Adapter

You need to recharge your mobile phone to call your family.

The problem is you come from France and you are still in Japan on business.

What are the options to solve this problem ?

1. Modify your phone charger to be able to connect it to the japan socket.
2. Buy another phone charger.
3. Buy a simple adapter.

Solution 1:

• The problem is your charger won't work when you'll return in France.
• If you modify your charger you may break it.
• You have to know exactly how your mobile charger works.

Solution 2:

• It would be expensive
• Maybe there is no charger available in Japan for your mobile.
• You'll have two chargers to do the same thing = to recharge.

Solution 3:

• It seems to be the less expensive solution.
• You'll be able to recharge your phone when you'll return in France.
• You'll be able to use the same trick in other countries.

THIS IS THE ADAPTER DESIGN PATTERN !!!

When you will be in the same situation =

You must keep your old objects but use new or external API.

Don't modify your objects, just make adapters !!!

Your adapter will implement/extend the expected interface/class.

Your adapter will contain an instance of the class it wraps.

Your adapter will make calls to the instance of the wrapped object.

Facade

What happens when you switch on your laptop ?

- It loads the BIOS
- It detects hardware
- It finds a bootable device
- It loads the boot sector (MBR)
- It loads and executes the operating system kernel
- It displays a login screen

All these steps just clicking on the Power Button :)

THIS IS THE FACADE DESIGN PATTERN !!!

When you will be in the same situation =

You have lot of classes and it begins to become complex.

Don't make a long documentation, just make facades !!!

Your facade will provide a simplified interface to your functionalities.

You will be able to change the implementation with no impact.

It will be more easy and quick to use your functionalities.

Composite

You have to make a program for a car maker company.
Your program has to calculate the factory price of each car.
You have the prices of the car parts.
You have the list of car parts of each car.
To test your program the company gives you the factory price of the XYZ car.

You made your program and launch it with the XYZ car.
Of course, the price that you program found is different :)

After some hours to find a bug in your code... you understand.
In the list of prices there are some bundles of car parts.
These bundles are sometimes less expensive than the sum of car parts prices.
Some car models use these bundles... and the XYZ model too.

You understood so you modify your code to fix the problem.

1. A "car" is not a parts list but a tree structure of components.
2. A component can be :
   • a car part
   • a bundle (= composite) composed by other components
3. A component is able to give his price.
• Car part
  • you already know the price
• Bundle (= composite)
• maybe you already know the price
• else the price is the sum of his components prices

THIS IS THE COMPOSITE DESIGN PATTERN !!!

When you will be in the same situation =

A group (tree structure) of different objects have to be treated in the same way.

Don't make "if/else" block to manage each case, just apply composite.

You will declare the common treatment in a X interface ("Priceable" in example).

Your classes will implement the X interface.

You will make a Composite class (implementing X too) to group your X objects.

Bridge (aka Driver)

You work with your team on a free photo editing sotfware.

Your are in charged of develop the part to print the photos.

In the office, you have a Canon PIXMA InkJet Printer.

So you contact the canon support team to get some documentations.

You need to have the API 's to use with their printers.

You develop the module to be able to print with this printer.

You test, it works, you're very happy !!!

BUT how do you do if you want to print on another printer ?

Your program and the printer are too much close.

You have to put a "bridge" between them.

This bridge will be a kind of contract between them.

This contract will contain all possible usages.

You understood, it defines how to "drive" the printer.

The program promise to use it to contact the printer.

The printer promise to response to each usage.

THIS IS THE BRIDGE DESIGN PATTERN !!!

When you will be in the same situation =

Your program has to work with a "part" that can changed.

Don't redevelop each time, just implement drivers !!!

You will define in an interface what your program needs.

You'll implement this interface for the "part" = his driver.

Your program will load and use only the interface.

If a new "part" appears, you'll just implement the driver for it.

Singleton

Some days ago I saw an advertisement for a french bank.
A couple is entering in a bank to make a credit to buy their home.
A bank employee is taking the couple to his office.
During the short walk the couple and the employee are discussing.
Nonetheless between each question the employee is not the same person.
The couple are taking fright and so leave the bank.
At the end, there is a message like :
"In our bank, your projects will be followed by the same person for several years"

THIS IS THE SINGLETON DESIGN PATTERN !!!

When you will be in the same situation =

You have/prefer to keep the same object during your program execution.

Don't give the object to all your methods, just use a singleton !!!

Your singleton will instantiate a new object only the first time.

It will more easy to get the object anywhere.

If you want to change how to instantiate it, you will change it only at on place.

Observer (aka Listener)

I used to use "Google Reader" to keep informed about development news.
It's a simple & free RSS reader with a mobile & web interfaces.
With it, I can subscribe to RSS feeds that I wish.
I am directly informed of these news & events.
I can choose to read to full article or do nothing.

THIS IS THE OBSERVER DESIGN PATTERN !!!

When you will be in the same situation =
You want to keep informed of changes but to choose to act or not.

Don't make objects asking if changes happened, just make observers !!!

The observers will implement an Observer interface.

The observable objects will implement an Observable interface.

The observers will be able to be referenced to the Observable objects.

The observers will be notified when an event will happen.

Mediator

The life is wonderful due to you can do millions of things.

You can speak with people, play a sport, travel around the world...

Imagine you want to go to Japan... yes, I would go back :)

You can't choose yourself your plane, your seat or your pilot.

You just contact an airplane company and choose your dates and destination.

It's the same for lot of other things.

If you want a laptop, you contact a reseller, not the manufacturer.

THIS IS THE MEDIATOR DESIGN PATTERN !!!

When you will be in the same situation =

The communication between your objects become too much complex.

Don't add new methods in your classes, just make mediators to manage it.

The objects will discuss/work only with the mediator.

All the communication between objects will be encapsulated in the mediator.

Best way:

- Mediators implement interfaces to be able to change the implementations.

- Mediators use interfaces instead of concrete objects to manage several objects.

Proxy

Sometime there is already a process or program in place.
Let's take the example used for the driver design pattern.
The is program able to print on printers.
You want just to add some actions : logs, checks, restrictions...
Of course, you don't want break this existing program.
You just want add a layout between the program and printers.

THIS IS THE PROXY DESIGN PATTERN !!!

When you will be in the same situation =
You want just to add actions around existing methods.

Don't modify objects adding your actions, just make a proxy !!!

You proxy will implement the same interface that your object.

Your proxy will contain your object.

Each method of the interface will call the same method of the object.

You will be able to add actions before, after, modify parameters...

Chain of Responsibility

There was 100 years ago, Ford Motor Company made the T-Model.
The revolution was to use an assembly line production.
This kind of production is always used nowadays.

The car is put on a conveyor belt.
The car has to cross some steps before to be considered like finished.

If there is a problem at only one step, the car won't go to the next steps.

These main steps are:

1. Remove the doors
2. Install the dashboard
3. Install the seats and windows
4. Install bumpers
5. Install the engine
6. Install brakes and suspensions
7. Put the doors back
8. Install the wheels
9. Adjustment
10. Check

THIS IS THE CHAIN-OF-RESPONSIBILITY DESIGN PATTERN !!!

When you will be in the same situation =

An object has to be subject to a series of processes, checks, treatments, ...

Don't code these treatments in the same place, just make a chain of responsibility.

All the treatments will implement the same interface.

So it will be easy to create a new treatment.

Each treatment will know the next treatment and call it if all is ok.

The object just will cross all the treatments without know them.

You can have a central object containing the chain.

This object will be able to add a treatment at the end of the chain.

Links with other design patterns:

We can change one ore several steps of the chain by a composite easily.

Flyweight

Everyone has already played with a deck of playing cards.

A deck is composed by 54 cards or 32 cards.

Each card is unique and between each party we keep the same cards.

The only rule to respect is don't damage (or modify) the cards.

In the real life 2 parties can't used the same deck in the same time.

But in the development world it's not a problem due to you can.

THIS IS THE FLYWEIGHT DESIGN PATTERN !!!

When you will be in the same situation =

You have a set of defined objects that you use without modify them.

Don't instantiate a new object for each usage, just use flyweight !!!

You will centralize all the different objects in the same place.

It will more easy to find the instance that you need.

Sharing these objects, you will minimize the used memory.

Factory Method

When you go to a restaurant to eat a pizza,
you don't expect to cook your pizza your-self.
First because it's not your job,
next because maybe you have not the skills.
Someone else is here to do it for you.

THIS IS THE FACTORY METHOD DESIGN PATTERN !!!

When you will be in the same situation =

You need to create an object but you don't care how it was made.

Don't instantiate the object your-self, just use a factory method !!!

Each object will do only his own job.
You will be able to make a new implementation of the factory easily.
You will be able to change the instantiationby changing at one place.

Abstract Factory

Everyoneone has already eaten a cheese pizza.
It depends on the restaurant, it could be good or bad.
Nonetheless each restaurant calls it "cheese pizza".
Because it respects the "cheese pizza" recipe.
There are lot of pizza restaurants.
The fact is they don't make their pizza in the same way.
They are called"cheese pizza" but they aren't identical.

THIS IS THE ABSTRACT FACTORY DESIGN PATTERN !!!

When you will be in the same situation =
The client does not need to know (or care) which concrete objects it gets.

Don't return concrete objects, just use an abstract factory !!!

The abstract factory will define the factory methods to implement.
These methods will return generic interfaces.

The concrete factories will implement the abstract factory.

They will build the objects in their own way respecting the interfaces.

Prototype

You work in a company.
You signed a contract of employment.
Your colleagues have done the same thing.
These contracts are very similar.
The employee's name, address and wage change.
Would it not be easier to clone a contract
then just change this information?

THIS IS THE PROTOTYPE DESIGN PATTERN !!!

When you will be in the same situation =
Only some information change between complex objects.

Don't create these objects from scratch, just clone and modify them !!!

Your program will be faster with objects ready to clone.
You can create several prototypes if there are many cases.
If a new constraint has to be added in all your cloned object,
just add it in your prototype.



Links with other design patterns:

You can change store all your prototypes into a static class = flyweight design pattern.

Builder

There are several kinds of pizza.
There are cheese pizza, white sauce pizza, etc.
However, to ma a pizza, there are always:
- Make pizza dough.
- Make the pizza sauce.
- Make a pizza topping.
So to make a pizza there are essential steps to follow.

THIS IS THE BUILDER DESIGN PATTERN !!!

When you will be in the same situation =
there are always the same steps to build an object.

Don't let people build their objects as they want, just use the builder pattern !!!

All the implementations will follow the same way.
It will be easy to add an implementation system.
A director class will be in charged of call the building methods.

Decorator

Everybody has already moved into an apartment.
When you get inside, you personalize it.
You're not going to break the walls.
The apartment is an apartment.
But you hide things you do not like.
You repaint one or two rooms.
Maybe you install some new furniture.

THIS IS THE DECORATOR PATTERN DESIGN !!!

When you will be in the same situation =
You want to add/remove (=decorate) dynamically functionalities to an object.