OOP + S = OOPS
Tags: beginners, oop, solid
Published: 2019-06-01 01:37:45

---
title: OOP + S = OOPS
published: true
description: Some thought on the single responsibility rule
tags: #beginners #oop #solid
---


## 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!