Before we delve deeper into technicalities of Object oriented or procedural, let's understand what "approach" on its own stands for. I am trying to delve deeper into the word "approach" because of one plain reason, that most of us fail to demarcate between the concept of means and ends. In any software development endeavor, the most important thing is and should be fulfilling of customer requirements. Rest all is fancy technicalities. I am using fancy, not to put the technologies in a derogatory sense, but to cautious developers from indulging into the self glorification aspect of technologies. As a developer we tend to feel proud of the number of frameworks we know or the intricacies of a server administration we understand. In this, many times the customer requirements are fitted on top of technologies.
Let's get back into our discussion on approach. What is an approach? An approach is a way to solve a problem. Approach represents the means and not the ends. The same problem possibly can be solved using number of approaches. Let's a take a simple example of traveling from one city to another. There are many approaches to do this. Taking a flight to driving on the highway to cycling. Now which approach is better is completely problem specific. If the cities are near by than flight may take longer considering the check in and checkout over heads. Similarly if it is an old cities, near to each other with narrow bylanes, cycling would be a better idea. Now let's delve into our original topic of Object Oriented Approach. Please look into the further discussion, keeping in mind the discussion on approach we did.
Object oriented approach is just one of the way of solving the problem. We will try to understand why it is a good approach in many cases but also what are the pitfalls you should be aware of while working with this approach.
Object Oriented approach takes the notion of object as its center stage. The counterpart of Object oriented approach is the procedural approach. Procedural approach puts procedures/functions as the central theme. The important notions of object oriented approach are abstraction, encapsulation and inheritance. We will not go into the definitions of these as there is enough material on these aspects. Rather let's try to understand how this notions help in building better softwares.
A parallel analogy can be drawn, when a certain idea is adapted into a movie or story. For example, if one wants to write a story of how a princess was rescued from an evil demon by a prince. Most of Hindi movies till some time back were of similar nature. Now to bring this story to life, one has to identify the characters and the backdrops in which the story will flow. These are the elements of the movies and the interaction of these elements in certain sequence brings the whole story out. The counterpart of these elements is objects in the software world. Building of a software is similar to building a story from an idea. Object oriented approach involves in identifying those objects so that they can interact with other objects in some meaningful way. Also Object oriented approach has certain notions which help in characterizing the objects in a better way.
Abstraction is about identifying the elements of a system. For example in finding the elements of our story there are obvious elements like prince and princess. Sometimes the elements are not so obvious. For example who are the friends and associated of prince and of demon. The identification of these elements depends on the context also. In case of software development, the customer requirements will drive the identification of these elements. With abstraction, the other important aspect is granularity. How many elements are used to identify a notion. For example the notion of evil is constructed by one demon or a demon and his Guru.
Encapsulation on the other hand is about characterization of the element. In software terms, we talk about data and behaviour when we talk about encapsulation. For example, the mood of the prince may be a data point, which brings out the emotions of a particular moment. Similarly when princess will call for help, the prince has to run for her rescue. This is the behaviour. Encapsulation is important from the perspective of characterization of the element.
Inheritance is very specific to software world. This one can realise by noticing that you never discuss the inheritance aspect with the customer. But one does discusses Abstraction and Encapsulation elements.(May not be using the terms themselves). Inheritance is mostly a design issue driven more by the need of reusability.
In the discussion we have avoided using the word class and completely relied on the word object to build the discussion. The reason is because class is again specific to software world. It's a means to build the representation of the real world using objects.
Also another important aspect which is specific to Object oriented world is use of interfaces. Use of interfaces is related to the notion of indirection it provides to the system. The interaction of the system is build around the notion of expected behaviour and not how the behaviour is implemented. The underlying behaviour can change as per the context. This is also known as polymorphism.
The most popular principals of object oriented programming approach are:
- Open close principle: Open for extension but closed for change. This means that design in such a way that new behaviour can be added, but the existing behaviour cannot be modified by mistake also. It boils down to using the right access modifiers and also to allow a class to be inherited or not.
- Liskov Substitution principle: This means that working against an interface, it should not matter which underlying implementation is working. The agent interacting with the above element should not have to acquire the knowledge of the specific type.This also drives to Design by contract.
- Dependency Inversion Principle: The different layers of an application should depend on the contracts (in terms of interfaces)
The main advantage of using object oriented approach is that it provides a neat design approach and the maintainability and reusability of the elements is higher. Also by deploying design by contract approach the parts of the systems can be changed without impacting the whole system.
On the disadvantage side, the learning curve for mastering object oriented approach is steeper. Developer often do mistakes by assuming that by knowing how to write a class they know the object oriented approach. It's more about developing the capability to abstract and encapsulate elements in the system and building right contracts between them.