About coupling and cohesion

cohesioncoupling

At the end of this discussion about coupling and cohesion https://www.youtube.com/watch?v=hd0v72pD1MI some renowned programmers agreed in the general thought that to achieve high cohesion you have to join things, and to achieve low coupling you have to split them.

This seems to be a common thought but I think is totally the opposite.
In my opinion the most cohesive module is the one that doesn't exist or have just one small feature, and in the other hand the less coupled module is the one that only depends on itself

In a small example, the following module:

(feature A, feature B, feature C)

has low cohesion and low coupling (no coupling at all).

Trying to achieve high cohesion I will try to split that module:

(feature A)-(feature B)-(feature C)

now I have three high cohesive modules but now the system could become highly coupled.

I see this issue in the Microservices world, where splitting things seems to be equal to "decoupling" your system.
Then you have to touch 4 different services and 3 layers in each one to add a simple property, but no one seems to care about that.

I would like to hear your thoughts about this

Best Answer

I see this issue in the Microservices world, where splitting things seems to be equal to "decoupling" your system. Then you have to touch 4 different services and 3 layers in each one to add a simple property, but no one seems to care about that.

Excellent insight!

This is not just microservices, as you say. Even in monoliths a layered architecture results in you modifying all "layers" most of the time, even for simple things.

"No one seems to care" is also a great insight. Although, I think it has more to do with a lot of bad, and no good examples being widely available.

If you care about maintainability, i.e. if you want to have (business-relevant) changes mostly localized (such as adding a simple property somewhere), you'll find that you need to do things differently to what most projects do.

In short, and this has been years worth of learning (/ unlearning) for me, you'll have to make sure that objects don't publish their data. Having a "getter" in an object basically means that data is used elsewhere, i.e. this object will probably change if any of the usage sites want something differently. This is what cohesion is supposed to prevent. You'll have to include all functionality in the object that is cohesive, including presentation, persistence, etc.

Coming back to your example about adding a property. You can imagine the only way you will have a single place of modification, if you include both UI, "logic" and persistence in the same object. Ironically this is what object-orientation was supposed to do, include function with data.

Regarding microservices, those can be done this way too. If your microservices are not CRUD-based (as most are), but implement a closed, self-contained function, including UI, you will not have this problem of modifying many on a single change.

As you probably realize, all this is dogmatically opposed by most current design / architectural patterns, which always try to split on technical merits. Like always splitting everything UI from everything that is "pure" calculation.

So this is where we're at. You seem to be asking the right questions, so keep asking, don't take anything on authority!

HTH

Part 1:

Technically known as "Separation of Concern". Each class has a specific role, it should be handling business logic or application logic. Try and steer clear of class that combine both responsibilities. i.e. A class that manages (broad term) data is application logic while a class that uses data is business logic.

Personally I refer to this (in my own little world) as create it or use it. A class should create an object or use an object it should never do both.

Part 2:

How to implement separation of concern.
As a starting point there are two simple techniques:

Note: Design patterns are not absolute.
They are supposed to be customized to the situation but have an underlying theme that is similar to all applications. So don't look at the examples below and say that I must follow this rigidly; these are just examples (and slightly contrived at that).

Dependency Injection:

This is where you pass in an object that a class uses. The object that you pass in based on an interface so your class knows what to do with it but does not need to know the actual implementation.

class Tokenizer
{
    public:
        Tokenizer(std::istream& s)
            : stream(s)
        {}
        std::string nextToken() { std::string token; stream >> token;return token;}
    private:
        std::istream& stream;
};

Here we inject the stream into a Tokenizer. The tokenizer does not know what type the stream is as long as it implements the interface of std::istream.

Service Locator Pattern:

The service locator pattern is a slight variation on dependency injection. Rather than give an object that it can use, you pass it an object that knows how to locate(create) the object you wants to use.

class Application
{
     public:
         Application(Persister& p)
             : persistor(p)
         {}

         void save()
         {
             std::auto_ptr<SaveDialog> saveDialog = persistor.getSaveDialog();
             saveDialog.DoSaveAction();
         }

         void load()
         {
             std::auto_ptr<LoadDialog> loadDialog = persistor.getLoadDialog();
             loadDialog.DoLoadAction();
         }
    private:
        Persister& persistor;
};

Here we pass the application object a persistor object. When you perform a save/load action it uses the persistor to create an object that actually knows how to do the action. Note: Again the persistor is an interface and you can provide different implementations depending on the situation.

This is useful when a potentially unique object is required each time you instantiate an action.

Personally I find this is particularly useful in writing unit tests.

Note of Patterns:

Design patterns is a huge subject unto itself. This is by no means an exclusive list of patterns you can use to help with loose coupling; this is just a common starting point.

With experience you will realize you are already using these patterns its just that you did not use their formal names. By standardizing their names (and getting everybody to learn them) we find that it is easy and quicker to communicate ideas.

Logical cohesion, and why is it bad or undesirable

Logical cohesion can be bad because you end up grouping functionality by technical characteristics rather than functional characteristics. For example, consider an application consisting of multiple modules. Each module represents some business domain and has corresponding data access code. If you group all data access code across all modules then you have logical cohesion. After all, it is all data access and it in some cases it is beneficial to be able to evaluate the data access patterns of an application. This however is problematic because the business domain provides the module boundaries, not the technical domain. By achieving logical cohesion you end up losing on functional cohesion. Typically, the business domain defines a well-defined unit of deployment and technical aspects are there to support the business domain.

Best Answer

Related Solutions

Coupling. Best practices

Part 1:

Part 2:

Note of Patterns:

Logical cohesion, and why is it bad or undesirable

Related Topic