Thinking in OOPS

Object Oriented Programming is one of the most misunderstood concepts in today’s world. It may seem a hard implication at this age where every other programmer is using object oriented language to structure their code, but do we really understand OOPS and the way it must be used to solve our problems better.

What is OOPS?

Do you know the full form of OOPS? I mean OOP is very clear and it stands for Object Oriented Programming but what about ‘S’ in OOPS. If you do not know then it’s fine because it is one of the most confused topics in OOPS. Some say OOPS stands for Object Oriented Programming Structure, for some ‘S’ stands for System and they try to prove their point by saying that there is a famous conference named as Object Oriented Programming Conference and Structure and some say that ‘S’ doesn’t carry any meaning (bullshit). I think it’s all nonsense to argue on the meaning of ‘S’. I think OOP is more of a paradigm than a system. A paradigm which enables us to think in a proper way, a paradigm that gives us the power to better understand real-world problems in terms of programming.

OOP is a paradigm which is organised around Objects rather than Actions and Data rather than logic. If we look at the history we will see that the programming has been more of a logical procedure that takes input as data and performs the logical operation on it to obtain the desired result. OOP in simple words OOP is for Dependency Management.

Fundamental Concept Of OOP

Abstraction

One of the most fundamental concepts of oop is the Abstraction. Abstraction is a powerful concept in OOP. it helps to solve complex problems. Abstraction is a concept of dealing with ideas rather than events. It is a way to combine smaller things to make a bigger thing. Suppose, we want to buy a car. We will go to the showroom and look for the complete car, though it is made of many different small modules that are responsible for their own specific task which when work in cohesion creates a single complex entity, which is in our case is CAR. You will never get to know about the complexity beneath it. That is what abstraction is. A process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics. You will only worry about the looks and feel of the car rather than dig deeper to know how the engine works. Interfaces are the way to achieve abstraction.

Encapsulation

Another fundamental concept of oop is Encapsulation. This is again one of the most misunderstood concepts in “oop” because different people interpret it differently and that creates confusion. You may know encapsulation as the hiding of data members and member functions which would simply mean hiding the internal representation of an object from the view outside of the Object’s definition. Well, it’s not wrong to say that but it is partial definition. Encapsulation can be used to achieve data hiding but encapsulation itself is not data hiding. Infact some OOP languages hiding of components is not automatic or can be overridden; thus, information hiding is defined by yet another notion. There are two parts to encapsulation which is used to distinguish two distinct notions-

1. A language mechanism for restricting direct access to some of the object‘s components.
2. A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

The feature of Encapsulation is often supported by the use of classes, although there are different ways to achieve that.

Inheritance

Third pillar or I should say mechanism to achieve OOP is Inheritance. This is rather one of most important mechanism to achieve OOP. It provides code reusability and power to a programmer to create relationships between multiple objects. It can also be used extend the functionality of some class without changing the actual code of that class. This satisfies the Open/Closed principle of SOLID Design.  

A Good Design

OOP is one of the most used concepts in today’s era. There is no right or wrong design rather a good and a bad makes more sense. Many developers and programmers who have been working in this field has tonnes of experience and has created their own theories and postulates which differentiate one design from another and motivates ones to use which is the best possible design for their application. What I’m trying to say here is that if you do not know what’s best, it is better to refer the design patterns which are known to have worked for many different organisations many times and it will give you that extra confidence because it is already tested by large organisations. You will also get to know about the pros and cons of using that particular design which will help you better analyse it.

If you are going to formulate your own design, then you must make sure you follow and obey the SOLID Design principles. This will make your code clean, more independent, more maintainable and you will avoid smelly code. These principles may sound tough in the beginning but are very easy to grasp.

Let’s take each principle one-by-one,

Single Responsibility Principle, in short, is S.R.P

It simply means that,

A class should have one and only one reason to change, meaning that a class should have only one job.

Open Close Principle in short O.C.P,

It simply means that,

Objects or entities should be open for extension, but closed for modification.

Liskov Substitution Principle in short L.S.P

It simply means that,

Derived classes must be useful through the base class interface, without the need for the user to know the difference.

Interface Segregation Principle

The Interface Segregation Principle states that clients should not be forced to implement interfaces they don’t use. Instead of one fat interface, many small interfaces are preferred based on groups of methods, each one serving one submodule.

Dependency Inversion Principle

Check this document out: The Dependency Inversion Principle.

It basically says:

1. High-level modules should not depend  on low-level modules. Both should depend on  abstractions.
2. Abstractions should never depend on upon details. Details should depend on abstractions.

DIP reduces the coupling between two pieces of code. This can be achieved only when you are more dependent on the concept rather than the implementation part of it. Because you know that changes are risky. It can really complicate or break your architecture in future. Therefore, you must write your code in such a way which is time stable. This can easily be achieved by making your implementation depend on the interface. If your implementation depends on the interface then you get the power to choose which implementation is best at runtime and use that instead.

To provide a summary, the Dependency Inversion Principle is primarily about reversing the conventional direction of dependencies from “higher level” components to “lower level” components such that “lower level” components are dependent upon the interfaces owned by the “higher level” components. (Note: “higher level” component here refers to the component requiring external dependencies/services, not necessarily its conceptual position within a layered architecture.) In doing so, a coupling isn’t reduced so much as it is shifted from components that are theoretically less valuable for reuse to components which are theoretically more valuable for reuse.

Conclusion

OOP is one of the most widely used paradigms in today’s world. The four pillars of OOP i.e, Abstraction, Encapsulation, Inheritance and Polymorphism enables us to write a better code in terms of data rather than logics. If used properly while implementing SOLID Principles in your design pattern then you not only have created an awesome architecture but you are also saved from writing smelly code. That’s how powerful OOP is once you conquer it. I strongly suggest you to read SOLID Design Principles by Uncle Bob which will give you immense insights on the pros and cons of this paradigm and how to avoid the pitfalls.

And As Always,

Be My Aficionado 🙂