Dev Diary 01 - Let's Talk About The Strategy Pattern
As developers, we almost always start with Object-Oriented principles. This is very useful and lays the foundation for numerous other code optimizations later on. However, this alone is not enough to help us create maintainable code. Let me first start off with an example where using just these principles does not result in a concise codebase.
The Inheritance Problem:
Pretty much every coding book and online resource talks about how inheritance helps to reduce the overall codebase and promote code reuse. This for the most part is true. The place where this fails is when we have different features in different classes that inherit a specific main class.
Simple example of inheritance. src
Take for example vehicles. All vehicles can be driven. All vehicles get us from point A to point B faster. So, creating a main class and inheriting this in all the sub-classes like car, bike, the plane might seem efficient. However, the bike only has 2 tires, the car has 4 and a truck can have 6-8 and sometimes even more. Additionally, features such as a horn, etc all change as well.
So, inheriting the main superclass in all subclasses is not always a solution. This works only if all the sub-classes have the exact same features as the superclass.
Interface to the rescue?
Well, if you guys have dabbled with OO languages, you would have come across interfaces. So, let's see how interface could help us here.
So, with interface, we could probably group all the common features in an interface and then implement the custom features in the sub-classes themselves right?
This does help reduce a bit of code. However, in a long run, if more different types of vehicles come into existence, we are screwed. The code can soon become extremely hard to manage.
So, now what? We have literally used the object oriented features that we are aware of and yet the code can soon become really hard to maintain. This is why design principles are extremely important. Being able to use the various OO concepts to reduce the final code is what make them so important.
The Strategy Pattern:
One of the most used phrase I came across was "Program to interface, not implementation". To do this, we would need to pull out the varying features of vehicles like the horn, wheels, mode of transport, etc and create an interface of it. We then need to create separate implementation of these characteristics in concrete classes. Forexample, bot aeroplane and a car can move from point A to point B However, one goes on the road while the other flies in the sky.
By implementing these are separate classes and extending it to the same interface, makes our code more maintainable and also understandable. So, let's say we need to support a new vehicle like a ship, we just create a new implementation of ship and extend it to the interface. This interface can now be used in any class that might need the ship attributes.
Changes to be made in my code base?
Well, this doesn't entirely apply to my codebase yet. However, one place where I can see the usage of inheritance is with SteemChillers API response Right now all the endpoints that I call respond with several common fields. In my codebase, all of them have their own objects. So, I could just inherit the common attributes into all the response classes. Thereby reducing the overall code size.
I'm sure I'll find several design patterns that will help me make my codebase easier to manage in the long run.
It is highly recommended to first get a rough orientation of the planned development. This also allows you to estimate which data structures you need and which objects. Certainly also a first relation between the objects or their attributes and methods will be considered. There can be also estimated approximately, at which parts an inheritance makes sense and where better interfaces are used.
However, the programming language must also support this. Python, for example, supports inheritance very well, but has no classical means for programming interfaces. You can do something with
Exceptions, but it is not nice. Javascript also only knows inheritance.Java and C++, on the other hand, support both variants.
So if you prefer programming in Python or Javascript, you have to forget the interfaces anyway. So the above considerations and the choice of programming language play a big role and intertwine.
This is not really a problem (you can define an attribute
tiresin the superclass - if all objects have wheels at all ;-) - and initialize it in the constructor of the child class with the appropriate number :-) ).Child classes can of course have their own attributes and methods. In fact, only the common properties should be defined in the parent class. Also, there are the possibilities of overwriting or overloading.... :-)
Yes, this is very comfortable. Especially because the response contains the respective columns with the indices where the information can be found in the rows. :-)
The encapsulation in an answer class is a good idea!
Ahh... I see where I messed up here. I meant to include things like ships over here and went with trucks. Error on my part. But, you get the point I tried to make.
With respect to overloading, I'd need different parameters in each overload. In the case of vehicles, if we are talking about tires, the overload would always be an integer and we cannot differentiate with that.
Totally! The mistake I made was I never went through the entire documentation initially and used the endpoints as and when I needed them. Now, going back and redoing those are a pain in the butt😅 But, that's something I will need to eventually get to anyways.