Topic: More patterns; Principles of dynamic design
Lectures
Patterns:
Contracts and interaction design:
- slides
- video part 1 youtube, video part 1 mediahopper, video part 2. (Part 2 is only at YT not MediaHopper because of a technical problem.)
Q&A/discussion: we started off talking about a few points from the lab assessment. Some people had duplicated information about connections between classes both as associations and as attributes; I reiterated that we (tend to) use associations to represent relationships between classes which are both within the scope of our class diagram, reserving attributes for situations where a class has data of a base type or of a class that's not within scope of our class diagram. I want to talk about this in the context of the UML spec, but didn't quite do so today as I want to work out where to draw the boundaries...this will come either next week or as a separate video/text. Then we also talked more about inheritance/generalization and the is-a relationship and how this creates strong coupling and why we care; and some more about coherence and the importance of these for maintainability. I put up the diagram of XP practices (linked from last week's q&a paragraph) and talked through them, emphasising the centrality of Simple Design and how the role of design in development motivates Model-Driven Development as an attempt to get the benefits of design up front without the rework costs. Then, still in the context of inheritance, we discussed how to ensure that creating a new subclass doesn't break clients of the superclass. The gold standard in some sense is to write explicit contracts - e.g. pre- and post-conditions for methods - and say that to be correct, a subclass must satisfy the same contracts that the superclass entered into. However in practice this isn't often done. Liskov Substitutivity is essentially the best we can do without having contracts - it amounts to saying, whatever object of the subclass we have, there was already some object of the superclass that behaved the same way, so having tested a client thoroughly with objects of the superclass suffices, to ensure that the client will still work with objects of the subclass. It amounts to saying "whatever contract the client had in mind, if the superclass satisfied it, the subclass must still satisfy it" - which means that the subclass writer may be constrained to satisfy even properties of the superclass which are morally just unimportant implementation details.
Videos
Optional: Joshua Bloch on How to Design a Good API and Why it Matters
Readings
- Martin Fowler on Command-Query Separation
- Martin Fowler on Fluent Interfaces Optional: Wikipedia entry on fluent interfaces (has interesting language examples, but is a bit long-winded).
- Patterns, this week and next. I recommend trying the exercises before doing the reading.
Browse and google as necessary to grok the patterns: e.g. start here or here. (See the annotated lists in the slides for the patterns you need to know for exam.)
If you prefer a video presentation, there are lots on YouTube: e.g. here is Derek Banas' explanation of the Strategy pattern - he has a whole series and there are many others. Use whatever material you find useful.