>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.
>

OK. In-depth explanation: http://fox.wikis.com/wc.dll?Wiki~Coupling~SoftwareEng

But, IMO, you do have a junk drawer there or at least a swiss army knife.

To me the goal is to have discrete objects that do a particular thing well. You thereby get loose coupling.

In this case, the methods in your object (and by the way to me a method is supposed to be distinct to the object - so a spark plug sparks, and a dog barks, and there's something wrong when the dog sparks and the spark plug barks) are examples of coincedental cohesion - which is also undesirable.

You can always either make methods in two objects with the same name as a separate shared UDF/.PRG (that call that shared UDF) or make the object call the shared UDF/.PRG.

It is not "cohesion" to have the code of a UDF/.PRG copied into different methods.

I'd want to have different objects - an ADOObject for the ADO interfacing, an ObjectManager which provides the ClassProperty methods, a Windows interface object, so you can Logoff and a BuildDirectoryTree object, which would in fact use iterator, aggregate and visitor objects.

>
>>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...