The beauty of OOP: A class has been born
Such beauty when an orchestra creates symphonies by musical instruments. Such beauty when a theatre presents untold stories with roles. Both are the same fine art — to tell audience what it is by how it feels.
Look at the bike on the picture. Do you think it can be build programmatically? What if its possible? What if by the power of technology, a mortal programmer has the ability to create one? Thanks to programming that connects the imagination and wildest dream into art in reality, it is possible.
Let’s say, I am that mortal programmer. With programming, I could do it by using a function. In programming, function is a set of instruction to do something.
NOTE: code examples are simplified due to minimize complexity.
function buildWhiteFixieBike() {
make its frame ...logic
make its pedal ...logic
make its saddle ...logic
make its stem ...logic
make its chain ...logic
make its frontWheel ...logic
make its rearWheel ...logic
put it all together ...logic
}One function called buildWhiteFixieBike() can create a white fixie bike by creating any part it’s needed. It works perfectly to build the bike that we wanted.
But, as a mortal programmer, I had an instinct that there are still something not done well. What if I could separate wheels creation into another function, so that I only need to place my logic once? Why I need to do the logic twice to create the same parts?
function buildWhiteFixieBike() {
make its frame ...logic
make its pedal ...logic
make its saddle ...logic
make its stem ...logic
make its chain ...logic
make its frontWheel by call createWheel()
make its rearWheel by call createWheel()
put it all together ...logic
}function createWheel() {
make a wheel ...logic
}
This would introduce to any mortal programmer a technique called Don’t Repeat Yourself (DRY) that whenever you see duplication, make it into one set of instruction. It would have been chaotic if I only changed the frontWheel and forgot to change the rearWheel because the knowledge are separated. The beautiful white fixie bike will crash after several runs.
In Pragmatic Programmer book, it says “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” There are types of duplication introduced in the book:
Imposed Duplication — Programmers feel they have no choice because the environment seems to require duplication.
Inadvertent Duplication — Programmers don’t realize that they are duplicating information.
Impatient Duplication — Programmers get lazy and duplicate because it seems easier.
Interdeveloper Duplication — Multiple people on a team (or on different teams) duplicate a piece of information.
Those duplication in wheels creation problem occur, especially for imposed duplication, inadvertent duplication, and impatient duplication. At first, I thought it needed to implement both wheel in the same function twice (imposed). I was too lazy to separate it into another function to cut my time (impatient). And I thought both wheels were different because one for front part and one for rear part, but I did the same logic for both (inadvertent).
Now, whenever I want to create a wheel, I will call createWheel() function. That way, I don’t have the same logic elsewhere. But still, there are something that’s not right. Function buildWhiteFixieBike() need to change if I wanted to create my frame differently like paint it into green. And it applies to another part creation too.
It introduce me to a new concept called Single Responsibility Principle (SRP) that every function should have only one reason to change. Uncle Bob also said in this article that:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
To fulfill my destiny as a mortal programmer, I did changes for separate parts creation into its own from buildWhiteFixieBike() function.
function buildWhiteFixieBike() {
make its frame by call createFrame()
make its pedal by call createPedal()
make its saddle by call createSaddle()
make its stem by call createStem()
make its chain by call createChain()
make its frontWheel by call createWheel()
make its rearWheel by call createWheel()
put it all together ...logic
}function createWheel() {
make a wheel ...logic
}function createFrame() {
make a frame ...logic
}function createPedal() {
make a pedal ...logic
}function createSaddle() {
make a saddle...logic
}function createStem() {
make a stem ...logic
}function createChain() {
make a chain ...logic
}
Now, by breaking it into functions, it gains me clearer understanding of its responsibility. So that way, each function will change for only one reason.
Still, there are something need to be improved. The more you see it, the more you realize that every function is creating an object. Not only build the white fixie bike, but functions to create its part too.
Please welcome, Object-Oriented Programming (OOP) where anything can be represented as an object. In OOP, everything divide into smaller modules called class. A class represent one single object. A class have its state and behavior. A class only have one reason to change.
By gaining this knowledge, I can separate any object creation into its own class:
class FixieBike {
function create(frame,pedal,saddle,stem,chain,frontWheel,rearWheel) {
put it all together ...
}
}class Frame {
function create(color) ...
}class Pedal {
function create() ...
}class Stem {
function create() ...
}class Chain {
function create() ...
}class Wheel {
function create() ...
}
Every part has its own class now. They only know their own behavior and their own attributes. This makes a class stupid and it is good. No class will override another class job. This will led to another advantages, when I change one class I don’t need to change in other class (DRY).
Now, whenever I create FixieBike I need to create its parts separately. It can be done by creating the object from their own class. So that every class should have only one reason to change (SRP).
Conclusion
As I keep improving the code, it allows me to understand what makes code more clean. It looks very simple, it is very basic: implement OOP, SRP, and DRY principle into the codebase. But it still happens on the floor though. I’d realized that only understand those basics are not enough. It needs to be applied.
One main reason why we need to make code more clean and beautiful is to make it less effort to debug in another day of production. The code speak as itself to another programmer that will handle the codebase. When there is a changes for objects, it is only needed to be changed on its class.
Sources:
The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
