Someone put some good stuff on the wiki recently.

http://fox.wikis.com/wc.dll?Wiki~Cohesion

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

Modules/procedures can all be components. This is not just an OOP discussion.

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

Agreed. In general, we want High Cohesion and Loose Coupling. Let's get back to the specific example.

DWORD.PRG is cohesive. If I copy the code from DWORD.PRG into a method of a class that extracts icons and deletes DWORD.PRG, that method is cohesive. The class is cohesive, because its members (methods) are supporting the responsibility of the component.

A class that holds a bunch of generic functions would not be cohesive. Further, it would likely require more coupling.

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

I think we're saying very similar things except that I said meaning and you said responsibility.


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


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

I don't see why these concepts cannot be applied to functions/prgs etc.

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

So is putting the code from DWORD into each class that needs it _tight_ coupling and therefore wrong?