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

Hiya - don't know if anyone has mentioned this yet -
but this is a way to make VFP 'behave' as if it could handle
template processing similar to C++ for classes and operator overload.

>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.
>
Na - its a standard argument for template writing in C++ - you're not arguing over something new .
BUT ? The concept of templates, whilst they are re-usable, was always to allow for different types of computations or things done based on the input parameters and number of input parameters to the class. OO Purists will absolutely dry and debunk the concept, but ? was basic principle for how to deal with data structures in C++, in a college textbook sanctioned by the ACM about 8 years ago.
>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.
>
EH - if ONE FUNCTION doing ONE THING [and not possibly more than one thing] then it should ONLY reside in a common libary, either in a classlibrary or in a prg.

IF you are relying on it doing more than one thing, then don't, by any means, call it the DWORD METHOD - that 'label' doesn't hold any more.

>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?
>
ah - rewrites ! Well - they typically keep you a coding, and if an employee, your wages are secured. If you are a independant or a code shop, if you can't get it into a maintenance contract then you'll have to eat the time.

>Having the dword code inside the class means less couples and the class can be seen as more coherent.
>
uh.. moving it inside of a class library would be fine [with your wording above] .. having the dword code inside of a class with other branches of execution absolutely adds to some overhead, and at this point ? it's less coherent, in my opinion, because its no longer atomic or granular.
its also not as tightly coupled cause it is now only part of a branch of execution .

but ? from a viability of C++ templates and translating the concept into a VFP class - I still think its mondo cool.

>The bottom line is, which is the correct interpretation? Please provide proof.
>
proof ? yak - I have to dig in storage for the book ! Tis in a box. Yikes - My Life is a box [or collection of loosely coupled boxes, thereof]
mondo regards [Bill]
>Thanks!