loose coupling, strong cohesion

[koen]

I think I understand the concept of loose coupling more or less. Classes (or subsystems) shouldn't depend on the workings of other classes too much. Strong cohesion however is something I don't get. It seems contradictory with loose coupling. Can someone explain this concept ?

[448191]

Cohesion is the degree in which different parts form a meaningful unit. 'Parts' can refer to pieces of software on any level, from components, to packages, subpackages, classes, methods, or even blocks of code. It's not really contradictory to coupling. High cohesion can promote loose coupling, because high cohesion usually equals less (or more related) responsibilities for that part.

 

High cohesion and loose coupling is what you're usually after. Hope that helps a little.

[koen]

Let's see if I understand this. An example would be that when I use a class, code snippet, library, etc from someone else, i'd have to make sure I choose something that fits my needs as close as possible. Eg not choosing something with extra functionality or features I don't need for my program.

 

Is this correct?

[448191]

No, not really. Cohesion is about centralizing responsibilities. One common way to accomplish this abstraction. For a familiar example, imagine some CMS with data access logic scattered throughout different business objects. By abstracting out the SQL and whatever else there is to abstract concerning data access, I centralize the responsibility in the data access layer, reducing coupling between the different business components, and increasing cohesion. There is high cohesion in the newly created data access component, as well as in the business components, who now have reduced responsibilities.

 

Cohesion and loose coupling are goals, abstraction is one of the means.

[koen]

Ok let me try again. Strong cohesion is about handling clearly defined responsibilities and delegating what's not part of that responsibility. Or: if it's not part of the responsibility, ideally some other part should be responsible for handling that. The strategy pattern as an example of how one might implement this.

[448191]

That's a lot more accurate. Though I think it's important to understand that this doesn't just concern classes or types, like something like implementing a Strategy addresses. It also applies on a higher level (think MVC), a lower level (think Template Method), and can even be a goal within a relatively simple block of code. Abstraction, delegation, the SRP (and OCP, DRY and the like), they're just handles for approaches to achieve higher cohesion and looser coupling. Many, many patterns (if not most) are common practices to achieve this, with the ultimate goal of increased maintainability and extensibility in mind.

 

It's very broad concept, that applies across layers as well as methodologies; it's not at all exclusive to OO.

[Codecaine]

That's a lot more accurate. Though I think it's important to understand that this doesn't just concern classes or types, like something like implementing a Strategy addresses. It also applies on a higher level (think MVC), a lower level (think Template Method), and can even be a goal within a relatively simple block of code. Abstraction, delegation, the SRP (and OCP, DRY and the like), they're just handles for approaches to achieve higher cohesion and looser coupling. Many, many patterns (if not most) are common practices to achieve this, with the ultimate goal of increased maintainability and extensibility in mind.

 

It's very broad concept, that applies across layers as well as methodologies; it's not at all exclusive to OO.

 

Agreed.  I've done a mathematical analysis of coupling within the Zend Framework.  It shows the difference in coupling at class level and at component level.  Anyone interested can check it out at http://codecaine.co.za/posts/analysis-of-coupling-within-the-zend-framework.

[448191]

I'll admit, I didn't read the whole thing (interesting thing you're doing though), but the first thing that sprung to mind is: you can't calculate coupling. Coupling is the degree in which the change in one component requires a change in another. There isn't a mathematical formula in the world that can calculate that, it's too abstract.