Design Patterns 6.170 Lecture 18 Notes Fall 2005 Reading: Chapter 15 of Program Development in Java by Barbara Liskov 1 Design patterns A design pattern is: • a standard solution to a common programming problem • a technique for making code more flexible by making it meet certain criteria • a design or implementation structure that achieves a particular purpose • a high-level programming idiom • shorthand for describing certain aspects of program organization • connections among program components • the shape of an object diagram or object model 1.1 Examples Here are some examples of design patterns which you have already seen. For each design pattern, this list notes the problem it is trying to solve, the solution that the design pattern supplies, and any disadvantages associated with the design pattern. A software designer must trade off the advantages against the disadvantages when deciding whether to use a design pattern. Tradeoffs between flexibility and performance are common, as you will often discover in computer science (and other fields). Encapsulation (data hiding) Problem: Exposed fields can be directly manipulated from outside, leading to violations of the representation invariant or undesirable dependences that prevent changing the implementation. Solution: Hide some components, permitting only stylized access to the object. Disadvantages: The interface may not (efficiently) provide all desired operations. Indirec-tion may reduce performance. Subclassing (inheritance) Problem: Similar abstractions have similar members (fields and methods). Repeating these is tedious, error-prone, and a maintenance headache. Solution: Inherit default members from a superclass; select the correct implementation via run-time dispatching. 1Disadvantages: Code for a class is spread out, potentially reducing understandability. Run-time dispatching introduces overhead. Iteration Problem: Clients that wish to access all members of a collection must perform a specialized traversal for each data structure. This introduces undesirable dependences and does not extend to other collections. Solution: Implementations, which have knowledge of the representation, perform traversals and do bookkeeping. The results are communicated to clients via a standard interface. Disadvantages: Iteration order is fixed by the implementation and not under the control of the client. Exceptions Problem: Errors occurring in one part of the code should often be handled elsewhere. Code should not be cluttered with error-handling code, nor return values preempted by error codes. Solution: Introduce language structures for throwing and catching exceptions. Disadvantages: Code may still be cluttered. It can be hard to know where an exception will be handled. Programmers may be tempted to use exceptions for normal control flow, which is confusing and usually inefficient. These particular design patterns are so important that they are built into Java. Other design patterns are so important that they are built into other languages. Some design patterns may never be built into languages, but are still useful in their place. 1.2 When (not) to use design patterns The first rule of design patterns is the same as the first rule of optimization: delay. Just as you shouldn’t optimize prematurely, don’t use design patterns prematurely. It may be best to first implement something and ensure that it works, then use the design pattern to improve weaknesses; this is especially true if you do not yet grasp all the details of the design. (If you fully understand the domain and problem, it may make sense to use design patterns from the start, just as it makes sense to use a more efficient rather than a less efficient algorithm from the very beginning in some applications.) Design patterns may increase or decrease the understandability of a design or implementation. They can decrease understandability by adding indirection or increasing the amount of code. They can increase understandability by improving modularity, better separating concerns, and easing description. Once you learn the vocabulary of design patterns, you will be able to communicate more precisely and rapidly with other people who know the vocabulary. It’s much better to say, “This is an instance of the visitor pattern” than “This is some code that traverses a structure and makes callbacks, and some certain methods must be present, and they are called in this particular way and in this particular order.” Most people use design patterns when they notice a problem with their design — something that ought to be easy isn’t — or their implementation — such as performance. Examine the offending design or code. What are its problems, and what compromises does it make? What would you like to do that is presently too hard? Then, check a design pattern reference. Look for patterns that address the issues you are concerned with. 22 Creational patterns 2.1 Factories Suppose you are writing a class to represent a bicycle race. A race consists of many bicycles (among other objects, perhaps). class Race { Race createRace() { Frame frame1 = new Frame(); Wheel frontWheel1 = new Wheel(); Wheel rearWheel1 = new Wheel(); Bicycle bike1 = new Bicycle(frame1, frontWheel1, rearWheel1); Frame frame2 = new Frame(); Wheel frontWheel2 = new Wheel(); Wheel rearWheel2 = new Wheel(); Bicycle bike2 = new Bicycle(frame2, frontWheel2, rearWheel2); ... } } You can specialize Race for other bicycle races: // French race class TourDeFrance extends Race { Race createRace() { Frame frame1 = new RacingFrame(); Wheel frontWheel1 = new Wheel700c(); Wheel rearWheel1 = new Wheel700c(); Bicycle bike1 = new Bicycle(frame1, frontWheel1, rearWheel1); Frame frame2 = new RacingFrame(); Wheel frontWheel2 = new Wheel700c(); Wheel rearWheel2 = new Wheel700c(); Bicycle bike2 = new Bicycle(frame2, frontWheel2, rearWheel2); ... } ... } // all-terrain bicycle race class Cyclocross extends Race { Race createRace() { Frame frame1 = new MountainFrame(); Wheel frontWheel1 = new Wheel27in(); 3Wheel rearWheel1 = new Wheel27in(); Bicycle bike1 = new Bicycle(frame1, frontWheel1, rearWheel1); Frame frame2 = new