You probably know the "SOLID principles", which should help you to be a better programmer. And maybe, you are still struggeling with the "S", the Single-responsibility principle (SRP). Maybe I can give you a different view on this topic.
Ok, we are talking about OOP, the Object Oriented Programming. As Robert C. Martin (Uncle Bob), the originator of the term, was editor-in-chief of C++ Report magazine, we can assume he probably was using this langauge. Did you ever wonder about the strange formulation:
"A class should have only one reason to change"?
Often enough, we find this explanation: "A class should have only one reason to change, meaning it should only have one job or responsibility". But, what is "a job?" Is it a complex task or keeping a single state? If a class has the job to print something, in which kind is it changed, if it is doing the job? Let´s say: We get more questions than answers.
So, maybe we should have a look back to what C++ was used for in 2003. This is an overview of the Microsoft Foundataion Classes (MFC):
Ok, this is the 1st of three charts, but all classes are derived from CObject, which implements the most basic behavoir of MFC-Objects. You will find all kinds of Interface objects that can be used to build User Interfaces, but also handle Drag&Drop-Actions, store the current UI state and so on. This are the building blocks of all Windows Applications:
"The Microsoft Foundation Class (MFC) Library and Visual C++ provide an environment that you can use to easily create a wide variety of applications." (Source).
If you are building with User interfaces in C++, you usually do not start building classes from scratch. You select an appropriate class that provides most of what you need, so you just add some specific code. So, you start with one of the foundation classes or one of it´s decendants. As an example, you want to create a new input field to be used in the Application UI. As the UI only accepts classes that are derived from certain core classes, you need to start with one of the existing classes. Therefore you inherit a lot of skills that each UI-element must have. To minimize your work, you select an element that is very similar to what you want and add only what you need. Thanks to inheritance and polymorphism, this is possible without breaking the existing code.
Later Robert C Martin explained the SRP as cohesion: "Gather together the things that change for the same reasons. Separate those things that change for different reasons". You surely need more than one thing to gather something.
In C++, class hierarchies can be quite complex and deeply nested. But if you follow the SOLID principles, you will be able to manage this complexity. Think of a class always as part of a hierarchy. Each new class, you add to this hierarchy, sould have a single task. This does not mean, it should only have one method or one state. But all properties and methods it implements should be focused on the same task. I suppose, this is, what Uncle Bob meant.
There is another aspect of the SRP that you can only understand thinking in hierarchies: A hierarchy is like a tree, each method you add to the root is inherited by all the branches and leafs. If you choose the wrong position, you might be forced to implement the same code in multiple branches. To keep your code maintainable, you should try to find a position where every task needs to be implemented only once. This could also be seen as a "single responsibility principle": For each task (in a class family), there should only be one member that is responsible for this task.
Finally I´m not sure what Uncle Bob was really trying to say, but I know, that using OOP without taking benefit of inheritance does not make much sense.
Top comments (2)
I like this take! Good one :)