We all know how much object orientation has impacted the way we code in last 20 years. Initially it was a challenge to move the existing code from structural to object oriented. As amount of effort, it need to refactor the dependencies was not worth. From last decade, Organizations are building green field products with OO in core. It does not mean OO way will take away structured code. It is combination of two which make final product. In this block we will keep our focus to discuss the building blocks of OO. So, let’s start by point them down.
- Encapsulation
- Inheritance
- Abstraction
- Polymorphism
- Composition
We will discuss above concepts in detail. After it we will try to elaborate more on Interface-Implementation discuss.
Encapsulation: It is method of packaging the class in such a way that minimal public interfaces are exposed. It is best from security as well as functionality prospective. For example, if we want to calculate the cube root of number it is sufficient for interface to shown cube root results, logic exposure is not necessary.
Inheritance: Simplifying the definition of inheritance we can say it is concept of inheriting the attributes and method of another class i.e. new class can abstract behavior of other class. Let’s take example of Mammal class having attribute eye color. So, classes such as Cat and Dog need no to write eye color attribute again, they can inherit it from mammal class.
Abstraction: Taking inheritance example to one step further i.e. if we want to have class for Persian cats etc we need to have multi inheritance which is actual abstraction. So, it is basically extension of encapsulation.
Polymorphism: Poly means many, morphism is more of meanings/shapes. Let’s say we have a class name write and we can write using pen, pencil, highlighter. And once I call method write to write using pencil, pen, highlighter it is like write method call the object to use for writing resulting in different results.
Composition: Inheritance is more of IS-A relationship but then when we talk of some objects, we come across HAS-A relationship. The abstraction depicts later type of scenarios. For example, we can have mixer and mixer motor called as same thing. Mixer has a mixer motor.
As we have briefly talked about the build blocks of the OO. But it is equally import to use them in balance so that we should have best design in place. One should always understand the importance of keeping implementation separate from the interface. I am not referring to GUI when I am talking about interface, I am talking about class interface.
Let me take an example to explain it further. We have FAN in our house and the only thing we know is that we need to plug in in the AC power unit. It is not my concern to understand how electricity will be generated or how will it reach to my house. If I try to play with my interface and make it more abstracted, then I am in danger of make it complex for developer to understand. So if I give 5 specification that particular fan can be only used with power plug or can only be used with nuclear generated electricity not coal generated then chances are Fan may not do great as a product.
So, any implementation change should not impact the interface. End user will not have any concern if backend switch from Coal to Solar. But it will be a problem if power changes from AC to DC.
I know understanding the concept is one thing and implementing them is different. But I am hopeful that after reading above concepts readers can figure out the core components of object orientation.