Your SlideShare is downloading. ×
Design Patterns
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Design Patterns

392
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
392
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. DESIGN PATTERNS
    • DESIGN PATTERNS
      • Partial solutions (self-contained components) that are (re)usable in building larger systems
    • SOME AREAS OF PATTERN USAGE
      • A common interface component (allowing different subsystems to co-exist seamlessly)
      • A wrapper/adapting component (provides plug-ins to sets of legacy or externally developed subsystems)
      • An abstract view (encapsulating and hiding the specificities of underlying subsystems)
    • WHAT IS A DESIGN PATTERN
      • An software composed of a few classes, which provide interfaces that support inheritance and delegation mechanisms for ‘gluing’ user developed applications for constructing large, modularized, component-based software systems. Classes in patterns can be adapted and refined (effortlessly) to suit various project designs.
  • 2. ABSTRACT FACTORY PATTERN - Encapsulation
    • PURPOSE
      • If developing an application to run on a variety of platforms. Each platform can have its own specific or concrete environment (CPU type, OS type, DBMS type, GUI type, etc.), and still, this application can access/interact with each platform (without changing it each time) THROUGH the Abstract Factory Pattern
    • DESCRIPTION
      • Each platform is represented by a Factory class, with concrete subclasses under it. Each concrete subclass support a platform concept (e.g, window, button, slider, menu). The Factory class contains methods for ‘creating’ or ‘instantiating’ a concrete type below it Thus, when the platform is changed, only the Factory class methods have to be reworked to conform to the new platform(s) concepts.
    • EXAMPLES
      • Fig 7-28
      • Swing – JFC dynamic interface concept modeling
    • RELATED TO
      • Other patterns and concepts that foster reuse and hiding/removal of dependencies (hw and sw)
  • 3. Figure 7-28. AbstractFactory design pattern (UML class diagram, dependencies represent <<call>> relationships). This design pattern uses inheritance to support different look and feels (e.g., Motif and Macintosh). If a new specialization is added, the client does not need to be changed.
  • 4. THE ADAPTER PATTERN – Legacy Wrapper
    • PURPOSE
      • A completely external system (legacy) that is needed to support a new application. The desire may be to replace the legacy system with, yet, newer or variation of it. None of these changes should impact the new application.
    • DESCRIPTION
      • The new application can call (using a set of calling functions internal to it) the resources of the legacy system. Of course, the legacy system’s calling-interface has different syntax and semantics; which are different from the new application’s calling procedure. An Adapter class serves as the ‘go-between’, by implementing an Interface using methods from the legacy system. The new application then calls the Interface, not directly to the legacy system.
    • EXAMPLES
      • Fig 6-34, Fig A2
      • (E.g., NewInterface implements the new-request to sort, passing in its parameters what-type to sort and the order. The Adaptor implements the MyStringComparator method, which in turn uses the LegacySystem’s basic sorting operations via calling)
    • RELATED TO
      • The Bridge pattern, which bridges that gap between an interface and its implementation
  • 5. THE BRIDGE PATTERN – Bridging alternative implementation via single interface
    • PURPOSE
      • Situations where ‘choices’ or alternative implementations of an algorithm, e.g., are desired; but the application need not change for each implementation usage. The Bridge patter abstracts the implementations’ interface from the application. Thus, the interface and the implementations are decoupled (either or both can be modified independently).
    • DESCRIPTION
      • First, an ImplementorInterface class is defined with methods, which provide services to the Abstraction class. (Remember, the application is shielded from the mutations of the ImplementorInterface through the Abstraction class.) The ImplementorInterface then subclasses all the possible concrete implementations (via generalization and inheritance).
    • EXAMPLES
      • Fig 6-37, Fig A3
    • RELATED CONCEPTS
      • The Adapter Pattern (complementary)
  • 6. ODBC Implementation ODBC imp Figure 6-37. Bridge pattern for abstracting database vendors (UML class diagram). Removing the dependency from database vendors from the systems provides more flexibility. Oracle ODBC Driver DB2 ODBC Driver Informix ODBC Driver
  • 7. THE COMMAND PATTERN – Encapsulating control (menu-style optioning)
    • PURPOSE
      • Isolation/clustering of related set of commands, which the application calls for but only through the Command abstract class. The Command class maps the called command into concrete command class. These concrete command classes contain simple ‘execute-type’ methods, which simply invokes the desired/called command in the set. In this way, command implementations are not scattered across different objects, and new concrete commands can be added/subtracted without disturbing the application
    • DESCRIPTION
      • The Command class interface defines the common services (implemented by all the concrete commands – more like a menu or list of command prototypes). Applications, or clients, request for services of interest via the Command abstract class
    • EXAMPLES
      • Fig 6-45
    • RELATED TO
      • MVC architecture (Fig 6-15)
  • 8. execute() MenuItem PasteCommand execute() Command execute() Menu Application * * copy() paste() Document execute() CopyCommand Figure 6-45. An example of a Command pattern (UML class diagram). In this example, menu items and operations on documents are decoupled. This enables us to centralize control flow in the command objects ( CopyCommand and PasteCommand ) instead of spreading it across boundary objects ( MenuItem ) and entity objects ( Document ).
  • 9. Figure 6-15. Model/View/Controller architecture (UML class diagram). The Controller gathers input from the user and sends messages to the Model . The Model maintains the central data structure. The View (s) display the Model and is notified (via a subscribe/notify protocol) whenever the Model is changed. Controller Model subscriber notifier initiator * repository 1 1 * View
  • 10. COMPOSITE PATTERN – Synthesis of systems via recursive hierarchies
    • PURPOSE
      • Services in the containment (class) hierarchy are factored out, and reachable via inheritance. In this way, the leaf nodes (lowest level of the tree-like structure), implement the modifiable services.
    • DESCRIPTION
      • The Composite class (which houses the services) is an aggregate of the services or leave nodes, where the services are shared. The leave methods do the actual operation of the services requested.
    • EXAMPLES
      • Fig 6-3, Fig 6-8, Fig 12-6
    • RELATED TO
      • Façade pattern
  • 11. Figure 6-3. Subsystem decomposition (UML class diagram).
  • 12. Figure 6-8. Alternative subsystem decomposition for the decision tracking system of Figure 6-7 (UML class diagram). The coherence of the RationaleSubsystem and the PlanningSubsystem is higher than the coherence of the original DecisionSubsystem . Note also that we also reduced the complexity by decomposing the system into smaller subsystems. subtasks * assesses solvableBy resolvedBy based-on * * * implementedBy RationaleSubsystem PlanningSubsystem Criterion Alternative Decision DesignProblem SubTask ActionItem Task
  • 13. Figure 12-6. Model of the software life cycle (UML class diagram). A software life cycle consists of process groups, which in turn consist of processes. A process accomplishes a specific purpose (e.g., requirements, design, installation). A process consists of activities, which are in turn consists of sub-activities or tasks. Tasks represent the smallest piece of work that is relevant to management. Tasks consume resources and produces one or more work products. A project is an instance of a software life cycle.
  • 14. THE FAÇADE PATTERN – Presenting a unified interface for subsystems
    • PURPOSE
      • Reduces dependencies among classes by presenting a unified interface to encapsulated subsystems. (E.g., A compiler application with many subsystems, using the Compiler via a Façade pattern will provide a high level interface to the compiler
    • DESCRIPTION
      • Lower level class (subclasses) in, e.g., the compiler application, can be invoked via the high-level interface. An Façade is opaque (I.e., black-box like) in that a caller accesses the subclass services/methods indirectly.
    • EXAMPLE
      • Fig 6-30, (Fig A-6)
    • RELATED TO
      • Fosters coupling and cohesion, layering and partitioning of systems. Complements the Composite Pattern
  • 15. Compiler compile(s) create() getToken() create() generateParseTree() create() Figure 6-30. An example of the Facade pattern (UML class diagram). CodeGenerator Compiler Optimizer Lexer Parser ParseNode
  • 16. OBSERVER PATTERN – Presenting multiple views through a single entry (subscriber)
    • PURPOSE
      • Many viewers see specific subscriptions/views through a single Subscriber abstract class. The Subscriber is capable of presenting multiple views or displays of the same information for different viewers or audiences.
    • DESCRIPTION
      • Using invoke() and update() methods between the viewers (e.g., publisher class objects) and the subscriber objects, the concrete views (or concrete subscribers) can be modified to allow synchronization or consistency between the viewers and the subscriber-objects.
    • EXAMPLE Fig 6-15
    • RELATED TO
      • Entity, interface and control objects
  • 17. Figure 6-15. Model/View/Controller architecture (UML class diagram). The Controller gathers input from the user and sends messages to the Model . The Model maintains the central data structure. The View (s) display the Model and is notified (via a subscribe/notify protocol) whenever the Model is changed. Controller Model subscriber notifier initiator * repository 1 1 * View
  • 18. THE PROXY PATTERN – Deferring expensive services
    • PURPOSE
      • Services which require expensive computation or memory usage are deferred. A preliminary (preparatory or evaluative service is provided) service is provided by the Proxy class, before the Real class services are invoked.
    • DESCRIPTION
      • The Proxy and the Real classes both implement the same interface, but the Proxy is more skeletal, having a subset of the Real class’s attributes, evaluates certain requests completely on its own, and then delegates the heavyweight services to the Real class
    • EXAMPLES
      • Fig 7-31, Fig A8, Client-Server systems, Windowing systems
    • RELATED CONCEPTS
      • Caching expensive computations (look-ahead techniques)
  • 19. Figure 7-31. Delaying expensive computations using a Proxy pattern (UML class diagram).
  • 20. THE STRATEGY PATTERN – Encapsulating multiple implementation of algorithms
    • PURPOSE
      • Decouples an algorithm from its many implementations. Similar to the adaptor and bridge patterns, only that a Strategy pattern encapsulates the behaviors of a single object – an algorithm
    • DESCRIPTION
      • An abstract Strategy class provides an interface to concrete strategy classes, which implement the various behaviors of that single algorithm. The concrete implementations can be switched with impacting the caller application
    • EXAMPLES
      • Fig 6-40, Fig A9
    • RELATED TO
      • Adapter and Bridge Patterns
  • 21. Message getBlock() IDEA IDEA_Vendor_A IDEA_Vendor_B Context class Strategy class ConcreteStrategy classes Figure 6-40. An example of a Strategy pattern encapsulating multiple implementation of the IDEA encryption algorithm (UML class diagram). The Message and IDEA classes cooperate to realize the encryption of plain text. The selection of an implementation can be done dynamically. encrypt(key, block) decrypt(key, block)

×