Observer Design Pattern: A better approach to OOP

Object oriented programming makes it way too easy to model real world processes and put them in the programmer’s language, the source code. The source code of any application is the black box for the state and behavior of an application in the real time. Although OOP is a great leap towards programming in real time, it could be made way too easier if we could think of few important aspects of programming. One of the important features of OOP is inheritance, which is a powerful tool to manage and manipulate behavior in large, enterprise class applications. But, inheritance too could be tiresome if we have a better way to reduce the code and make it easier to manage.

Signatures via interfaces:

While we are onto implementing code reusability in our program, we are required to create a base class from which every other class could be inherited. This would be like making a ‘mama-class’ in our object and then making her give birth to a new class, every time we need, just to suit our context and purpose. But this concept of signatures makes the use of an interface, which is basically a class with the behaviors mentioned in it without the precise definition of each behavior. You could think of it as this, in an application of vehicles, we define a vehicle interface with the functions of Start(), GoForward(), GoBackward(), Stop() etc. These functions are just what we need of a vehicle. For now, in an interface, we just mention what is required of the vehicle object and not the specifications of how and what-if conditions. Later on, on every new object such as cars, jeeps or SUVs, we will define how each of the functions is accomplished.

A classical OOP genius would argue this method of being long and tedious as we are required to put up the definition in every object that we create of the vehicle type. Inheritance would just require the definition of the function only once, in the base class, and later it could be used directly. But, if I made a abject, Motorcycle then simply inheriting would allow the Motorcycle object to move backwards as well, while in the real world, motorbikes DO NOT have the reverse gear system. Bam!

Okay, now while we agree to use signatures over inheritance, it would be better if we would not require the functions to define in each new object that we define along the way, wouldn’t it? And that is just what could be done using segregation process.

Code segregation:

If you’ve got some aspect of your code that is changing, say with every new requirement, then you know you have got a behavior that needs to be pulled out and separated from all the stuff that doesn’t change. (Head First Design Pattern, Freeman & Freeman, 2004). This means to tell us that things could be made a lot simpler if we separated the varying features of our class and each of the features that varies be given a signature. Hence, in the above example, the GoBackward() method is redefined in a new interface, say ReverseMovement(). Now, what we could do is, design a class that implements the ReverseMovement() behavior down to its details. In this way, now if we needed GoBackward() function at any instance of our class, all we need to do is inherit the ReverseMovement() class, just as in classical OOP approach. This way, the changeable feature is now only a few blocks away than being locked up in the base class ‘vehicles’.

Ding! While I talk about the signatures and interfaces, a thing might pop-up in your brains called the “Abstact Class”. There is a question, could this implementation not be done using abstract classes? One possible answers could be why waste $100 in an Xbox if you can get it for 15 bucks? Defining interfaces ensures the CUP is least utilized and the memory is optimally occupied by other relevant processes. Interfaces allow us to remain care free about the type of object that is required to be instantiated at runtime, thus giving us the dynamic flexibility.