Applying gof design patterns
1 / 66

Applying GOF Design Patterns - PowerPoint PPT Presentation

  • Updated On :
  • Presentation posted in: General

Applying GOF Design Patterns . Chapter 26 Applying UML and Patterns Craig Larman Presented By : Naga Venkata Neelam. Objectives. Apply GRASP and GOF design patterns to the design of NextGen case study. Introduction. The following GOF design patterns are

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentationdownload

Applying GOF Design Patterns

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Applying gof design patterns l.jpg

Applying GOF Design Patterns

Chapter 26

Applying UML and Patterns

Craig Larman

Presented By : Naga Venkata Neelam

Objectives l.jpg


  • Apply GRASP and GOF design patterns

    to the design of NextGen case study.

Introduction l.jpg


  • The following GOF design patterns are

    explored in the subsequent sections :

    • Adapter

    • Analysis

    • Factory

    • Singleton

    • Strategy

    • Composite

Adapter gof l.jpg


  • Context/problem

    • How to resolve incompatible interfaces or provide a stable interface to similar components with different interfaces?

  • Solution

    • Convert the original interface of a component into another interface through an intermediate adapter object.

The adapter pattern l.jpg

The Adapter Pattern

  • Adapters use interfaces and polymorphism

    to add a level of indirections to varying APIs

    in other components.

Using an adapter l.jpg

Using An Adapter

Using an adapter7 l.jpg

Using An Adapter

  • Protected Variations, Low Coupling, Polymorphism,Indirection helps us to view through the myriad details and see the essential alphabet of design techiques being applied.

  • Naming Convention has the advantage of easily communicating to others reading the code or diagrams what design patterns are being used.

Analysis discoveries during design domain model l.jpg

Analysis Discoveries During Design:Domain Model

  • In addition to being a newly created software class in the Design Model, this is a domain concept.

  • The following figure illustrates the updated Domain Model.

Updated partial domain model l.jpg

Updated Partial Domain Model

Slide10 l.jpg


  • The architecture of the Design Model will usually be organized into layers.One of these layers of design classes will be called “Domain layer”.

  • It will contain software classes whose names and structure take inspiration from the domain vocabulary and concepts.

Factory gof l.jpg


  • Context/Problem

    • Who should be responsible for creating objects when there are special considerations, such as complex logic,a desire to separate the creation responsibilities for better cohesion, and so forth

  • Solution

    • Create a Pure Fabrication object called a Factory that handles the creation

Solution 2 l.jpg


  • Showing a pseudo code allows one to include dynamic algorithm details on a static class diagram such that it may lessen the need for interaction diagrams.

Advantages of factory objects l.jpg

Advantages of Factory Objects

  • Separate the responsibility of complex creation into cohesive helper objects.

  • Hide potentially complex creation logic

  • Allow introduction of performance-enhancing memory management strategies,such as object caching or recycling.

Singleton gof l.jpg


  • The Factory raises a new problem in the design:

    • Who creates the factory itself?

    • How is it accessed?

  • One solution is pass the Factory instance around as a parameter to wherever a visibility need is discovered for it, or to initialize the objects that need visibility to it,with a permanent reference.

  • Alternative is Singleton pattern.

Solution l.jpg


  • Define a static method of the class that returns the singleton.

  • With this approach, a developer has global visibility to this single instance,via the static getInstance method of the class.

Visibility to single instance l.jpg

Visibility to Single Instance

public class Register


public void initialize()

{… do some work…

//accessing the singleton Factory via the getInstance call

AccountingAdapter = ServiceFactory.getInstance().getAccountingAdapter();

…do some work…}

//other methods…}

Lazy initialization l.jpg

Lazy Initialization

public static synchronized ServiceFactory getInstance()




//critical section if multithreaded application

instance = new ServicesFactory();


return instance


Eager initialization l.jpg

Eager Initialization

public class ServiceFactory


//eager initialization

private static ServicesFactory instnace = new ServicesFactory();

public static servicesFactory getInstance()


Return instance;


//other methods…


Reasons to prefer lazy initialization l.jpg

Reasons to prefer lazy Initialization

  • Creation work is avoided, if the instance is never actually accessed.

  • The getInstance lazy initialization sometimes contains complex and conditional creation logic.

Implicit getinstance singleton pattern message l.jpg

Implicit getInstance Singleton Pattern Message

Preferred methods l.jpg

Preferred Methods

  • Instance-side methods permit subclassing and refinement of the singleton class into subclasses.

  • Most object-oriented remote communication mechanisms only support remote-enabling of instance methods,not static methods.

  • A class is not always a singleton in all application contexts.

Conclusion of external services with varying interfaces problem l.jpg

Conclusion of External services with varying Interfaces Problem

Strategy gof l.jpg


  • Context/Problem

    • How to design for varying, but related,algorithms or policies?

    • How to design for the ability to change these algorithms or policies

  • Solution

    • Define each algorithm/policy/strategy in a separate class, with a common interface

Strategy in collaboration l.jpg

Strategy In Collaboration

  • A strategy object is attached to a context object- the object to which it applies the algorithm.

  • In this example the context object is a sale.

Creating a strategy with a factory l.jpg

Creating a strategy with a factory

  • There are different pricing algorithms or strategies, and they change over time.

    • Who should create the strategy?

  • A straight forward approach is to apply the Factory pattern again: a PricingstrategyFactory can be responsible for creating all strategies needed by the application.

Context objects needs attribute visibility to its strategy l.jpg

Context objects needs attribute visibility to its strategy

  • The reference in the sale will be declared in terms of the interface,not a class, so that any implementation of the interface can be bound to the attribute.

  • It is not desirable to cache the created strategy instance in a field of the PricingstrategyFactory, but rather to re-create one each time,by reading the external property for its class name, and then instantiating the strategy.

Factory for strategies l.jpg

Factory for Strategies

Creating a strategy l.jpg

Creating a Strategy

Creating a strategy 2 l.jpg

Creating a Strategy(2)

  • Protected Variations with respect to dynamically changing pricing policies has been achieved with the Strategy and Factory patterns.

  • Strategy builds on Polymorphism and interfaces to allow pluggable algorithms in an object design.

Composite gof and other design principles l.jpg

Composite(GOF) and other Design Principles

  • Context/Problem

    • How to treat a group or composition of objects the same way(polymorphically) as a non-composite(atomic object)?

  • Solution

    • Define classes for composite and atomic objects so that they implement the same interface.

Understanding composite gof with an example l.jpg

Understanding composite (GOF) with an example

  • Suppose a store has the following policies in effect for a particular day:

    • 20% senior discount policy.

    • Preferred customer discount of 15% off sales over $400.

    • On day,there is $50 off purchases over $500.

    • Buy 1 case of Darjeeling tea, get 15% discount off of everything.

Problem l.jpg


  • Suppose a senior who is also a preferred customer buys 1 case of Darjeeling tea, and $600 of veggieburgers.

  • What pricing policy should be applied?

Solution using conflict resolution strategy l.jpg

Solution using conflict resolution strategy

  • In this strategy a store applies the following:

    • Best for the customer (lowest price)

    • Highest pricing strategy (during a difficult financial period)

Multiple co existing strategies l.jpg

Multiple Co-Existing Strategies

  • One sale may have several pricing strategies

  • Pricing strategy can be related to the type of customer

  • Pricing strategy can be related to the type of product being brought

Multiple co existing strategies 2 l.jpg

Multiple co-existing strategies(2)

  • The ProductSpecification must be known by the StrategyFactory at the time of creation of a pricing strategy influenced by the product.

  • Is there a way to change the design so that the Sale object does not know if it is dealing with one or many pricing strategies, and offer a design for the conflict resolution?

  • And the answer is yes,with the composite pattern.

Signature feature of composite object l.jpg

Signature feature of Composite Object

  • In composite pattern,the composite classes such as CompositeBestForCustomerPricingStrategy inherit an attribute pricingStratagies that contains a list of more ISalePricingStrategy objects.

  • The outer composite objects contains a list of inner objects, and both the outer and inner objects implement the same interface.

Collaboration with a composite l.jpg

Collaboration with a Composite

  • In this the Sale does not know or care if its pricing strategy is an atomic object or a composite strategy that is it looks the same to the Sale object.

Object code for compositepricing strategy l.jpg

Object Code for CompositePricing Strategy

//Super class so all subclasses can inherit a List of startegies

public abstract class CompositePricingStrategy implements ISalePricingStrategy


protected List pricingStrategies = new ArrayList();

public add(ISalePricingStrategy s){


public abstract Money getTotal(Sale sale);

} // end of class

Object code for compositepricing strategy 2 l.jpg

Object Code for CompositePricing Strategy (2)

// a composite Strategy that returns the lowest total

// of its inner SalePricingStrategies

public class CompositeBestForCustomerPricingStrategy extends CompositePricingStrategy


public Money getTotal(Sale sale){

Money lowestTotal = new Money(Integer.MAX_VALUE);

//iterate over all the inner strategies

Object code for compositepricing strategy 3 l.jpg

Object Code for CompositePricing Strategy (3)

for(Iterator i= pricingStrategies.iterator(); i.hasNext();){

ISalePricingStrategy strategy = (ISalePricingStrategy);

Money total = strategy.getTotal(sale);

lowestTotal = total.min(lowestTotal);


return lowestTotal;


}//end of class

Inheritance in uml l.jpg

Inheritance in UML

Creating multiple salepricingstrategies l.jpg

Creating Multiple SalePricingStrategies

  • There are three points in the scenario where pricing strategies may be added to the composite:

    • Current store-defined discount,added when the sale is created.

    • Customer type discount,added when the customer type is communicated to the POS.

    • Product type discount added when the product is entered to the sale.

Creating a composite strategy for the first case l.jpg

Creating a composite strategy for the first case.

Creating a process sale for the second case l.jpg

Creating a Process sale for the second case

  • Use case UCI: Process Sale

  • Extensions (or Alternative Flows)

    Customer says they are eligible for a discount (e.g employee, preferred customer)

    • Cashier signals discount request.

    • Cashier enters Customer identification

    • System presents discount total, based on

      discount rules.

Creating a pricing strategy for a customer discount l.jpg

Creating a pricing strategy for a customer discount

Creating a pricing strategy for a customer discount 2 l.jpg

Creating a pricing strategy for a customer discount(2)

Considering grasp and other principles in the design l.jpg

Considering GRASP and Other principles in the Design

  • An ID is given to the customer

  • Transform the customer ID to a Customer object.

  • Pass aggregate Object as Parameter.

Slide48 l.jpg


  • Although this application of composite was to a strategy family, the Composite pattern can be applied to other kinds of objects

  • For example, it is common to create "macro commands " - commands that contain other commands -through the use of Composite.

Note 2 l.jpg


  • Composite is often used with the Strategy and Command Patterns.

  • Composite is based on Polymorphism and provides Protected Variations to a client so that it is not impacted if its related objects are atomic or composite.

Facade gof l.jpg


  • Context/Problem

    • A common, unified interface to a disparate set of implementations or interfaces- such as within a subsystem-is required.There may be undesirable coupling to many things in the subsystem, or the implementation of the subsystem may change.What to do?

Fa ade gof 2 l.jpg

Façade(GOF) (2)

  • Solution

    • Define a single point of contact to the subsystem- a facade object that wraps the subsystem. This facade object presents a single unified interface and is responsible for collaboration with the subsystem components.

Facade l.jpg


  • A Facade is a front-end object that is the single point of entry for the services of a subsystem; the implementation and other components of the subsystem are private and can't be seen by external components.

  • Facade provides Protected Variations from changes in the implementation of a subsystem.

Example for a facade l.jpg

Example for a facade

  • Define a rule engine subsystem, whose specific implementation is not yet known.It will be responsible for evaluating a set of rules against an operation, and then indicating if any of the rules invalidated the operation.

  • The facade object to this subsystem will be called POSRuleEngineFacade.

  • The designer decides to place calls to this facade near the start of the methods that have been defined as the points for pluggable rules.

Object code for the example l.jpg

Object code for the Example

public class Sale{

public void makeLineItem(Productspecification spec,int quantity){

SaleLineItem sli = new SalesLineItem(spec, quantity);

//call to the Facade




//....}//end of class

Explanation l.jpg


  • With this design, the complexity and implementation of how rules will be presented and evaluated are hidden in the rules engine subsystem.accessed through the POSRuleEngineFacade facade.

  • The subsystem hidden by the facade object could contain dozens or hundreds of classes of objects, or even a non-object-oriented solution, yet as a client to the subsystem one can see only its one public access point.

Summary of facade objects l.jpg

Summary of Facade Objects

  • Facades are often accessed through singleton.

  • The facade pattern is simple, and widely used.

  • It hides a subsystem behind an object.

Uml package notation l.jpg

UML package notation

Observer publish subscribe delegation event model l.jpg

Observer/Publish-Subscribe/ Delegation Event Model

  • Context/Problem

    • Different kinds of subscriber objects are interested in the state changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event.

    • Moreover, the publisher wants to maintain low coupling to the subscribers.

Solution59 l.jpg


  • Define a subscriber or Listener interface. Subscribers implement this interface.

  • The publisher can dynamically register subscribers who are interested in an event, and notify when an event occurs.

Updating the interface when the sale total changes l.jpg

Updating the interface when the sale total changes

The observer pattern l.jpg

The Observer Pattern

The observer pattern62 l.jpg

The Observer Pattern

  • Observer Is not only for connecting UIs and Model Objects but also used for GUI widget event handling in both Java technology and Microsoft's .Net.

  • One publisher can have many subscribers for an event.

Implementation l.jpg


class Property Event extends Event


private Object sourceofevent;

private String propertyName;

private Object oldValue;

private Object newValue;




Implementation 2 l.jpg


class Sale


private void publishPropertyEvent(String name,Object old,Object new)


PropertyEvent evt = new PropertyEvent(this, "",old,new);

for each AlarmListener al in alarmListeners





Observer l.jpg


  • Observer provides a way to loosely coupled objects in terms of communication.

  • Publishers know about subscribers only through an interface, and subscribers can register dynamically with the publisher.

Conclusion l.jpg


  • Objects can be designed and responsibilities assigned with the support of patterns.

  • They provide an explainable set of idioms by which well designed object-oriented systems can be built.

  • Login