Design Patterns Part1

Design Patterns: Elements of Reusable Object-Oriented Software (Part 1) Tom Chen

Overview ● Introduction ● What is Design Pattern? ● Organizing Design Patterns ● How to Select a Design Pattern? ● Design Patterns Part 1 ● Creational: Factory, Abstract Factory, Singleton ● Structual: Bridge, Decorator ● Behavioral: Interpreter, Visitor

What is Design Pattern? ● "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"

What is Design Pattern? Four Essential Elements ● Pattern name ● A handle used to describe a design problem, its solutions, and consequences in a word or two ● Problem ● When to apply the pattern. ● Solution ● The elements that make up the design, their relationships, responsibilities, and collaborations ● Consequences ● The results and trade-offs of applying the pattern

Priciples of Design Patterns ● Program to an interface, not an implementation. ● Polymorphism ● Favor object composition over class inheritance. ● Delegation

Organizing Design Patterns ● Creational Patterns ● Abstract the instantiation process ● Structural Patterns ● How classes and objects are composed to form larger structures ● Behavioral Patterns ● Describe algorithms and the assignment of responsibilities between objects – Not just patterns of objects or classes but also the patterns of communication between them

Organizing Design Patterns c.1

Creational Patterns Factory Method ● Intent ● Define an interface for creating an object, but let subclasses decide which class to instantiate. ● Motivation ● A framework for applications that can present multiple documents to user ● Both classes of application and document are abstract – subclass them to realize their application-specific implementations

Creational Patterns Factory Method Application doesn't know which subclass to instantiate. CreateDocument() is the factory method!

Creational Patterns Factory Method ● Applicability ● A class can't anticipate the class of objects it must create ● A class wants its subclasses to specify the objects it creates ● Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

Factory Method Sample Code c.1

Factory Method Sample Code c.2

Factory Method Consequences ● Eliminate the need to bind application-specific classes into your code ● Potential Disadv. : clients might have to subclass the Creator class just to create a particular ConcreteProduct object

Creational Patterns Abstract Factory ● Intent ● Provide an interface for creating families of related or dependent objects without specifying their concrete classes. ● Motivation ● A UI toolkit that supports multiple look-and-feel standards ● To be portable, should not hard-code widgets for a particular look and feel

Creational Patterns Abstract Factory This is the Abstract Factory!

Abstract Factory Applicability ● A system should be independent of how its products are created, composed, and represented ● A system should be configured with one of multiple families of products. ● A family of related product objects is designed to be used together ● Only want to reveal the interface of a class library of products, not the implementations

Abstract Factory Sample Code New interface! An abstract factory. Factory Methods are defined!

Pass in abstract factory. Create objects with the factory Usage of the new interface:

Abstract Factory Consequences ● Isolates concrete classes ● Makes exchanging product families easy ● Promotes consistency among products ● Application use objects from only one family at a time ● Difficult to support new kinds of products ● Change the AbstractFactory class and all of its subclasses

Creational Patterns Singleton ● Intent ● Ensure a class only has one instance, and provide a global point of access to it. ● Motivation ● Important for some classes to have exactly one instance – Only one printer spooler, one file system, one window manager... ● Solution: make the class itself responsible for keeping track of its sole instance – Ensure that no other instance can be created – Provide a way to access the instance

Singleton Applicability ● Must be exactly one instance of a class and must be accessible to clients from a well-known access point ● When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code

Singleton Consequences ● Controlled access to sole instance ● Reduced name space ● An improvement over global variables ● Permits refinement of operations and representation ● By subclassing ● Permits a variable number of instances ● More flexible than class operations (Static member functions)

Structural Patterns Bridge ● Intent ● Decouple an abstraction from its implementation so that the two can vary independently. ● Motivation ● An abstract class defines the interface and concrete subclasses implement it in different ways. – Not always flexible enough ● Inheritance binds an implementation to the abstraction permanently – Difficult to modify, extend, and reuse abstractions and implementations independently

Bridge Motivation c.1 ● Case: Implement a portable Window abstract ● Work on both XWindow and IBM's Presentation Manager(PM)

Bridge Applicability ● Avoid permanent binding between abstraction and implementation ● EX: Select or switch implementation at run-time ● Both the abstractions and their implementations should be extensible by subclassing ● Changes in the implementation of an abstraction should have no impact on clients

Bridge Consequences ● Decoupling interface and implementation ● Even possible for an object to change implementation at run-time ● Eliminate compile-time dependencies on the implementation ● Improved extensibility ● Extend the Abstraction and Implementor hierarchies independently ● Hiding implementation details from clients

Structural Patterns Decorator ● Intent ● Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. ● Motivation ● Add responsibilities to individual objects, not to an entire class – EX: Add properties like borders or behaviors like scrolling to any UI component ● Inheritance is inflexible

Structural Patterns Decorator DrawScrollbar() Draw() Draw() Draw() DrawBorder()

Decorator Applicability ● Add responsibilities to individual objects dynamically and transparently ● For responsibilities that can be withdrawn ● When extension by subclassing is impractical ● Produce an explosion of subclasses ● Class definition may be hidden or unavailable for subclassing

Decorator Consequences ● More flexibility than static inheritance ● Responsibilities can be added and removed at run- time ● Avoid feature-laden classes high up in the hierarchy ● Inheritance requires creating a new class for each additional responsibility ● A decorator and its component aren't identical ● Lots of little objects ● Easy to customize but can be hard to learn and debug

Behavioral Patterns Visitor ● Intent ● Represent an operation to be performed on the elements of an object structure ● Define a new operation without changing the classes of the elements on which it operates ● Motivation ● 2D CAD System: Simple geometries compose a model ● Basic functions – Save model to file, drawing, dragging, scale ...

Visitor Motivation Difficult to extend the ability of Shape!

Visitor Motivation c.1 Key: Double Dispatch!

Visitor Applicability ● Perform operations on object structure containig many classes of objects with differing interfaces ● Avoid polluting classes with distinct and unrelated operations ● Visitor keep related operations together ● Classes defining object structure rarely change, but often define new operations ● Change class need redefining interface to all visitors

Visitor Consequences ● Visitor makes adding new operations easy ● Visitor gathers related operations and separates unrelated ones ● Adding new ConcreteElement classes is hard ● Corresponding implementation in every ConcreteVisitor class

Visitor Consequences c.1 ● Visiting across class hierarchies ● Iterator works for classes of the same parent ● Visitor works for classes of different parent ● Accumulating state while visiting elements ● Breaking encapsulation ● Must provide public operations that access an element's internal state

Behavioral Patterns Interpreter ● Intent ● Given a language, define a representation for its grammar along with an interpreter using the representation to interpret sentences in the language ● Motivation ● Search for strings matching a pattern decribed by Regular Expression ● Search algorithms could interpret a regular expression rather than building custom algorithm

Interpreter Motivation c.1 ● Suppose the following grammar defines the regular expressions

Interpreter Motivation c.2 Context

Interpreter Motivation c.3 ● raining & (dogs | cats) * EX: Context = It is raining cats and dogs.

Interpreter Applicability ● Grammar is simple ● For complex grammars, the class hierarchy for the grammar becomes large and unmanageable ● Efficiency is not a critical concern

Interpreter Consequences ● Easy to change and extend the grammar ● Implementing the grammar is easy, too ● Complex grammars are hard to maintain. ● Adding new ways to interpret expressions (Easier) ● EX: Support pretty printing or type-checking an expression by defining a new operation – Use Visitor to avoid changing grammar classes

Design Patterns Part1

More Related Content

What's hot

Viewers also liked

Similar to Design Patterns Part1

Recently uploaded

Design Patterns Part1