Chapter 8, Object Design: II

Oriented Software Engineering Software Oriented -

Object Using UML, Patterns,Using UML, and Java Recall: Why reusable Designs?

A design… …enables flexibility to change (reusability) …minimizes the introduction of new problems when fixing old ones (maintainability) …allows the delivery of more functionality after an initial delivery (extensibility) …encapsulates software engineering knowledge.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 How can we describe Software Engineering Knowledge? • Software Engineering Knowledge is not only a set of algorithms • It also contains a catalog of patterns describing generic solutions for recurring problems • Not described in a programming language. • Description usually in natural language. A pattern is presented in form of a schema consisting of sections of text and pictures (Drawings, UML diagrams, etc.)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 Design Patterns • Design Patterns are the foundation for all SE patterns • Based on ‘s patterns • Book by John Vlissedes, Erich Gamma, Ralph Johnson and Richard Helm, also called the Gang of Four • Idea for the book at a BOF "Towards an Architecture Handbook“ (Bruce Anderson at OOPSLA’90)

John Vlissedes Erich Gamma Ralph Johnson Richard Helm •* 1961-2005 •* 1961 •* 1955 • University of Melbourne •Stanford •ETH •University of Illinois, •IBM Research, Boston •IBM Watson •Taligent, IBM •Smalltalk, Design Consulting Group (Australia) Research Center • JUnit, Eclipse, Patterns, Frameworks, •Design Patterns • Jazz OOPSLA veteran Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 3 Types of Design Patterns (GoF Patterns)

• Structural Patterns • Reduce coupling between two or more classes • Introduce an abstract class to enable future extensions • Encapsulate complex structures • Behavioral Patterns • Allow a choice between algorithms and the assignment of responsibilies to objects (“Who does what?”) • Characterize complex control flows that are difficult to follow at runtime • Creational Patterns • Allow to abstract from complex instantiation processes • Make the system independent from the way its objects are created, composed and represented.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Taxonomy of Design Patterns (23 Patterns)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Many design patterns use a combination of inheritance and delegation

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21

Client

ClientInterface LegacyClass

Request() ExistingRequest()

adaptee Inheritance Adapter Delegation. Request()

The adapter pattern uses inheritance as well as delegation: - inheritance: Adapter inherits Request() from ClientInterface - Delegation: Binds LegacyClass to the Adapter.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 Adapter Pattern • The adapter pattern lets classes work together that couldn’t otherwise because of incompatible interfaces • “Convert the interface of a class into another interface expected by a client class.” • Used to provide a new interface to existing legacy components (Interface engineering, reengineering). • Two adapter patterns: • Class adapter: • Uses multiple inheritance to adapt one interface to another • Object adapter: • Uses single inheritance and delegation • Object adapters are much more frequent. • We cover only object adapters (and call them adapters).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 Taxonomy of Design Patterns

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 Delegation

Inheritance Inheritance

Taxonomy in Taxonomy in Application Domain Solution Domain

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 Why the Name Bridge Pattern? It provides a bridge between the Abstraction (in the application domain) and the Implementor (in the solution domain)

Taxonomy in Taxonomy in Application Domain Solution Domain

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26 Using a Bridge • The bridge pattern can be used to provide multiple implementations under the same interface • Example: Interface to a component that is incomplete, not yet known or unavailable during testing • GetPosition() is needed by VIP, but the class Seat is only available by two simulations (AIMSeat and SARTSeat). To switch between these, the bridge pattern can be used:

Seat imp

VIP SeatImplementation GetPosition() SetPosition()

AIMSeat SARTSeat

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27 The Bridge Pattern allows to postpone Design Decisions to the startup time of a system • Many design decisions are made at design time (“design window”), or at the latest, at compile time • Bind a client to one of many implementation classes of an interface • The bridge pattern is useful to delay this binding between client and interface implementation until run time • Usually the binding occurs at the start up of the system (e.g. in the constructor of the interface class).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 Adapter vs Bridge • Similarities: • Both hide the details of the underlying implementation • Difference: • The adapter pattern is geared towards making unrelated components work together • Applied to systems that are already designed (reengineering, interface engineering projects) • “Inheritance followed by delegation” • A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently • Green field engineering of an “extensible system” • New “beasts” can be added to the “zoo” (“application and solution domain zoo”, even if these are not known at analysis or system design time • “Delegation followed by inheritance”.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Taxonomy of Design Patterns (23 Patterns)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 • Provides a unified interface to a set of classes in a subsystem • A façade consists of a set of public operations • Each public operation is delegated to one or more operations in the classes behind the facade • A facade defines a higher-level interface that makes the subsystem easier to use (i.e. it abstracts out the gory details).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 Subsystem Design with Façade, Adapter, Bridge • The ideal structure of a subsystem consists of • an interface object • a set of application domain objects (entity objects) modeling real entities or existing systems • Some of these application domain objects are interfaces to existing systems • one or more control objects • We can use design patterns to realize this subsystem structure • Realization of the interface object: Facade • Provides the interface to the subsystem • Interface to the entity objects: Adapter or Bridge • Provides the interface to an existing system (legacy system) • The existing system is not necessarily object-oriented!

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35 Good Design with Façade, Adapter and Bridge • A façade should be offered by all subsystems in a software system which provide a set of services • The façade delegates requests to the appropriate components within the subsystem. The façade usually does not have to be changed, when the components are changed • The adapter pattern should be used to interface to existing components and legacy systems • Example: A smart card software system should use an adapter for a smart card reader from a specific manufacturer • The bridge pattern should be used to interface to a set of objects with a large probability of change • When the full set of objects is not completely known at analysis or design time (-> Mock Object Pattern) • When there is a chance that a subsystem or component must be replaced later after the system has been deployed and client programs use it in the field. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36 Design Example

VIP • Subsystem 1 VIP can call on any component or class operation look in Subsystem 2 (Vehicle Subsystem).

Vehicle Subsystem

Seat

Card

AIM SART

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 Realizing an Opaque Architecture with a Facade VIP Subsystem The Vehicle Subsystem • decides exactly how it is

accessed

• No need to worry about misuse by callers • A subsystem with a façade can be used in an early integration test Vehicle Subsystem Facade • We need to write only stubs for each of the public methods in the Seat Card façade.

AIM SA/RT

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38 Taxonomy of Design Pattern

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39

• Different algorithms exists for a specific task • We can switch between the algorithms at run time • Examples of tasks: • Different collision strategies for objects in video games • Parsing a set of tokens into an abstract syntax tree (Bottom up, top down) • Sorting a list of customers (Bubble sort, mergesort, quicksort) • Different algorithms will be appropriate at different times • First build, testing the system, delivering the final product • If we need a new algorithm, we can add it without disturbing the application or the other algorithms.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40 Strategy Pattern Policy

Context * Strategy ContextInterface() AlgorithmInterface

ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC

AlgorithmInterface() AlgorithmInterface() AlgorithmInterface()

Policy decides which ConcreteStrategy is best in the current Context.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41 Using a Strategy Pattern to Decide between Algorithms at Runtime Policy Client DevelopmentTimeIsImportant ExecutionTimeIsImportant SpaceIsImportant

Database * SortInterface

SelectSortAlgorithm() Sort() Sort()

BubbleSort QuickSort MergeSort

Sort() Sort() Sort()

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42 Supporting Multiple implementations of a Network Interface Context = {Mobile, Home, Office}

LocationManager Application NetworkConnection NetworkInterface open() send() close() receive() send() setNetworkInterface() receive()

Ethernet WaveLAN UMTS open() open() open() close() close() close() send() send() send() receive() receive() receive()

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43 Taxonomy of Design Patterns

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44 Motivation

• Consider a user interface toolkit that supports multiple looks and feel standards for different operating systems: • How can you write a single user interface and make it portable across the different look and feel standards for these window managers? • Consider a facility management system for an intelligent house that supports different control systems: • How can you write a single control system that is independent from the manufacturer?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45 Abstract Factory

AbstractFactory AbstractProductA

Client CreateProductA CreateProductB

ProductA1 ProductA2

ConcreteFactory1 AbstractProductB

CreateProductA CreateProductB

ProductB1 ProductB2

ConcreteFactory2

CreateProductA Initiation Assocation: CreateProductB Class ConcreteFactory2 initiates the associated classes ProductB2 and ProductA2 Applicability for Abstract Factory Pattern

• Independence from Initialization or Representation • Manufacturer Independence • Constraints on related products • Cope with upcoming change

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47 Example: A Facility Management System for a House

IntelligentHouse HouseFactory

createBulb() createBlind()

EIBFactory LuxmateFactory

createBulb() createBulb() createBlind() createBlind()

LightBulb Blind

EIBBulb LuxmateBulb EIBBlind LuxmateBlind

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48 Clues in Nonfunctional Requirements for the Use of Design Patterns • Text: “manufacturer independent”, “device independent”, “must support a family of products” => Abstract Factory Pattern • Text: “must interface with an existing object” => Adapter Pattern • Text: “must interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated” =>Bridge Pattern • Text: “must interface to existing set of objects” => Façade Pattern

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49 Clues in Nonfunctional Requirements for use of Design Patterns (2)

• Text: “complex structure”, “must have variable depth and width” => • Text: “must provide a policy independent from the mechanism” ⇒Strategy Pattern • Text: “must be location transparent” => • Text: “must be extensible”, “must be scalable” => (MVC )

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50 Summary

• Composite, Adapter, Bridge, Façade, Proxy (Structural Patterns) • Focus: Composing objects to form larger structures • Realize new functionality from old functionality, • Provide flexibility and extensibility • Command, Observer, Strategy, Template (Behavioral Patterns) • Focus: Algorithms and assignment of responsibilities to objects • Avoid tight coupling to a particular solution • Abstract Factory, Builder (Creational Patterns) • Focus: Creation of complex objects • Hide how complex objects are created and put together

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51 Conclusion

Design patterns • provide solutions to common problems • lead to extensible models and code • can be used as is or as examples of interface inheritance and delegation • apply the same principles to structure and to behavior • Design patterns solve a lot of your software development problems • Pattern-oriented development • My favorites: Observer, Composite, Strategy and Builder.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52 Additional Design Heuristics

• Never use implementation inheritance, always use interface inheritance • A subclass should never hide operations implemented in a superclass • If you are tempted to use implementation inheritance, use delegation instead

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53