F-1 © 2007 T. Horton CS 4240 Principles of SW Design More design principles LSP, OCP, DIP, … And another pattern Decorator

F-2 Well-known Design Principles Liskov Substitutability Principle Open-Closed Principle (OSP) Dependency Inversion Principle (ISP)

F-3 Substitutability Liskov Substitutability Principle: –“Wherever we see a reference to an abstract object in our code, we can legally replace that with a reference to any subclass object.” –Or another way: subclasses should always be substitutable for their base classes. All about inheritance and “general” references –Implies that we can “use” the subclass object in any way that’s legal for the superclass –Formal definition of IS-A (isn’t it?) Use it to evaluate your use of inheritance

F-4 Dependency Inversion Principle DIP says –High level modules should NOT depend on low- level modules. All modules should depend on abstractions –Abstractions should not depend on details. Details should depend on abstractions. Another way to say it: –Depend on abstractions, not concrete things.

F-5 OO Principle: Open-Closed Principle The Open-Closed Principle (OCP) –Classes should be open for extension, but closed for modification. Don’t allow clients to alter your code. Allow clients to easily add things to your classes. –Provide means of extension Example of this: the Observer design pattern Note there’s a cost to making classes extendable

F-6 Lots in Common Here First, these are formal “principles” for other principles we talked about –Or closely related ones Second, some of these are related –OCP is a goal –DIP is a way of helping you reach that goal

F-7 Another Design Problem, Another Pattern You’re doing Beverages for a coffee shop Four types of coffee-drink: –HouseBlend, DarkRoast, Decaf, Espresso Also can add (for a cost): –SteamedMilk, Soy, Mocha, WhippedMilk Want a cost() method in each class to calculate costs Question: how to structure classes for this? –Avoid class explosion. Same solution as for Customer and Accounts? Need a Bridge?

F-8 One Solution Beverage abstract super-class –Subclasses: HouseBlend, DarkRoast, Decaf,… Fields / Attributes: –milk, soy, mocha, whip Methods / Operations: –hasMilk(), setMilk(); hasSoy(), setSoy(); … –cost() Issues?

F-9 Problems with This Approach Price for condiments? Alter existing code New condiments? Add methods; alter cost() operation in superclass New beverage like ice tea that shouldn’t have whipped milk? Want a double mocha?

F-10 Decorator Design Pattern “Decorate” an object –Wrappers: a object defined so that it encloses another object Key points: –Decorators have the same supertype as the object they wrap. So you can use a decorated object in the same place as the original object (a la Liskov) –Can use more than one decorator on an object –Can decorate objects at run-time

F-11 Decorators in Java I/O Used for input and output file streams Many stream types are wrappers –Add extra functionality, e.g. push-back, line-numbering, buffering, etc. –Create by using “more basic” file-stream object in constructor –Can used a wrapped-stream where you’d use any stream See Java API: utStream.html utStream.html Also used in Java Swing

F-12 Decorators in Java I/O FileInputStream istream = new FileInputStream(“foo.txt”); BufferedInputStream bstream = new BufferedInputStream(istream);

F-13 Issues with Decorators Disadvantages: –May add many classes, makes package hard to understand Like Java I/O streams –Client code should not rely on knowing a reference’s specific concrete class May get wrapped. Wrapping intended to transparent to client code. –Creating new objects could be more complex A factory class may help

F-14 Swing Examples of Decorators Example 1: Yikes -- dead link now -- never mind Button with a diagonal line – –Note: quick read, but not a lot of explanation of Swing and how buttons are drawn or components Example 2 & 3: Component border, minimize – –Better explanation, especially of Decorator pattern Inheritance vs. decoration how components are composed and painted in Swing