In real life software development one particular challenge we developers constantly face is requirement changes. Anyone who is in the software business game knows how frequently and drastically software specification can change in any time. For this reason, in software engineering only one thing is considered as constant: CHANGE!
In object oriented world, we have some nice ways to deal with this, i.e. design patterns to the rescue. There are lots and lots of design patterns out there to help us, the developers. Amongst them the most common and widely used one is known as Strategy Pattern. Any developer with a few years of experience under his/her belt uses this quite frequently (sometimes even without knowing they are using it!).
In this post I am going to try to create a scenario, which we can solve using strategy pattern.
We all know the three basic principles of OOP: Encapsulation, Inheritance and Polymorphism. And there is also this fourth principle: Data Abstraction; though it’s not always mentioned as a standalone principle, as it is closely tied with encapsulation. Today I am going to discuss a simple case to display the power and necessity of Inheritance.
Let’s assume a scenario: you are working on an application, which has to perform a server call asynchronously and has no direct impact on the UI. But when the server returns a response, you have to make some modification to your application regardless of the present UI.