1. Patterns – Day 13 Responsibility Read chapters 6-11 of Metsker. If you have not given me an electronic copy of your (past) presentation, please do so. No class tomorrow or Monday

2. Reminders Some purposes of patterns –Re-use –Maintenance

3. Presentations happening soon We’re doing some chapters out of order, so that I don’t do too many in a row. Not ideal, but the best I can do. Be ready on your “earliest day”. It is possible that it will happen later. It is possible that it will be split.

4. Questions, comments, rebuttals, etc.?

5. Responsibility In one sense, responsibility is what OO design and programming are all about. Who is responsible for what? So most patterns will say something about responsibility. In Metsker’s classification, seven of the patterns particularly deal with this.

6. Normal responsibility In Metsker's view, Normal responsibility = _________ responsibility

7. CHALLENGE 7.1 CHALLENGE 7.1 The class structure shown here has at least ten questionable assignments of responsibility. For five of these, write a statement of what is wrong.

8. What do you think of these statements? Establishing principles for the proper assignment of responsibility in object- oriented systems seems to be an area ripe for progress in computer science. –A system in which every class and method clearly defines its responsibilities and bears them correctly is a strong system, probably stronger than most systems we encounter today.

9. What do you think of these statements? It is common to speak of classes and methods as bearing various responsibilities. –In practice, this usually translates into your bearing responsibility for the solid design and proper functioning of your code. Fortunately, –Java offers some relief. You can limit the visibility of your classes, fields, and methods and thereby limit your responsibility to developers who use your code.

10. Controlling Responsibility by Limiting Visibility. Metsker's example: –Objects are usually responsible for maintaining themselves in a consistent state. –If we allow other people's code to change a field, the consistency might be broken. –Picture on next slide

11. Oozinoz visibility example If someone creates a subclass that "burrows" into a SolidRocket, the consistency can be lost. CHALLENGE 7.4CHALLENGE 7.4 In this situation, how could you prevent other developers from taking advantage of protected fields by subclassing into classes in your package?

12. Responsibility Patterns If you intend toApply the pattern Centralize responsibility in a single instance of a class SingletonSingleton (Chapter 8)Chapter 8 Decouple an object from awareness of which other objects depend on it ObserverObserver (Chapter 9)Chapter 9 Centralize responsibility in a class that oversees how a set of other objects interact MediatorMediator (Chapter 10)Chapter 10 Let an object act on behalf of another object ProxyProxy (Chapter 11)Chapter 11 Allow a request to escalate up a chain of objects until one handles it Chain of Responsibility Chain of Responsibility (Chapter 12)Chapter 12 Centralize responsibility in shared, fine- grained objects FlyweightFlyweight (Chapter 13)Chapter 13