Mike-

>From http://c2.com/cgi/wiki?CouplingAndCohesion
>
>"Cohesion is the degree to which the responsibilities of a single component form a meaningful unit.

Yes.

>Coupling applies to any relationship between software components.

Yes, or between objects. And there is loose coupling and tight coupling. Coupling refers to the degree changing the internal workings of one class affects other objects that are clients of that class.

It might be helpful (for the discussion) if we note that "componenents" can comprise one or more objects. So components can be contained in, or contain, other components.

>A first-order principle of software architecture is to reduce coupling and increase cohesion."

So far, so good. Note tho', also from http://c2.com/cgi/wiki?CouplingAndCohesion, "Cohesion is a property or characteristic of an individual module. Coupling is a property of a collection of modules[.]"

Cohesion refers to the intra-dependance of a component's members. Coupling refers to the inter-dependance of objects. So, a component is cohesive (not coherent) if its members all support and related to the well-defined, and complete responsibility of the componenet.

>A module must be coherent and it must reduce coupling. What does the word coherent mean?

Cohesive. Not coherent.

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

Not really correct, IMO. The DWORD class is cohesive if it doesn't contain any unrelated members or functionality to its single responsibility. It can be _loosely_coupled_ with other objects in yet a third object (componenet) if it doesn't break other objects if the guts are changed. There isn't any coupling with a function (or method). Coupling is between objects. And some coupling is necessary. We just don't want tight coupling.

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

It's a good function, yes. Cohesiveness (not coherent) and coupling doesn't apply in this example. It's a verb, anyway, not a noun. Nouns being objects that are coupled or cohesive. Doesn't, AFAIK, apply to verbs (methods).

>There is no internal functionality that might be used elsewhere. It has no external code coupled in it.

It doesn't. It's a pretty simple thing. But there's no reason it couldn't use another object.

> However, it is intended to be coupled to other things. That leads to flexibility.

Okay...

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

It's wrong, but not for coupling or cohesion. First, because your premise is wrong. You don't have a class, you have a method. It's wrong--maybe _this_ is a question of coherency. One function can means two different things.

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

I think this would be a good candidate for an interface. And you could implement this method as a DWORD interface. What do you think about that idea?

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

Connection--coupling isn't all bad. It's _tight_ coupling that's bad.