Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (1) –A structural design pattern Decouples interface from implementation –Intent To provide a unified interface to a set of interfaces in a subsystem To simplify an existing interface Defines a higher-level interface that makes the subsystem easier to use

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (2) –Problem Situation I: Wish to simplify a process for most clients –Subsystems are built for multiple applications –Most applications use only a small subset –Most applications interact in a predefined manner Situation II: Wish to reduce the number of dependencies between client and implementation classes –Requires an interface that allows a level of isolation Situation III: Wish to build a layered software design with all inter-layer communication between interfaces

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (3) –Non-software example Customer Service Representative –Provides a unified interface to each of the departments involved in a transaction

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (4) –Abstract Description Object Design Pattern Most clients use façade to achieve desired results –Façade can be bypassed for more complex access Client

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (5) –Consequences Shields clients from subsystem complexity Promotes weak coupling between clients and subsystems –Easier to swap out alternatives Allows more advanced clients to by- pass and have direct subsystem access

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (6) –Implementation Issues Can involve nontrivial manipulation of subsystem –May require several steps in sequence or composition –May require temporary storage Can completely hide subsystem –Place subsystem and façade in package –Make façade only public class –Can be difficult if subsystem objects returned to client Can implement Façade as abstract class –Allows different concrete facades under same interface

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (7) –Example: Tic-Tac-Toe When a player wants to make a move it must tell: –the “board” to make such a move –the “control manager” to set up for next turn (halt the game, skip a turn, change players, …) –The “view administrator” to announce the winner, loser, or draw if the game is over To avoid this complication, player interacts with a single interface IGame (the façade)

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (8) –Example: Tic-Tac-Toe public abstract class APlayer { protected IGame game; public APlayer(IGame g, …){ this.game = g; … } public class ComputerPlayer extends APlayer { … public void takeTurn() { … getGame().takePosition(p.x, p.y, this, …); } Handles all the details.

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (9) –Second Example: Data Access Object Data Access Object Data Manager

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (10) –Common Variations Key: Don’t add new behavior, just simplify interface to existing behavior –Java API Usage java.net.URL –client can use it without being aware of classes that allow it to work –client can use classes like URLConnection directly if they choose

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Façade Design Pattern (11) –Adapter & Façade are often compared Common misperception –Façade deals with multiple classes and Adapter deals with one Adapter converts an interface and façade simplifies one FacadeAdapter Are there preexisting classes?Yes Is there an interface we must design to?NoYes Does an object need to behave polymorphically? NoProbably Is a simpler interface needed?YesNo