The Conclusion of The SOLID Principles Series (SOLID 6/6)

SOLID principles are maybe one of the most written subject in programming blogs. This series probably didn’t bring nothing new to it but as I said in the first post of this series my purpose was to finally really learn what SOLID principles are. It was a more powerful way to learn them writing this series than just read about them (and it is not one or two times I have read about SOLID principles, remembering only the first one, single responsibility principle).

If someone considers writing a series about SOLID I recommend to write it in a different order (ie. not starting from ‘S’ like all others including me). That way there is a better chance to find some new view for these principles compared to others who always write in the same order.

If there is one thing to say about SOLID principles it is that they highlight the importance of interfaces. Four of them has the key point in using interfaces. The single responsibility principle is the only one not related to interfaces. “Code against interfaces, not implementations“ is the main message of SOLID.

Small classes and interfaces are another key points that concern every five principles one way or another. For example, the single responsibility principle says to write small classes that do only one thing and does it well. Interface segregation principle on the other way says to implement small interfaces, even with just one method.

Small classes and interfaces better lead to loosely coupled code, which is widely recommended. Mark Seemann compares not-SOLID code and SOLID code as “Duplo vs Lego”. Not-SOLID code and its classes are like Duplo bricks: big ones but hard to implement anything special. Whereas Lego bricks are like SOLID code and classes: they are small and you can construct more specialized creations (software) with them. As a Lego fan, I like this parable.

According to Mark Seemann SOLID code is more maintainable and easier to unit test than not-SOLID code (Encapsulation and SOLID by Mark Seemann). That comes straight from the small size of classes which makes them easier to unit test (can someone say a big class is easy to unit test?) and thus also easier to maintain.

Probably I will learn more about SOLID etc. by reading Agile Principles, Patterns and Practices in C# by Robert C. Martin and Micah Martin in near future.

Blog Posts in This Series

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle
• The conclusion