FACADE & ADAPTER CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 7 09/13/2011

Similar documents
Object Fundamentals Part Two. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 3 09/01/2009

Design Patterns (Part 2) CSCE Lecture 18-10/25/2016 (Partially adapted from Head First Design Patterns by Freeman, Bates, Sierra, and Robson)

07. ADAPTER AND FACADE PATTERNS. Being Adaptive

TDDB84: Lecture 6. Adapter, Bridge, Observer, Chain of Responsibility, Memento, Command. fredag 4 oktober 13

TDDB84 Design Patterns Lecture 06

UML & OO FUNDAMENTALS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 3 08/30/2011

UML & OO Fundamentals. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 3 09/04/2012

Programmazione. Prof. Marco Bertini

Expanding Our Horizons. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 9 09/25/2011

Tecniche di Progettazione: Design Patterns

Design to interfaces. Favor composition over inheritance Find what varies and encapsulate it

The Adapter Pattern. Interface with anything!

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming

MORE OO FUNDAMENTALS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 4 09/01/2011

An Introduction to Patterns

Lecture 13: Design Patterns

Pattern Resources. Lecture 25: Design Patterns. What are Patterns? Design Patterns. Pattern Languages of Programming. The Portland Pattern Repository

More OO Fundamentals. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 4 09/11/2012

Facade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004

Lecture 21: Design Patterns (Part 3)

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Design Patterns Reid Holmes

Object Fundamentals Part Three. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/6448 Lecture 4 09/06/2007

COURSE 2 DESIGN PATTERNS

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

TDDB84 Design Patterns Lecture 09. Interpreter, Facade

Object Fundamentals. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/6448 Lecture 2 08/30/2007

Design Patterns. Dr. Rania Khairy. Software Engineering and Development Tool

COMP200 INTERFACES. OOP using Java, from slides by Shayan Javed

Inheritance & Polymorphism

OODP Session 5a. Web Page: Visiting Hours: Tuesday 17:00 to 19:00

Relationships amongst Objects

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

CSE 219 COMPUTER SCIENCE III STRUCTURAL DESIGN PATTERNS SLIDES COURTESY: RICHARD MCKENNA, STONY BROOK UNIVERSITY.

Lecture 2 and 3: Fundamental Object-Oriented Concepts Kenneth M. Anderson

Nat. Thomas Software Engineering Telephonics Inc. Long Island IEEE Lecture Series

APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS

CS 370 Design Heuristics D R. M I C H A E L J. R E A L E F A L L

Inheritance & Polymorphism. Object-Oriented Programming

Relationships Between Real Things. CSE 143 Java. Common Relationship Patterns. Composition: "has a" CSE143 Sp Student.

Design Patterns Revisited

Inheritance & Polymorphism

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

Design Pattern Detection

Software Engineering Prof. Rushikesh K.Joshi IIT Bombay Lecture-15 Design Patterns

Object Fundamentals, Part One. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 2 08/27/2009

Relationships Between Real Things CSE 143. Common Relationship Patterns. Employee. Supervisor

Design Patterns Cont. CSE 110 Discussion - Week 9

CISC 322 Software Architecture

Adapter & Facade. CS356 Object-Oriented Design and Programming November 19, 2014

The Strategy Pattern Design Principle: Design Principle: Design Principle:

Credit is where Credit is Due. Lecture 28: OO Design Heuristics (Part 2) This Lecture. Last Lecture: OO Heuristics. Rules of Thumb

Originality is Overrated: OO Design Principles

Relationships Between Real Things CSC 143. Common Relationship Patterns. Composition: "has a" CSC Employee. Supervisor

Administrivia. CMSC433, Fall 2001 Programming Language Technology and Paradigms. Administrivia (cont.) Project 1. Copy constructor.

Software Design and Analysis for Engineers

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

Object-Oriented Design

Contents. I. Classes, Superclasses, and Subclasses. Topic 04 - Inheritance

Logistics. Final Exam on Friday at 3pm in CHEM 102

Introduction to Design Patterns

The Design Patterns Matrix From Analysis to Implementation

L23.1 Introduction... 2

Design Pattern Detection

Chapter 14 Abstract Classes and Interfaces

Inheritance and Polymorphism in Java

Good-Enough Design. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 11 02/17/2009

CREATED BY: Muhammad Bilal Arslan Ahmad Shaad. JAVA Chapter No 5. Instructor: Muhammad Naveed

Programming in C++ Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur

More About Objects. Zheng-Liang Lu Java Programming 255 / 282

Design Patterns גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT OBJECT ORIENTED PROGRAMMING

Tecniche di Progettazione: Design Patterns

Object Fundamentals Part Three. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 4 09/03/2009

Reuse at Design Level: Design Patterns

Lecture Contents CS313D: ADVANCED PROGRAMMING LANGUAGE. What is Inheritance?

Instance Members and Static Members

Example: Count of Points

4.1 Introduction Programming preliminaries Constructors Destructors An example... 3

CS 112 Introduction to Programming

Refactoring, Part 2. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 27 12/01/09. University of Colorado, 2009

CS313D: ADVANCED PROGRAMMING LANGUAGE

Final Exam. Final Exam Review. Ch 1: Introduction: Object-oriented analysis, design, implementation. Exam Format

Software Paradigms (Lesson 3) Object-Oriented Paradigm (2)

Object Oriented Programming Part II of II. Steve Ryder Session 8352 JSR Systems (JSR)

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)

Software Eningeering. Lecture 9 Design Patterns 2

REVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION

Structural Design Patterns. CSE260, Computer Science B: Honors Stony Brook University

A few important patterns and their connections

Plan. A few important patterns and their connections. Singleton. Singleton: class diagram. Singleton Factory method Facade

Design Patterns Lecture 2

Tecniche di Progettazione: Design Patterns

Java Session. Day 2. Reference: Head First Java

Topics in Object-Oriented Design Patterns

Credit where Credit is Due. Lecture 29: Test-Driven Development. Test-Driven Development. Goals for this lecture

Chapter 8, Object Design: Reusing Pattern Solutions

First IS-A Relationship: Inheritance

Example: Count of Points

Transcription:

FACADE & ADAPTER CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 7 09/13/2011 1

Goals of the Lecture Introduce two design patterns Facade Adapter Compare and contrast the two patterns 2

Facade (I) Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Design Patterns, Gang of Four, 1995 There can be significant benefit in wrapping a complex subsystem with a simplified interface If you don t need the advanced functionality or finegrained control of the former, the latter makes life easy 3

Facade Pattern: Structure Client Facade 4

Facade (II) Facade works best when you are accessing a subset of the subsystem s functionality You can also add new features by adding it to the Facade (not the subsystem); you still get a simpler interface Facade not only reduces the number of methods you are dealing with but also the number of classes Imagine having to pull Employees out of Divisions that come from Companies that you pull from a Database A Facade in this situation can fetch Employees directly 5

Example (Without a Facade) Database Client Company Division Employee Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. It uses four classes. 6

Example (With a Facade) Database Facade find(name): Employee Client Employee With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly. 7

Real World Example: Core Audio Consider Core Audio, included in ios If you want to access that subsystem directly, you have up to 8 frameworks that you need to deal with AudioToolbox, AudioUnit, AVFoundation, CoreAudio, CoreAudioKit, CoreMIDI, CoreMIDIServer & OpenAL However, if all you need to do is play a sound, you can use a single class, AVAudioPlayer, which acts as a Facade 8

Facade Example (I) Imagine a library of classes with a complex interface and/ or complex interrelationships Home Theater System Amplifier, DvdPlayer, Projector, CdPlayer, Tuner, Screen, PopcornPopper (!), and TheatreLights each with its own interface and interclass dependencies 9

Facade Example (II) Imagine steps for watch movie turn on popper, make popcorn, dim lights, screen down, projector on, set projector to DVD, amplifier on, set amplifier to DVD, DVD on, etc. Now imagine resetting everything after the movie is done, or configuring the system to play a CD, or play a video game, etc. 10

Facade Example (III) For this example, we can place high level methods like watch movie, reset system, play cd in a facade object and encode all of the steps for each high level service in the facade; Demo Client code is simplified and dependencies are reduced A facade not only simplifies an interface, it decouples a client from a subsystem of components Indeed, Facade lets us encapsulate subsystems, hiding them from the rest of the system 11

Adapters in the Real World Our next pattern provides steps for converting an incompatible interface with an existing system into a different interface that is compatible Real World Example: AC Power Adapters Electronic products made for the USA cannot be used directly with outlets found in most other parts of the world To use, you need an AC power adapter 12

OO Adapters (I) Pre-Condition: You are maintaining an existing system that makes use of a third-party class library from vendor A Stimulus: Vendor A goes belly up and corporate policy does not allow you to make use of an unsupported class library. Response: Vendor B provides a similar class library but its interface is completely different from the interface provided by vendor A Assumptions: You don t want to change your code, and you can t change vendor B s code. Solution?: Write new code that adapts vendor B s interface to the interface expected by your original code 13

OO Adapters (II) Existing System Vendor B Class Library Create Adapter Adapter Interface Mismatch Need Adapter And then... 14

OO Adapters (III) Existing System Adapter Vendor B Class Library...plug it in Benefit: Existing system and new vendor library do not change, new code is isolated within the adapter. 15

Example: A turkey amongst ducks! (I) If it walks like a duck and quacks like a duck, then it must be a duck! Or... 16

Example: A turkey amongst ducks! (II) If it walks like a duck and quacks like a duck, then it must might be a duck turkey wrapped with a duck adapter (!) 17

Example: A turkey amongst ducks! (III) Recall the Duck simulator from last lecture? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public interface Duck { public void quack(); public void fly(); } public class MallardDuck implements Duck { public void quack() { System.out.println("Quack"); } public void fly() { System.out.println("I'm flying"); } } 18

Example: A turkey amongst ducks! (IV) An interloper wants to invade the simulator 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public interface Turkey { public void gobble(); public void fly(); } public class WildTurkey implements Turkey { public void gobble() { System.out.println("Gobble Gobble"); } public void fly() { System.out.println("I'm flying a short distance"); } } 19

Example: A turkey amongst ducks! (V) Write an adapter, that makes a turkey look like a duck 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 public class TurkeyAdapter implements Duck { private Turkey turkey; public TurkeyAdapter(Turkey turkey) { this.turkey = turkey; } public void quack() { turkey.gobble(); } public void fly() { for (int i = 0; i < 5; i++) { turkey.fly(); } } } 1. Adapter implements target interface (Duck). 2. Adaptee (turkey) is passed via constructor and stored internally 3. Calls by client code are delegated to the appropriate methods in the adaptee 4. Adapter is full-fledged class, could contain additional vars and methods to get its job done; can be used polymorphically as a Duck Demonstration 20

Adapter Pattern: Definition The Adapter pattern converts the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces The client makes a request on the adapter by invoking a method from the target interface on it The adapter translates that request into one or more calls on the adaptee using the adaptee interface The client receives the results of the call and never knows there is an adapter doing the translation 21

Adapter Pattern: Structure (I) Client 1. Client codes to an interface, not an implementation. Allows creation of multiple adapter classes, if needed. Target «interface» request() Adapter request() Object Adapter Adaptee specificrequest() 2. Adapter makes use of delegation to access the behavior of Adaptee. We can pass any subclass of Adaptee to the Adapter, if needed. adaptee.specificrequest() 22

Adapter Pattern: Structure (II) Client Target request() Adaptee specificrequest() 1. Requires use of multiple inheritance, but now adapter does not need to re-implement target and/or adaptee behavior. It simply overrides or inherits that behavior instead. Adapter request() adaptee.specificrequest() Class Adapter Demonstration 23

Comparison (I) To many people, these two patterns appear to be similar They both act as wrappers of a preexisting class They both take an interface that we don t need and convert it to an interface that we can use With Facade, the intent is to simplify the existing interface With Adapter, we have a target interface that we are converting to; we often want the adapter to plug into an existing framework and behave polymorphically 24

Comparison (II) Superficial difference But Facade hides many classes; Adapter hides only one a Facade can simplify a single, very complex object an adapter can wrap multiple objects at once in order to access all the functionality it needs The key is simplify (facade) vs convert (adapter) 25

Multiple Inheritance Let s talk a little bit more about multiple inheritance Some material for this section taken from Object-Oriented Design Heuristics by Arthur J. Riel Copyright 1999 by Addison Wesley ISBN: 0-201-63385-X 26

Multiple Inheritance Riel does not advocate the use of multiple inheritance (its too easy to misuse it). As such, his first heuristic is If you have an example of multiple inheritance in your design, assume you have made a mistake and prove otherwise! Most common mistake Using multiple inheritance in place of containment That is, you need the services of a List to complete a task Rather than creating an instance of a List internally, you instead use multiple inheritance to inherit from your semantic superclass as well as from List to gain direct access to List s methods You can then invoke List s methods directly and complete the task 27

Graphically food type location Animal elements head List makenoise() eat() roam() addelement() removeelement() findelement() Hippo Inheriting from List in this way is bad, because Hippo IS-A List is FALSE makenoise() eat() submerge() A Hippo is NOT a special type of List Instead... 28

Do This food type location Animal What s the Difference? makenoise() eat() roam() Hippo elements head List makenoise() eat() submerge() addelement() removeelement() findelement() 29

Another Problem What s wrong with this? A B C Hint: think about what might happen when you create an instance of D D 30

Multiple Inheritance A Second Heuristic Whenever there is inheritance in an OO design, ask two questions: 1) Am I a special type of the thing from which I m inheriting? 2) Is the thing from which I m inheriting part of me? A yes to 1) and no to 2) implies the need for inheritance A no to 1) and a yes to 2) implies the need for composition Recall Hippo/List example Example Is an airplane a special type of fuselage? No Is a fuselage part of an airplane? Yes 31

Multiple Inheritance A third heuristic Whenever you have found a multiple inheritance relationship in an object-oriented design, be sure that no base class is actually a derived class of another base class Otherwise you have what Riel calls accidental multiple inheritance Consider the classes Citrus, Food, and Orange ; you can have Orange multiply inherit from both Citrus and Food but Citrus IS-A Food, and so the proper hierarchy can be achieved with single inheritance 32

Example Food Food Citrus Citrus Orange Orange 33

Multiple Inheritance So, is there a valid use of multiple inheritance? Yes, sub-typing for combination It is used to define a new class that is a special type of two other classes where those two base classes are from different domains In such cases, the derived class can then legally combine data and behavior from the two different base classes in a way that makes semantic sense 34

Multiple Inheritance Example WoodenObject Door Is a wooden door a special type of door? Yes Is a door part of a wooden door? No Is a wooden door a special type of wooden object? Yes Is a wooden object part of a door? No Is a wooden object a special type of door? No Is a door a special type of wooden object? No All Heuristics Pass! WoodenDoor 35

Wrapping Up Reviewed examples of Facade and Adapter Saw how easy it was to implement them Compared the patterns A Facade simplifies an interface Adapter converts one interface into another 36

Coming Up Next Homework 3 Due This Friday Lecture 8: Expanding Horizons Read Chapter 8 of the textbook Lecture 9: Strategy, Bridge, Abstract Factory Read Chapters 9, 10, & 11 Homework 4 will be assigned on Friday 37