Design patterns OOD Lecture 6 Next lecture • Monday, Oct 1, at 1:15 pm, in 1311 • Remember that the poster sessions are in two days – Thursday, Sep 27 • 1:15 or 3:15 pm (check which with your TA) • Room 2244 + 2245 The object design activity Select sub-system Specification Re-use Specifying types & signatures Specifying visibility Identifying missing attributes & operations Identifying components Adjusting components Specifying constraints Specifying exceptions Adjusting patterns Identifying patterns Check use cases Restructuring Optimization Revisiting inheritanc Optimizing access paths Collapsing classes Caching complex computations Realizing associations Delaying complex computations What are design patterns? • Software problems generally have more than one solution: How do you choose which to use? – Patterns give guidance in the form of solution types based on experience • Patterns are also communication tools: “I’m using pattern X” instead of lengthy descriptions of solution details. Communication abstraction • Design patterns are not designs — only helpful hints Pattern elements • A name • Description of a typical problem • The elements that make up the pattern: Classes, relations, responsibilities, collaborations • Consequences: Pros, cons, trade-offs • An example solution The concept of design patterns • Nothing new in itself. Patterns are to a large degree verbalized and externalized experience, no matter what your discipline • The “Gang of Four book” (GoF) started people thinking more in these terms for s/w design – Gamma, Erich, Richard Helm, Ralph Johnson, John Vlissides (1995) Design Patterns: Elements of Reusable Object-Oriented Software. Addison- Wesley. ISBN 978-0-2016-3361-0 • Inspired by architectural theory: Christopher Alexander (1977) A Pattern Language: Towns, Buildings, Construction “Classic” patterns • Creational patterns – Abstract factory, Builder, Factory method, Singleton, Prototype • Structural patterns – Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy • Behavioural patterns – Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor Factory method Creational pattern • Problem – Hard-coding class names in code makes code less flexible • Damages re-use, changes might require multiple consistent updates – Testing: E.g. stubbing production data – Shielding user from complex creation, possibly involving data the user shouldn’t have access to • Solution – Decouple creation point from class name – Use separate method for instance creation – Encapsulates the places needing changes – Multiple pluggable creators with common interface Factory method UML «interface» Creator +factoryMethod() : Product Product ConcreteCreator +factoryMethod() : Product • DIP + OCP (+ ISP + LSP), decoupling • Dependency injection (technique for achieving dependency inversion) • Dependency defined by Creator • Injector/Provider/Container = ConcreteCreator • Dependent = whatever uses Product Factory method: Before class Bonniers { void publish(String title, String author, String text) { … String isbn = kb.lookup(title, author); Book b = new ISBNBook(title, author, isbn); … } } public class ISBNBook { public ISBNBook(String title, String author, String isbn) { … } … } Factory method: After public interface BookCreator { Book makeBook(String title, String author); } «interface» Creator public class BooksWithISBN implements BookCreator { @override +factoryMethod() : Product Book makeBook(String title, String author) { String isbn = kb.lookup(title, author); return new ISBNBook(title, author, isbn); } } // different package class Bonniers { BookCreatorProdu bc;ct ConcreteCreator void publish(String title, String author, String text) { ... +factoryMethod() : Product Book b = bc.makeBook(title, author); ... } } Factory method Other uses • Also used to encapsulate object creation when it’s complex or it’s convenient to delay decision class ImageReaderFactory { static ImageReader getImageReader(InputStream is) { switch(determineImageType(is)) { case ImageReaderFactory.GIF: return new GifReader(is); case ImageReaderFactory.JPEG: return new JpegReader(is); // … } } } Factory method Limitations • Introducing factory methods might break existing clients • Reduces coupling by increasing complexity Abstract factory pattern • Generalization of factory method pattern «interface» «uses» Client AbstractFactory +createProductA() : AbstractProductA +createProductB() : AbstractProductB «uses» «interface» AbstractProductA ConcreteFactory1 «instantiates» ProductA1 ProductA2 +createProductA() : ProductA1 +createProductB() : ProductB1 «instantiates» ConcreteFactory2 «uses» +createProductA() : ProductA2 «interface» +createProductB() : ProductB2 AbstractProductB «instantiates» ProductB1 ProductB2 «instantiates» Composite Structural pattern • Description: Represent a hierarchy of variable width and depth so that leaves and composites can be uniformly accessed through a common interface • Examples – Syntax trees for arithmetical expressions (such as (((x+2)*y)+3)*(z+1)) – Organizational chart – In general, anything that can be seen as tree structured Composite Example Domain object Solution object • Instance diagram Add x + (y * 2) x Multiply y 2 Composite Solution Structure Participants • Component – Provides the common interface Component * – May provide interface to both parent parent and children (e.g. evaluate for arithmetic expressions) • Composite Leaf Composite leaves – Primitive with children – Implements behaviour for 1 composite objects • Leaf – Primitive w/out children Navigability – uni- or bidirectional – not part of – Implements behaviour for the pattern terminal objects Composite Example in code interface Expression { int evaluate(Map<String, int> environment); } class Add implements Expression { private Expression lhs; private Expression rhs; public Add(Expression l, Expression r) { lhs = l; rhs = r; } public int evaluate(Map<String, int> environment) { return lhs.evaluate(environment) + rhs.evaluate(environment); } } C o m p o n e n t * class Integer implements Expression { private int value; p a r e n t public Integer(int v) { value = v; } public int evaluate(Map<String, int> _env) { return value; } } l e a v e s class Variable implements Expression { L e a f C o m p o s i t e private String name; 1 public Variable(String n) { name = n; } public int evaluate(Map<String, int> env) { return environment.get(name); } } Composite Consequences and issues • Pro – Simplifies the client – Easy to add new kinds of components (e.g. division) • Contra – Recursive composition of objects • Behaviour depends on composition • Issues – How to provide access to children? • In Component (Expression) or in Composite (Add etc) • Pseudo-problem – Explicit parent references? – Sharing components? – Child ordering? Proxy Structural pattern • Expose only a subset of an object interface to clients • Improve the performance or the security of a system by delaying expensive computations, using memory only when needed, or checking access before loading an object into memory Proxy Solution Structure Participants • Subject Subject Client attribute1 – The interface that clients see attribute2 operation1() • RealObject operation2() – Class with expensive computations or security RealObject ProxyObject attribute1 issues attribute1 attribute2 attribute2 moreAttributes • operation1() 1 0..1 operation1() ProxyObject operation2() operation2() moreOperations() – Acts on behalf of RealObject until the expensive computation is needed, when it delegates to the real object Proxy Consequences • Pro: The Client is shielded from any optimizations for handling RealObjects • Contra: Adds a level of indirection between Client and RealObject (i.e. increases complexity) Proxy Example in code interface AlgebraServer { int calculate(Expression expression); } class RemoteServer implements AlgebraServer{ int calculate(ExpressionSubject expression) { ... } Client } attribute1 attribute2 operation1() class CachingProxy implementsoperation2() AlgebraServer { HashMap<Expression, Value> cache = new HashMap<Expression, Value>(); RemoteServer server; int calculate(Expression expression) { RealObject int result; ProxyObject attribute1 attribute1 attribute2 if (cache.hasKey(expression))attribute2 moreAt tr{ib utes resultope r=at iocache.get(expression);n1() 1 0..1 operation1() operation2() operation2() } else { moreOperations() result = server.calculate(expression); cache.put(expression, new Value(result)); } return result; } } Strategy Behavioural pattern • Decouple a policy-deciding class from a set of mechanisms so that different mechanisms can be changed transparently from a client Strategy pattern Library example • University library lending policies – Normal book, no outstanding requests: • Undergraduate borrower: 2 weeks • Everyone else: 4 weeks – Normal book, outstanding request: 1 week – Reference book: Cannot be borrowed – New book: 1 week – Reserved book: 3 days Strategy pattern Library example: Implementation #1 int getLoanLength(Book b, Patron p) { if (p.isReserved()) { return 3; } if (b.isNormalBook()) { if (p.hasOutstandingRequest()) { return 7;} if (p.isUnderGraduate()) { return 14; } else { return 28; } } if(p.isNewBook()) { return 7; } return 0; // is reference book } • Logic implementation in single method – Inflexible, as logic is hard-coded – Results in ugly code that is hard to read Strategy pattern Library example: Design #2 Book -loanLength : unsigned short(idl) +getLoanLength() : unsigned