Coupling and cohesion

1. Keep things that have to change together as close together in the code as possible.

2. Allow unrelated things in the code to change independently (also known as orthogonality).

3. Minimize duplication in the code.

One should always aim at increasing cohesion and decreasing coupling.

Decreasing coupling

Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are. Tight coupling means that related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand.

The goals behind achieving loose coupling between classes and modules are to:

1. Make the code easier to read.
2. Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes behind well-designed APIs.
3. Isolate potential changes to a small area of code.
4. Reuse classes in completely new contexts.

Ways to achieve loose coupling

1. Eliminate Inappropriate Intimacy.

Inappropriate intimacy refers to a method in a class that has too much intimate knowledge of another class. Inappropriate intimacy is a sign of harmful, tight coupling between classes.

2. Law of Demeter

Only talk to your immediate friends. An easy way to detect violation of this law is to see if you are calling a method on property of another object i.e. obj.Property.Method1()

The Law of Demeter is a powerful tool to help you spot potential coupling problems, but don't follow the Law of Demeter blindly. Violating the Law of Demeter does add tighter coupling to your system, but in some cases you may judge that the potential cost of coupling to a stable element of your code is less expensive than writing a lot of delegation code to eliminate the Law of Demeter violations.

Increasing cohesion

It is a measure of how closely related all the responsibilities, data, and methods of a class are to each other.

1. Implementing SRP would help achieve cohesion.

2. Tell, Don't ask

The Tell, Don't Ask design principle urges you to tell objects what to do. What you don't want to do is ask an object about its internal state, make some decisions about that state, then tell that object what to do. Following the Tell, Don't Ask style of object interaction is a good way to ensure that responsibilities are put in the right places.

3. Information Expert Pattern

If you have a new responsibility for your system, in what class should the new responsibility go? The Information Expert pattern asks, who knows the information necessary to fulfill this responsibility? In other words, your first candidate for any new responsibility is the class that already has the data fields affected by that responsibility.

4. Say it Once and Only Once

One of the best ways to improve cohesion in your system is to eliminate duplication wherever you spot it. It's probably best if you assume that you don't know exactly how your system is going to change in the future, but you can improve your code's ability to accept change by maintaining good cohesion and coupling in class structures. One of the best ways to improve the cohesion quality of your codebase is to simply pull out duplication into separate classes that can be shared across the codebase.