Design Patterns are much talked about yet much feared of, much explained and yet much confused topic. A lot of fundamentals used in Design Patterns are actually application of basic Object Oriented Design principles.
Take example of 'Simple Factory' (or just 'Factory') pattern, which is not actually a pattern but more of a good design practice. Think of a scenario where you need to create a different variant of some class depending on some condition.
E.g. You have a base class House and various sub classes extending House, say Villa, Flat and Penthouse.
Now depending on some user input, say price range, you need to use objects of Villa, Flat or Penthouse to perform some function.
public double getHouseArea(double higherPriceRange){
House house;
if(higherPriceRange < 4000000){
house = new Flat();
}else if(higherPriceRange < 10000000){
house = new Villa();
}else{
house = new Penthouse();
}
return house.getArea();
}
How about this:
public class HouseFactory{
public static createHouse(double higherPriceRange){
House house;
if(higherPriceRange < 4000000){
house = new Flat();
}else if(higherPriceRange < 10000000){
house = new Villa();
}else{
house = new Penthouse();
}
return house;
}
}
public double getHouseArea(double higherPriceRange){
House house = HouseFactory.createHouse(higherPriceRange);
return house.getArea();
}
Awesome right? Yeah. Elementary? Absolutely.
If you noticed we just followed the basic principle of 'encapsulate what varies'. Since the House creation code can vary if any new types of houses are added, we just rounded it off to a separate class. Also this avoids code duplication across various classes.
As I said, this is not a design pattern. It is just a simple design idiom. But whatever it is, no reason for us to not use it!
Take example of 'Simple Factory' (or just 'Factory') pattern, which is not actually a pattern but more of a good design practice. Think of a scenario where you need to create a different variant of some class depending on some condition.
E.g. You have a base class House and various sub classes extending House, say Villa, Flat and Penthouse.
Now depending on some user input, say price range, you need to use objects of Villa, Flat or Penthouse to perform some function.
public double getHouseArea(double higherPriceRange){
House house;
if(higherPriceRange < 4000000){
house = new Flat();
}else if(higherPriceRange < 10000000){
house = new Villa();
}else{
house = new Penthouse();
}
return house.getArea();
}
Now assume there is another similar function and you need to write the House creation code (code in blue) again! And what if we decide to add another type of house to our system, say a Treehouse, we will have to go an alter code in ALL those methods.
Won't it be a better idea to move all this code to a separate place and call that code in all the methods, so that in case of any kind of change, we have to update code in just one place.
public class HouseFactory{
public static createHouse(double higherPriceRange){
House house;
if(higherPriceRange < 4000000){
house = new Flat();
}else if(higherPriceRange < 10000000){
house = new Villa();
}else{
house = new Penthouse();
}
return house;
}
}
public double getHouseArea(double higherPriceRange){
House house = HouseFactory.createHouse(higherPriceRange);
return house.getArea();
}
Awesome right? Yeah. Elementary? Absolutely.
If you noticed we just followed the basic principle of 'encapsulate what varies'. Since the House creation code can vary if any new types of houses are added, we just rounded it off to a separate class. Also this avoids code duplication across various classes.
As I said, this is not a design pattern. It is just a simple design idiom. But whatever it is, no reason for us to not use it!
Comments