Before starting turning things upside down, I owe you an apology: in this article I’m not going to talk about architecture with a big picture, I will do it with a simple one. Do not take this as an architecture article.
Real-life background
In human history (well, I would extend this to animal history), every time we all needed to do something, we tried to do it as a group. If we needed to do actions in the town, we as groups (not as individuals) decided what to do.
If you are planning to build a house, you probably sign a contractor firm that will know what to do and which worker will do it and when. It would be daunting for you to think about each of them. Probably, you will talk to the boss and if he has only 4 workers, he himself will tell them what to do. If he has 50 workers, he will have some project managers, each of them with 10 assigned workers. This way, the boss will only have to talk to 5 people instead of 50.
Let’s dive in code
Now lets land at our code world. When you have 3 lines in a method, those lines have to be very bad for you not to understand what they are doing. If that method has 10-50-100 lines, things get interesting… It’s yelling at you to split them off. Now you have 3 pretty methods whose names have to be very bad for you to not understand what they are doing. You’ve successfully black-boxed their implementations: how they do it is their business, not yours; you told them what to do and you don’t really care how they do it.
I could continue extending this with the class level, but the idea would remain the same. I think every programmer knows that lines compose methods than composes classes; they will split them or not, but they know how to do it.
But here it’s where problems appear and not every programmer knows how to proceed. I have a guy called Vehicle.class, it has Wheel.class, some Door.class… The coder is facing the hard time of finding a method in a sea of methods that the car, as an entity in itself, has to offer outside. He knows that some methods can be offered within Wheel.class and Door.class, and indeed, he has moved them to those classes, but still too many methods in Vehicle.class: A, B, C, D… Z. He would be delighted to group A, B, C methods into something called Class1.class (or ABC.class) and D, E, F inside a method called Class2.class but he knows that won’t be descriptive (no, fellas, God doesn’t want any class in a project called Class1.class).
Dimensions
The problem this developer has encountered is about naming, not about Do The Right Thing. It is difficult to get back to the time where we knew about methods but hadn’t learned about classes and knew nothing that they existed (depending on how you started, you could learn them at the same time or even classes before methods). It was only after you were taught about classes, when you could reorganize better those many methods. It’s a pity that in college they keep stopping at classes idea and don’t teach about more advanced designs, layers… properly naming…
The time that passed for me since I learned about classes until I learned about layers took so long for me… I knew I was doing something wrong, but I didn’t know what it was… Imagine you only live in 2 dimensions and your house is a mess (not judging here) because everything is spared. It’s not until someone tells you about the 3 dimensions when you realize you can stack up things, use those things called wardrobes, shelves… wow, you are on fire when you discover all that fancy stuff.
Sad thing is that it’s probably that someone will tell you that from a 3D point so you may not see them (you’d be actually hearing voices without seen anyone, which is something that we would not call a healthy signal) and will be difficult for you to understand it and think that will work in your current 2D scheme.