160 likes | 229 Views
BTS530: Major Project Planning and Design. Basic Design Pattern Concepts All References and Material unless otherwise specified From: Applying UML and Patterns, 3 rd Edition, chapter 25. Basic Patterns/Concepts. Controller Use Case / Session Façade For protecting from variations
E N D
BTS530: Major Project Planning and Design Basic Design Pattern Concepts All References and Material unless otherwise specified From: Applying UML and Patterns, 3rd Edition, chapter 25
Basic Patterns/Concepts • Controller • Use Case / Session • Façade • For protecting from variations • For simplicity • Polymorphism
Use Case / Session Controller • What first object beyond the UI controls (receives and coordinates) a system operation? • A “controller” object • Uses use case logic to determine how a message from the UI should be handled • Can be considered a special type of Facade Design Patterns, p. 302
Facade • Knows which subsystem classes are responsible for a request • Delegates subsystem requests to appropriate subsystem objects • “Protects” and/or “Simplifies” Design Patterns, p. 461
Façade-protect from variations UI BusinessLogic DataServices
Façade-simplify • The home tv example: • “client” talks to one object—the HomeTheatreFacade • Much simpler than talking to: • Amplifier • Tuner • Dvd player • Etc. • One function “watch movie” initiates all required functions from other classes • Each individual component can be accessed if required Adapted from Head First Design Patterns, by Freeman, Freeman, Sierra, Bates, p258
Façade-simplify Provides a simple interface to a complex subsystem Still have accessto each componentin the subsystem
Polymorphism The Problem: • How do you handle alternatives based on type? How do you create pluggable software components? • if/then/else or case conditional logic is difficult to maintain • difficult to extend a program with new variations • how can you replace one server component with another without affecting the client?
Polymorphism A Suggestion/Solution: • When alternatives/behaviours vary by type (class): • assign responsibilities for the behaviours using polymorphic operations to the types for which the behaviour varies. • polymorphic => same name is given to services (methods) of different objects—the services might vary. • usually implement a common interface or are in a hierarchy with a common superclass (this is language dependent)
Problem1: how to support 3rd party tax calculators? Fig. 25.1
Problem2: in the game Monopoly a different action is initiated when players land on different squares—for example landing on GO initiates “receive $200”. What is the behaviour that varies? Why don’t we want to test for the type of an object and use conditional logic to handle this, all in one class? why? why? Fig. 25.2
Fig. 25.3 What this looks like in a sequence diagram. why? why?
Fig. 25.4-25.7 For individual squares:
Fig. 25.4-25.7 For individual squares: