March 200391.3913 R McFadyen1 Façade. March 200391.3913 R McFadyen2 Facade P. 368+ Main Entry: fa·cade Variant(s): also fa·çade / f&-'säd/ Function: noun.

Slides:



Advertisements
Similar presentations
Oct 2, Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
Advertisements

March R McFadyen1 Architecture Architecture involves the set of significant decisions about the organization of a software system, decisions.
January Ron McFadyen1 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) enclosed in a box.
March Ron McFadyen1 Ch 17: Use Case Realizations with GRASP Patterns Assigning responsibilities to objects to achieve user goals Section 17.4.
Oct R McFadyen1 Recall UML Class Diagram BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..*
Feb R. McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
Nov R McFadyen1 Design Patterns (GoF) contains the creational patterns: Abstract factory Builder Factory method (section 23.3 has a Simple.
March Ron McFadyen1 Observer P Also known as Publish-Subscribe Applied in order to implement the Model-View Separation principle (see.
Fall 2009ACS-3913 R McFadyen1 Design Patterns (GoF) contains the creational patterns: Abstract factory Builder Factory method (Simple Factory) Prototype.
March R McFadyen1 Design Patterns (GoF) contains the creational patterns: Abstract factory Builder Factory method (in Larman) Prototype Singleton.
Façade Pattern Jeff Schott CS590L Spring What is a façade? 1) The principal face or front of a building 2) A false, superficial, or artificial appearance.
NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu Banerjee.
Case Study The NextGen POS System
Nov Ron McFadyen1 Observer P Problem: There are many objects (subscribers) needing to know of the state changes, or events, of another.
Fall 2009ACS-3913 R McFadyen1 GoF Patterns, chapter 26 GoF book presents 23 patterns: Creational – 5 Structural – 7 Behavioural – 11 Larman discusses 7.
February Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m.
March R McFadyen1 GoF (Gang of Four): Gamma, Johnson, Helm & Vlissides Book: Design Patterns: Elements of Reusable Object-Oriented Software.
Fall 2009ACS-3913 R McFadyen1 Singleton Problem: Exactly one instance of a certain object is required (this object is called a singleton). We must ensure.
Jan 8, Ron McFadyen1 Waterfall Spiral UP Case study UML Use Cases.
Winter 2011ACS Ron McFadyen1 Façade A façade simplifies access to a related set of objects by providing one object that all objects outside the.
GRASP : Designing Objects with Responsibilities
Façade Design Pattern Source: Design Patterns – Elements of Reusable Object- Oriented Software; Gamma, et. al.
Chapter 22 Object-Oriented Design
Sept Ron McFadyen1 Extend Relationship.
Fall 2009ACS-3913 Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Date: 1753 an interpretation.
March R McFadyen1 Figure 30.2 Layers in NextGen They only have three layers in this architecture Each layer is shown as a UML Package No separate.
Chapter 26 Applying Gang of Four Design Patterns 1CS6359 Fall 2012 John Cole.
Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010.
Client/Server Software Architectures Yonglei Tao.
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (1) –A structural design pattern.
Design Patterns Alan Shalloway, James Trott, Design Patterns Explained, Addison-Wesley, Gamma, Helm, Johnson, Vlissides, Design Patterns, Elements.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Software Engineering 1 Object-oriented Analysis and Design Chap 30 Relating Use Cases.
MIS 2502 Business Rules BJ’s is interested in developing a new application. The database will track product, customer, and sale information. It will.
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
CSSE 374: 3½ Gang of Four Design Patterns These slides derived from Steve Chenoweth, Shawn Bohner, Curt Clifton, and others involved in delivering 374.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Chapter 26 GoF Design Patterns. The Adapter Design Pattern.
GoF Design Patterns (Ch. 26). GoF Design Patterns Adapter Factory Singleton Strategy Composite Façade Observer (Publish-Subscribe)
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Object-Oriented Software Engineering Practical Software Development using UML and Java Design Patterns – Part 2 Sources: Chapter 6: Using Design Patterns,
Oct R McFadyen1 Facade P Problem: There are a set of classes, a subsystem, that you need to interact with for some purpose, but you don’t.
What to remember from Chap 13 (Logical architecture)
Structural Design Patterns
OO Methodology Elaboration Iteration 2 - Design Patterns -
Design Patterns Software Engineering CS 561. Last Time Introduced design patterns Abstraction-Occurrence General Hierarchy Player-Role.
More Design Patterns From: Shalloway & Trott, Design Patterns Explained, 2 nd ed.
Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” Used to capture and describe.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
Watching the movie the hard way…. Page 256 – Head First Design Patterns.
GRASP: More Patterns for Assigning Responsibilities Presented By Dr. Shazzad Hosain.
Oct 3, Ron McFadyen1 GRASP Patterns 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion.
Expense Tracking System Developed by: Ardhita Maharindra Muskan Regmi Nir Gurung Sudeep Karki Tikaprem Gurung Date: December 05 th, 2008.
Sept Ron McFadyen1 Include Relationship UC1:Process Sale … Main Success Scenario … 7. Customer pays and System handles payment. … Extensions.
Elaboration: Iteration 2. Elaboration: Iteration 2 Basics Iteration 1 ends with : All the software has been tested: The idea in the UP is to do early,
Elaboration popo.
Presented by FACADE PATTERN
Presentation on GoF Design Patterns Submitted by WWW. ASSIGNMENTPOINT
GoF Patterns (GoF) popo.
MPCS – Advanced java Programming
Chapter Six The Facade Pattern
Design Pattern: Facade
Design Patterns (GoF) contains the creational patterns:
Facade From Main Entry: fa·cade Variant(s): also fa·çade /f&-'säd/ Function: noun Etymology: French façade, from Italian facciata,
GoF Design Patterns (Ch. 26). GoF Design Patterns Adapter Factory Singleton Strategy Composite Façade Observer (Publish-Subscribe)
Figure 30.2 Layers in NextGen
GoF Design Patterns (Ch. 26)
defines a higher-level interface that makes a subsystem easier to use
GoF Patterns Ch. 26.
Presentation transcript:

March R McFadyen1 Façade

March R McFadyen2 Facade P Main Entry: fa·cade Variant(s): also fa·çade / f&-'säd/ Function: noun Etymology: French façade, from Italian facciata, from faccia face, from (assumed) Vulgar Latin facia Date: circa : the front of a building; also : any face of a building given special architectural treatment 2 : a false, superficial, or artificial appearance or effect From

March R McFadyen3 Facade P Problem: There are a set of classes, a subsystem, that you need to interact with for some purpose, but you don’t want to create dependencies on this subsystem. Solution: Create a class that wraps this subsystem. The wrapper will define an interface that hides the details (classes, methods) of the subsystem. The façade is a “front-end” object that defines a single point of entry to the subsystem’s services. Showing the classes as a package (a subsytem) A façade, a wrapper

March R McFadyen4 Facade P Text example. NextGen POS is a system to be sold to many customers. Customers will want to customize NextGen POS Example: Payment rules may vary for gift certificates. How are gift certificates to be handled: One per customer per purchase? No change is returned - another gift certificate issued? To allow flexibility, it is desired to reduce the impact of changes to the rest of the system To reduce the impact, the Façade pattern is applied and the subsytem will be hidden behind a single object

March R McFadyen5 Sale objects, in the Domain package, access the POS Rule Engine via the façade in the POSRuleEngine package if ( POSRuleEngineFacade.getInstance().isInvalid(…)... On page 370: Public class Sale … ASIDE: on Page mention of the Singleton pattern Figure 23.19

March R McFadyen6 if ( POSRuleEngineFacade.getInstance().isInvalid(…)... On page 370: Public class Sale … ASIDE: on Page mention of the Singleton pattern Singleton is a pattern whereby one instance of an object of some class is created/allowed. The class will have a static method that returns the singleton. Façades are normally accessed via the Singleton pattern.

March R McFadyen7 Facade :Sale:POSRuleEngineFacade isInvalid (…) [valid] add (…) : makeLineItem() :SalesLineItem......

March R McFadyen8 Example: (from Design Patterns Explained by Shalloway & Trott) Suppose a client object must deal with Databases, Models, and Elements. The client must first open the Database, then get a Model, then queries the Model for Elements, and finally gets Elements. I.e. Client Database Model Element

March R McFadyen9 Example: (from Design Patterns Explained by Shalloway & Trott) It may be easier to create a Database Façade that can be used by clients I.e. ClientA Database Model Element Db Facade ClientB ClientC To use the database, one only needs to become aware of DbFacade, and learn how to use it.

March R McFadyen10 When to use Facade (from Design Patterns Explained by Shalloway & Trott) To create a simpler interface: number of methods, number of objects one has to deal with The system being hidden may have an older, more complex interface The cost of developing the façade, and of developers learning the new interface may be less than learning the old one You may only be needing a subset of the functionality You may want to augment the functionality of the system To facilitate tracking system usage – by forcing all requests to go through a Façade class, one can easily track the usage. To facilitate subsystem replacement – only one class is affected, the Façade class. This is the motivation in Larman’s example.