>While working in a FPW 2.6 environment, I have created a number of reusable routines (each a separate .PRG) that I use in my applications. What is the preferred way to use these in VFP? Do I continue to include each .PRG in my VFP project? Do I create DLLs? Do I create custom classes and place the routines in user-defined methods? If so, do I create many classes and categorize routines by topic or create one monolithic class? Any suggestions are welcome.
>
>TIA
Bryan,

This is an interesting question that doesn't have a simple short answer. This question actually came up during one of my sessions at DevCon. The issue here is one of design, and you are the person who determines the design. If you chose to design the system to make use of UDF's then your separate prgs will be fine, however if you chose to design the system to comply with OO design principles then the prgs will be outside of your own design decisions.

There is no right or wrong way to do this, except within the domain of YOUR design.

For the sake of discussion let's assume that you decide to use objects for your code and place the code in the methods of those objects. Which way is better, one huge object with all of the methods you will ever need, or multiple smaller objects each with some of those methods? Again, it depends on YOUR design. There are issues like maintainability that are easier to manage with smaller objects which have related code in them, however there is nothing inherently wrong about using one object to hold all of the code you might need (unless it violates your design).

The real issue here is that we need to take the time to produce a coherent design for our work. We need to decide How we are going to do things and then follow those decisions in the implementation. Many time we will revisit our design during implementation and adjust some of our ideas due to things we encounter during implementation, and this is the way it should be. A design is not static, but needs to evolve with experience.

Now there are the OOP police, who will chastize you for not following pure OO principles, but let them do things their way. The pragmatic issue is getting the job done for the client or user and whatever design you chose to use is fine as long as it works and creates maintainable systems.