OOP
When we first started with OOP it was about modelling objects after things. A more modern approach says that OOP is about the messages passed between these objects. But the more I draw message diagrams, the more I realize OOP is like a hidden object game. You are always discovering new objects that can be brought to life.
OOP Opponents
Some OOP haters, like Brian Will from Youtube, say that OOP makes you model objects that do not exist in real life. These are your 'Managers', 'Builders' and 'Coordinators". Yes these don't make sense in the real world, but what is the alternative? Long lines of confusing code? Documentation embedded into your code that lies? A spiders mess of modules with complicated api?
The only other viable solution to OOP is purely functional programming, but this comes with it's own set of issues.
I'll admit when I goto describe the big picture (class hierarchy), it can get blurry. The global scope is messy. However when I look at individual objects, the code is clear with little documentation needed. The local scope is clean. This is where UML diagrams for the big picture can help.
The S in SOLID
The S stands for Single Responsibility. A method, class or module should only be responsible for one thing. A method, class or module should only have one reason to change. So why is it so hard to implement?
S means Struggle
It's not just you. The single responsibility rule is completely arbitrary. It changes with the problem space. Newbies and seasoned coders alike still have problems. It get's easier with experience.
S means Spiral
If you follow the rule strictly, you might end up with classes with just one function. Then you will have too many objects with messy messaging between them. How do you know what should be another object and what should not?
It's not one answer fits all. I would say lean towards having more objects than less. Unless you can safely answer that this objects requirements will not change. If you find an object to be useless, you can always merge functionality.
However the opposite is not always true and may cause a spiral of changes.
S means Simple rule
Sandi Metz of POODR came up with a simple rule. Methods should be at most 4 lines long and classes should be at most 100. This is using the standard 80 character width. Try it out.
4 lines might seem too restrictive, but it's actually a lot. If you are having trouble, then you can split up your methods. If it's still too long, a hidden object might be waiting to be discovered.
OOP really means
OOP is about protecting your code against changing product requirements. The smaller your objects are the better you can defend. Adhering to the single responsibility rule helps with this.
OOP is about the 80/20 rule. 80% of the benefit should come from 20% effort. OOP can achieve this.
clean code
Writing clean code is not easy. I'm still refactoring my code and so should you. Go on a treasure hunt and find those hidden objects!
Top comments (1)
I´m not pretty sure If I would agree to all of your statemens.
First of all: There have been different approaches to OOP. Using messages was the way, smalltalk organized the object communication, but smalltalk was one of the first OO approaches ever. So, you can hardly say, it is the "modern approach". Objects in C++ or Delphi use method calls as the first way of communication. Many big applications implement a meassaging system, but this is not a core concept of the programming language. You could easily implement such an event system without objects. I do not think it is not defining the OO concept at all, if you use method calls or messages.
Secondly, things have nothing to do with objects. Not in the way, the "internet of things" does. OOP is about creating objects from classes. A class defines the behavoir of an object, while the object defines its own state. Classes can be derived from each other to inherit the structure and behavoir of a parent class. So I would agree that one core concept of OOP is to avoid redundancy. Every function should only be implemented once in a hierarchy.
The concept of "single responsibility" is shurely important. But you should be precise in the difference between classes and objects. A method should only be defined once in a class hierarchy, but there is absolutely no problem to have as many objects as you like. Many people new to OOP have problems to see the difference between classes and objects, so it is important to be clear in an explanation.
s = struggle
The real hard point in OOP is to build a class hierarchy, that is future poof. Making bad decisions in an early state of the design will be very hard to correct. I found myself several times to go two steps back because I found, that a decision was not good.
On the other hand, OOP allows to build your own abstraction layers to whatever tool you will need. If you cover your database interaction inside an object, it will be very easy to switch to another database, as you only need to change the covering class.
So, in my experience it is always a bit more effort to use OOP, and you should have good reasons to use it. On a long term, it often pays back, but not in any case. My rules of thumb are:
Overall I like to see more people gaining interest in OOP methods. They can be a real life saver for larger projects, as they allow to reduce the size of your problem, so that it finally fit´s into one brain!
Thank you for your post!