This is a blog post with my personal vision on the subject of SoC (Separation of Concerns) and SRP (the Single Responsibility Principle).
First of all, I’m convinced that it’s very important to adhere to these principles as much as possible.
It can really make your code easier to read and maintain. Clean simple classes with one responsibility are usually much easier to understand and to change. A change in some part of the program, will only affect the class that is responsible for that part of the logic.
Read the excellent book “Head First Design Patterns” by Eric and Elisabeth Freeman, if you have no idea of what I mean.
On the other hand, it is my believe that a dogmatic approach can also make your project a mess. I’ve already seen such projects, where even the architect himself found it nearly impossible to find his way in the massive amount of classes.
(Yes, that logic is definitely in this class. No wait, it’s in another implementation of that same interface here, I think.
Now where is it? Oh right, it’s in one of the other projects. Hmm, let’s see. Which one could it be? I think here… hmmm….no…or here…)
This led me to the creation of following chart.
It shows my interpretation of the relation between:
- the readability/maintainability of an application and
- the level of separation of concerns, expressed in number of YACTESoC‘s (which is an acronym I made up, for: Yet Another Class To Ensure Separation Of Concerns).
I distinguish three different stages.
Let’s start with the first stage.
In this stage there is no real design in the application. Just some classes that do lots of stuff, and possibly some helper classes with static methods.
First stage: Little or no SoC.
- Polytheism: multiple GOD-classes (they’re omnipotent, they can do it all!)
- Spaghetti coding
- Small number of classes, but most of them are humongous.
- Completely untestable.
- Just keep coding till it suddenly appears to work
(appears, because there are no tests to prove it)
As the code gets more structured and responsibilities are separated, class-size will decrease.
Classes will become simpler and better testable. So you arrive in the second stage.
Second stage: The happy medium
- Good SoC.
- Good testability.
- This code can be self-explanatory (with a clear project structure, and meaningful class and method names), so there is little need for extra documentation.
This stage can be achieved with little or no extra development (pink line in the chart) compared to stage 1, just by designing your application more intelligently.
There may be some extra work for writing unit tests. But, this extra investment is already paid back after just one or two change requests.
A change request in stage 1 is like a loose missile. You have no clue what damage it will do and where.
So, your goal should be to end up in the golden rectangle in the chart. Little extra development time, but well-structured, readable and testable code.
As the number of classes increases, the need for extra documentation increases to fully understand the structure of the project.
This requires extra work. In case of change request, you have to change the code AND adapt the documentation!
It only takes a little step further to end up in the documentation hell!
(This is the situation where you end up modifying more documents than code. Or end up with documentation than hasn’t been kept up to date enough to be useful, instead it can lead to misinformation and will work contra-productive).
As your skills as an architect grow, and your confidence grows stronger, you are more and more able to separate even the smallest responsibility from the rest. So you risk ending up in the third stage.
Third stage: Principles and Patterns rule!
- Holier than the pope SoC adaptation.
- Architectural masturbation material
- A huge number of classes with 10 lines of code.
- EVERYTHING is testable (with thousands of unit tests, mocks, stubs, …)
- An incomprehensible maze of classes for every new developer entering the team
(unless he follows a two-weeks intensive course about the project first)
It’s a lot of work to develop and maintain this kind of application. But then again, it is the most maintainable project ever.
However, the fact is that practically no one fully understands the project and knows where to change things. So it ends up as a mythical project that no developer in his right mind dares to modify!
Conclusion
So to conclude, let’s say it’s good to know and apply these principles (Check your favorite search engine for ‘SOLID development principles’), but just don’t overdo it.
I once heard a guy say: “it wasn’t easy, but finally we succeeded in using all patterns in the book from the Gang of Four” in our project.
Your motto should always be: use it when it’s helpful!
It may never be a goal in itself.