Difference between revisions of "DesignPatterns"
From Suhrid.net Wiki
Jump to navigationJump to search| Line 93: | Line 93: | ||
| * What if our client's design expect enumeration interfaces, but our data structure e.g. ArrayList doesn't implement Enumerations but implements Iterator. | * What if our client's design expect enumeration interfaces, but our data structure e.g. ArrayList doesn't implement Enumerations but implements Iterator. | ||
| * We need an adapter to convert the Iterator interface to the Enumeration interface. | * We need an adapter to convert the Iterator interface to the Enumeration interface. | ||
| + | |||
| + | [[File:AdapterPattern.png]] | ||
| [[Category:OODE]] | [[Category:OODE]] | ||
Revision as of 17:10, 17 December 2011
Contents
Intro
- A design pattern systematically names, explains, and evaluates an important and recurring design problem and its solution.
- They capture the intent behind a design by identifying objects, collaborations, and distributions of responsibilities.
- They capture static and dynamic structures of successful solutions to problems.
 
- Patterns support reuse of software architecture and design.
- They give software engineers a vocabulary with which to describe their designs.
- Patterns solve design problems such as:
- Finding appropriate classes to solve a problem.
- Determining how abstract or how concrete a class should be.
- Specifying interfaces of classes, architectures, and binary components.
- Designing for change.
 
- Patterns are not code-reuse they are experience reuse !
Facade
Intent
- Provide a common interface to a set of interfaces within a subsystem.
- Defines a higher level interface to make the subsystem interfaces easier to use.
Motivation
- Provide a simplified interface.
Consequences
- Shield clients from myriad subsystem components - hence promote weak coupling between clients and subsystems.
- Reduces number of objects clients have to deal with.
- Using a facade promotes decoupling between the client and the subsystems.
- Note that clients can still access the subsystems directly.
- Clients make a choice between ease of use and fine grained control (through direct access of subsystems).
 
Examples
public class Compiler {
  public Compiler();
  private Node node_tree;
  private Scanner scanner;
  private Parser parser;
  private Risc_CG generator;
  public void compile() {
   node_tree=parser.parse(scanner);
   generator.emit(node_tree);
   .....
  }
}
- The Compiler class is a facade to various sub system interfaces (Node, Scanner, Parser, Generator) that comprise a compiler.
- The compile() method provides a high level interface to the whole process of compiling using various subsystem interfaces.
- Here's one more example of a HomeTheatreFacade which simplifies the operation of various subsystems of a home theatre.
public class HomeTheaterFacade {
   private Amplifier amp;
   private Tuner tuner;
   private DVDPlayer dvdPlayer;
   private Projector proj;
   private Lights lights;
   private Screen screen;
   public void watchMovie() {
     lights.dim();
     screen.down();
     projector.on();
     amp.on();
     amp.setVolume(5);
     dvd.on();
     dvd.play();
   }
}
Adapter
Intent
- Convert the interface of one class into another interface that clients expect.
- An adapter would let objects work together, that otherwise wouldn't because of incompatible interfaces.
Motivation
- There is a class that provides required functionality, but does not support the interface the design needs.
Example
- The enumeration interface allows us to step through elements of a collection.
- However, there is now a new Iterator interface which has more functionality.
- What if our client's design expect enumeration interfaces, but our data structure e.g. ArrayList doesn't implement Enumerations but implements Iterator.
- We need an adapter to convert the Iterator interface to the Enumeration interface.

