Hi Mike,

Actually, it's not a "junk drawer" at all. That's my ToolsOther folder (bg).

All humor aside, this common code serves a very defined purpose. When I discover that a piece of code which I've written for a particular app or class *will be used* (notice I didn't say "might be needed") by one or more different classes/instances in *another* app, the code goes there. Some examples: CountADORows (a true count of ADO recordset rows regardless of the RecordCount property), CreateNewGUID, DoesClassPropertyExist, GetClassPropertyValue, LogOffWindows, BuildDirectoryTree -- you get the idea. The class currently only has 18 methods, so it's not huge and unwieldy.

When I asked the question, the above was the case. The code I'm thinking about placing in the common code class exists in three different apps right now. I'm just not certain I want to *force* my apps to have this class available as a requirement for running the app (right now, they instantiate/remove the class as needed).

I guess what I'm really asking in the original question is for a more "in-depth" explanation of the difference between tight and loose coupling, with an example or two.


>Hi Evan
>
>Ask yourself what this "common code" class resembles in terms of real physical objects. I'd bet your first answer is a junk drawer. Then ask yourself, is a junk drawer a good design?
>
>I think too often people are making conglomerates when they should be making sets of modules.
>
>>Hi folks,
>>
>>I'm trying to wrap my (extremely feeble) mind around an issue and I need some clarification. This concerns code written in VFP 8 and above, and the answer to this issue is -critical- to the timely completion of the app I'm currently working on.
>>
>>I have a "common code" Custom class which contains very frequently used code in its methods. This class is part of a class library which is accessible by either visual apps or "non-visual" components that may exist as VFP objects -or- COM objects. I use this common code class in MANY places throughout MANY apps, instantiating and releasing it as needed.
>>
>>As part of the app that I'm currently working on, I've also developed some data-driven classes that query some SQL Server metadata to mimic the appearance and functionality of the VFP Toolbox for use in several app forms.
>>
>>During this process, I've thought about placing some of the code that occurs frequently in these classes in the "common code" Custom class, storing the name and location of the class/classlib as properties of the toolbox classes (or in a local VFP config table, which already exists for each app), and then instantiating the common code in the Init() of the necessary toolbox pieces. Problem is, without that frequently used code, the toolbox pieces can't function and the Init() would have to abort if they weren't available. NONE of the other pieces of code in the common code class are required by any other classes to operate.
>>
>>I've also thought about making the common code class a required part of my "application object" when that instantiates.
>>
>>HERE'S THE QUESTION: By doing either of these things, does this action classify as "tight coupling" between the toolbox classes and the common code class? If so, is that acceptable for this process, and which way should I do it? If not, WHY?? And, if it's not, what are some of my alternatives and what are the benefits/drawbacks to those alternatives?
>>
>>All your thoughts and explanations are appreciated...