Head First Design Pattern summarize / chapter 1
Teaching the concepts that you’ve learned to others, is the best way to assure that you fully understood them.
based on the previous statement I decided that it’s time to affirm what I have learned from the ‘Head First Design patterns ‘ book by summarizing each chapter in a separate article.
This article is about chapter one. which is called “ Introduction to design patterns”
Here in the first chapter, the writer wants you to feel about what’s exactly the need for the design patterns in a real example.
So the chapter starts with an example of an app, It’s a successful duck lack game, SimUDuck. The game can show a large variety of duck types swimming and making quacking sounds. The initial designers of the system used standard OO techniques and created one Duck superclass from which all other duck types inherit.
At this moment everything is great until the company decided to extend the app and add onemore majestic feature to it.
And the feature was to add flying ducks to the app.
Thinking directly in a simple way leads to just add the fly() function to the Duck superclass, note that all the subclasses inherit from Duck superclass then this will lead to having all the ducks types flying in front of us !!!!!! too bad result.
Also the solution of making the fly() function here as an abstract function then override it as to do nothing at the types of ducks that don’t fly will lead to keeping overriding to each new Duck subclass that’s ever added to the program forever.
So the concolsion is that inheritance is not the answer, time to think about the interface concept.
let’s make the Flyable Interface and let the new flying ducks implements the Flyable interface. But while having the subclasses implement Flyable interface solves part of the problem (no inappropriately flying rubber ducks), we will creat a different maintenance nightmare by completely destroing code reuse for those behaviors.
Because whenever you need to modify behavior, you’re forced to follow and change it in all the different subclasses where that behavior is defined, probably introducing new bugs along the way!
At this point, you might be waiting for a Design Pattern to come and save your day.Here we will introduce our first design principle.
‘It’s about taking the parts that vary and encapsulate them so that later you can alter or extend the parts that vary without affecting those that don’t.
So we will separate the fly behavior from the Duck class.
And here we will learn one of the most important design principles.’
keep in mind that we didn’t mean here by interface exactly the java interface construct instead we mean the supertype class.
The point is to use polymorphism by programming to a supertype so that the actual runtime object isn’t locked into the code. And we could put in other words “program to a supertype” as “the declared type of the variables should be a supertype, usually, an abstract class or interface, so that the objects assigned to those variables can be of any concrete implementation of the supertype, which means the class declaring them doesn’t have to know about the actual object types!”.
According to this diagram in our Duck class, we will initiate a QuackBehavior and a FlyBehavior instance,
And we will have performQuack and performFly functions and we will delegate to the behavior class.
And for any new duck type, we initiate the type of the fly and quack behavior in the constructer or by using a set function to set the behavior type .
Know whenever we need to add any new fly behavior in the future suppose ‘ fly with a helicopter ‘ we just create a new class FlyWithHelicopter class that implements the FlyBehavior interface and override the fly() function, and whenever we want to modify this new fly behavior function we just go to class FlyWithHelicopter class and modify the fly function.
In this introductory chapter and after we dive into this Duck app we finally introduce strategy pattern.
‘The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.’
which leads us to the next article that talks about observer pattern in chapter two at this link
*the two previous diagrams were taken from the book.
