Hi Mike,

Cohesion: What are the responsibilities of the component you are creating? Is one of those responsibilities providing the DWORD function to other parts of the system?

Coupling: As others have stated, the issue is tight coupling vs. loose coupling. IMO, having lots of objects with messages flying around is a good thing (albeit confusing a times). It shows you have created nice, cohesive, reusable units and you are making use of them. Reusability is the goal, isn't it? Now, if your DWORD function worked with only a single class, it would be tightly coupled to that class and wouldn't be very reusable. Sometimes this is a requirement, but should generally be avoided.

In your example, I would probably leave DWORD as a separate function, or maybe put it in a class with other Win32 stuff.

>Hi all
>
>I'm having a debate with an associate. The debate has come down to a conflict over the meaning of the words coupling and cohesion.
>
>From http://c2.com/cgi/wiki?CouplingAndCohesion...
>
>"Cohesion is the degree to which the responsibilities of a single component form a meaningful unit.
>
>Coupling applies to any relationship between software components.
>
>A first-order principle of software architecture is to reduce coupling and increase cohesion."
>
>A module must be coherent and it must reduce coupling. What does the word coherent mean? The module must have meaning and the code should support that meaning. In this case, the module returns a dword. What does coupling mean? It means there should be no separate functionality embedded in this function.
>
>http://en.wikipedia.org/wiki/Coupling#Computer_programming
>
>Here's the scenario. We're trying to build a class. This class needs a piece of code. This piece of code could be a method. It could be a .PRG. The piece of code produces a DWORD that could be used with certain Win32 functions. The code looks like this...
>
>

PARAMETERS m.tnLongVal
>LOCAL m.lnLoopVar, m.lcReturn
>m.lcReturn   = ""
>FOR m.lnLoopVar = 24 TO 0 STEP -8
>  m.lcReturn = CHR(INT(m.tnLongVal/(2^m.lnLoopVar))) + m.lcReturn
>  m.tnLongVal   = MOD(m.tnLongVal, (2^m.lnLoopVar))
>NEXT
>RETURN m.lcReturn

>
>This code is a good candidate for a separate function. The code already serves a particular purpose. It is coherent. All the code in the function contributes to returning a dword.
>
>There is no internal functionality that might be used elsewhere. It has no external code coupled in it. However, it is intended to be coupled to other things. That leads to flexibility.
>
>If I modified the code like this...
>
>

PARAMETERS m.tnLongVal, m.tlSomeParameter
>IF m.tlSomeParameter
>  lcReturn = str(m.tnLongVal)^2
>ELSE
>  LOCAL m.lnLoopVar, m.lcReturn
>  m.lcReturn   = ""
>  FOR m.lnLoopVar = 24 TO 0 STEP -8
>    m.lcReturn = CHR(INT(m.tnLongVal/(2^m.lnLoopVar))) + m.lcReturn
>    m.tnLongVal   = MOD(m.tnLongVal, (2^m.lnLoopVar))
>  NEXT
>ENDIF
>
>RETURN m.lcReturn

>
>I just broke the rules. The other function triggered by setting m.tlSomeParameter to .T. is a squaring function. That means this piece of code could be used for returning a DWORD or returning the square of a number. That is clearly wrong. With me so far?
>
>A given class may be coherent. It may serve a singular purpose. If it needs the dword functionality, I have three choices. 1) I can make a method that contains the dword code, 2) I can make a dword method that calls the dword code or 3) I can call the dword code directly.
>
>IMO embedding the code in the dword method is poor coupling. The overhead of having the separate function means the two pieces are more independent. There is on the other hand, more "connections" required. That may be the very heart of this debate. More connections (which can be called couples) is seen as breaking the rules.
>
>Further, copying dword reduced it's reusability and will effect overall system stability. There is a potential for the two versions to drift. A problem in one means a problem exists in both. However, the likelihood is that only the one that exhibits a problem will be fixed. That means the second one is a lurking problem waiting to bite.
>
>A dword method that calls out to the dword.prg is a compromise.
>
>The dword code relies on several VFP functions. Methods of a class can rely on VFP functions. I say it is desirable for the class to refer to the dword.prg as if it was a VFP function. A single fix to the dword method will improve the entire system. On the other hand, if there are fixes in place to get around an existing dword problem, that code may break. I think that too is desirable. If you cure the patient, why leave on the bandages?
>
>Having the dword code inside the class means less couples and the class can be seen as more coherent.
>
>The bottom line is, which is the correct interpretation? Please provide proof.
>
>Thanks!