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.
