Sunday, November 9, 2014

Open/Closed Principle

Open/Closed principle says that "Software entities (classes, modules, etc..) should be closed for modification, but open for extension." While this doesn't make much sense, it is actually quite simple: to change behavior of a system (or a class or a module) you should not change existing code (it is closed for modification), but you should add new code (it is open for extension).

This principle is greatly tied to correct abstractions being present in existing code. If right abstraction is present, realizing this abstraction and plugging this realization into software allows for safer development, because there is only one new piece of behavior to test.

The problem with OCP is those very abstractions. It is impossible to predict what abstractions you are going to need in the future. Coming up with correct abstractions is one of the most important jobs of software developer. Developer needs to use their whole experience and knowledge of both software and domain to create abstractions, that can be expanded upon later on, while they don't unnecessarily complicate the design.

I believe OCP is one of the most important principle, especially in environment, where requirements change and demands on software change often. This is especially true in agile environment.

Monday, October 20, 2014

Single RESPONSIBILITY Principle

Single Responsibility Principle (SRP) says that "Each context should have only one responsibility."
This is simple to understand, but it is too ambiguous to actually apply it in practice. The major reason why is the word "responsibility". In original, Martin defines it as "reason for change", but that doesn't make things clearer. The problem is that responsibilities exist at many different levels of abstraction and in many different contexts. Responsibility can be "Responsibility to print a report", through "Responsibility to execute this query" to "Responsibility to add those two numbers". If this principle was followed rigorously, the code would end up as many tiny classes or functions each having  extremely simple and low-level responsibility.

SRP represents much more important concepts and those are cohesion and coupling. Other set of principles (GRASP) say, that cohesion should be high while number of coupling should be low.


But those two go against each other, so it is key to balance those two in equilibrium. Following SRP rigorously would then result in low cohesion and high coupling. Resulting in something that should be avoided.

One good areas where SRP is good fit is business modeling. It is much easier to use SRP on business responsibilities, than trying to come up with your own.

In light of this, I believe that SRP only serves to remind us, that we should always look at how cohesive and coupled our code is and separate or combine classes or methods based on that.

Thursday, September 25, 2014

Not so SOLID principles

SOLID principles appeared around year 2000 by Robert C. Martin aka. "Uncle Bob". They were principles, if followed by developer, would result in software, that is maintainable and extensible. Since then, they gained lots of popularity and recognition. I can see them being mentioned on Programmers all the time. And I do think that they are good thing to know and use.

But, as all things, those principles are not without problems. One of those problems is that they are ambiguous in their description. This leads to misrepresentation of what they really mean and how they should be used. This is why some of the principles have multiple definitions, as people tried to be more specific about it. This is also why I believe those principles are good guidelines, but they should not be followed rigorously.

The following posts will go over each of the five popular principles, in which I will try to explain possible problems with their understanding and how I understand them.

The principles are :

  • Single responsibility principle
  • Open/Closed principle
  • Liskov Substitution principle
  • Interface segregation principle
  • Dependency inversion principle