120 likes | 136 Views
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. Reminders. Some purposes of patterns Re-use Maintenance. Presentations happening soon.
E N D
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
Reminders • Some purposes of patterns • Re-use • Maintenance
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.
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.
Normal responsibility • In Metsker's view,Normal responsibility = _________ responsibility
CHALLENGE 7.1The class structure shown here has at least ten questionable assignments of responsibility. For five of these, write a statement of what is wrong.
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.
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.
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
Oozinoz visibility example If someone creates a subclass that "burrows" into a SolidRocket, the consistency can be lost. CHALLENGE 7.4In this situation, how could you prevent other developers from taking advantage of protected fields by subclassing into classes in your package?