SOLID – Focusing on Abstraction

I think I’ve never written about SOLID Principles here, in my blog. So, I will do it trying to be simple, and focusing on abstractions.

Single Responsibility

Simple, a classe must have only one responsibility. A classe or interface must be cohesive.

DIP – Dependence Inversion Principle

Each modifications in a class is propagated to dependent classes. This consequence of changes get difficult to maintain the classes and can create some bugs on your code. So, classes that are client of another classes are fragile because they are exposed to propagations of modifications. But, avoid dependencies is not the solution (actually, it’s impossible). The solution is perform dependencies with classes that are stable or where the chances of changes happen in is almost 0%.

Abstractions are always the best element to be dependent on, because they are stable.

Think in interfaces, when an interface would suffer modification? It doesn’t have any implementation! It’s stable! So, avoid to depend your classes of classes that have implementations and prefer to do it with abstractions.

*hint: a class that has a lot of dependent classes is stable. Why? Because any developer would not be crazy to modify a class like this =D.

A module should always depends of another that is more stable. Implementations should depends of abstractions and abstractions should depends of other abstractions.

If a class A depends on a class B, who depends on C, C is more abstract than B, B is more abstract than A and C is more abstract than A.

OCP – Open Close Principle

Still thinking about be stable, your classes should be close to modification (stability) but should be open to be extended.

For your classes become open to extensions, we should think on abstractions. Develop focusing on abstractions to extends them and create different implementations.

Cohesion

If a class is growing a lot and suffering a lot of modifications, it’s not closed to modifications and we should review the cohesion of this class. This classe has not only one responsibility, but two or more. A class with one responsibility is more stable and is easily closed to modification.

The solution is try to abstract this class to become cohesive, simple and, consequently, closing to modification stables.

DIP + OCP

You should develop thinking on abstractions to design stable (good option to dependency) and cohesive (single responsibility) classes and to be possible to extend them easily (open to extensions).

• How much you extract and abstract your classes, they will be simpler and consequently more cohesive.
  • How much simple and cohesive you class is, more you avoid modifications on it because it will not be necessary, so, this class will be “closed to modifications”.
    • How much closed to modifications your classes are, more stable and good to depend on theirs will be.
• How much you extract and abstract your classes, easier you will extends them and make your software grow.