Design Patterns

Document Sample
Design Patterns Powered By Docstoc
					Design Patterns
                    Design pattern

 Design pattern is a solution to a problem, which occurs over
and over again.

Pattern elements:

• Name    – a handle we use to describe a pattern in a word or
            two
• Problem – describes when to apply a pattern

• Solution – describes a set of design elements which solve a
             problem
• Consequences – benefits, disadvantages, constraints
                     Pattern types
E. Gamma classification:

 Structural patterns – solve objects composition problems
    Abstract Server, Adapter, Bridge, Proxy ...

 Creational patterns – abstract the instantiation process and
make a system independent on how objects are created
    Abstract Factory, Factory Method, Singleton ...

 Behavioral patterns - algorithms and the assignment of
responsibilities between objects
     Chain of Responsibility, Command, Iterator, Observer,
    State, Strategy ...
         Abstract Server: Problem




Problem:
- Button is not reusable in a context not involving a light
            Abstract Server: Solution




Solution: break dependency between Button and Light by
inserting an interface
              Abstract Server: Pattern
                          -server   <<Interface>>
             Client
                                    AbstractServer




                                        Server




Benefits:
- decouples clients from their servers
- servers can be changed without affecting clients
- eliminates DIP violation
                Adapter: Problem




Problem:
- Light already exists and can’t inherit from Device
- Device might have messages activate/deactivate
                    Adapter: Solution




- use an adapter to convert one interface to another
                     Adapter: Pattern
                -server   <<Interface>>
   Client
                          AbstractServer




                                            -server
                          ServerAdapter               Server




Also known as: Wrapper
Benefits:
- breaks dependency between client and server when server exists
- allows different servers to be swapped in and out
                    Adapter: Pattern

                -server   <<Interface>>
   Client
                          AbstractServer            Server




                          ServerAdapter




A variation, which allows server methods to be redefined
         Abstract Client: Problem




Problem:
• Server needs to send callback message to client
• GUI Button is not a reusable class
• Callback method makes Device unreusable
              Abstract Client: Solution




 Server provides interface for client to use
              Abstract Client: Pattern




 Q: What package should contain AbstractClient class ?
 A: Server’s package
                 Adapted Client
Problem:
       GUI library components (JButton) do not implement
       StateListener
Solution:
       use Adapter pattern along with Abstract Client


           GUIButton               StateListener




          ButtonAdapter               Device
              Singleton: Problem

Problem:
   • How many database objects do we need in a simple
   program?
   • Would it be a bad thing is someone mistakenly created
   more?

Solution:
   • prevent programmers from making objects.
       • Make constructors private or protected.
   • make the class responsible for making the one and only
   object
                  Singleton: Solution
                    class CompanyDb {
                     private:
                        static CompanyDb* db;
                        CompanyDb();
                         ~CompanyDb();
                     public:
                       static CompanyDb* Instance() {
                         if( 0 == db ) return db = new CompanyDb();
                         return db;
                       }
                       Employee* getEmployee( const char* name );
                    };

Use singleton when:
• there must be exactly one instance of a class
• it must be accessible to clients from anywhere inside the
program: CompanyDb::Instance()->getEmployee(“Leha”);
                        Monostate
 Solves the same problem as Singleton
 All members are static
 Constructors and destructor are private

Class CompanyDb {
  private:
    static Db db;
    CompanyDb();
  public:
   static Employee* get Employee( const char* name );
}
Db CompanyDb::db = Db( “CompanyName” );
Employee* CompanyDb::getEmployee( const char* name ) {
  return db.find( “Employee”, name );
}
Employee* emp = CompanyDb::getEmployee( “Leha” );
         Singleton vs. Monostate

Construction:
   • Singleton has lazy construction
       • Don’t pay unless you need it!
   • Monostates are always constructed
   • Singleton can have non-trivial constructors
   • Monostates can’t have non-trivial constructors

Destruction:
   • Singleton destruction is not defined
   • Monostate destructon is well-defined
               Strategy: Problem




Problem:
- different employees are paid differently
- what if we need to add hourly paid manager ?
- hierarchy is hard to maintain
                   Strategy: Solution




 PaymentPolicy specifies an algorithm for payment calculation
                      Strategy: Pattern




Also known as: Policy
Benefits:
- different strategies can be swapped in and out
- context is closed to changes or additions of strategies
                 Bridge: Problem
                      Window




            XWindow             PMWindow




          XDialogWindow        DialogWindow




Problem:
- Client code depends on platform
- To support a new platform, we need to reproduce all Window’s
derivatives
                        Bridge: Solution
                              Bridge
               Window                       1       WindowImp
               drawText()                            drawText()




  IconWindow       DialogWindow    XWindowImp               PMWindowImp
                                       drawText()             drawText()




All operations on Window subclasses are implemented in
terms of abstract operations from the WindowImp interface
 Makes Window and its subclasses platform-independent
 Q: How to make clients independent on WindowImp
subclasses?
                    Bridge: Pattern




Also known as: Handle/Body
Benefits:
- Eliminates DIP & OCP violation
- Increases maintainability
                  Proxy: Problem




Problem:
we need to store our objects in relational database, but we don’t
want the clients to depend upon the details of the database
schema
                      Proxy: Solution




Solution:
- use a surrogate that knows the details of the database
- clients think they are interacting with RealEmployee
                       Proxy: Pattern




Also known as: Surrogate
Applicability:
 - remote proxy
 - virtual proxy (creation of real object on demand)
 - protection proxy (for example: ACL support)
       Abstract Factory: Problem
                                      <<Interface>>
         Client
                                          Shape




                             Circle                   Square
              <<creates>>


                            <<creates>>



Problem:
 - creating objects creates a dependency on a concrete type
 - all other manipulations are done through interface !
                   Factory: Solution




Make a class whose responsibility is to make objects
Making objects can’t be avoided, but can be contained
                     Factory: Pattern




Isolates concrete classes, makes Types family changes easier
     Stairway to Heaven: Problem




Problem:
- We wish to make an hierarchy of classes persistent, but we
don’t want to depend upon the vendor of our database
              Stairway to Heaven: Solution


Knowledge                                         Knowledge of
of business                                        persistence




 Use Adaptor pattern at each level in the hierarchy
  Requires virtual multiple inheritance

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:8/27/2012
language:English
pages:32