Lecture sequence
Contents |
Week 1
"Blah blah blah" said User:Warwick Irwin. Nobody else got to say much. Some wiki pages were mentioned, including:
A big pile of books was waved threateningly at the students.
Everybody was asked to set up an account using their Real name.
Suddenly, it was Wednesday and everything changed. The Video rental system design example appeared, and students huddled into groups to scribble unintelligible marks on scraps of paper. Some of these scribbles were copied to the whiteboard, where they remained unintelligible. Several incantations were uttered:
- Separation of concerns
- Many to many association idiom
- Type and instance idiom (Couldn't think of a better name.)
- Beware type switches
- Switch statements smell
- Avoid redundant data
Learning happened, it seems.
A brave student (or students) should now update the Video rental system page with a record of the design(s) that emerged, & what we observed about it. Have courage.
Woo hoo! Award for bravery to User:Jason Clutterbuck. --Wal 23:45, 17 July 2008 (UTC)
Week 2
The Frogs design appeared, and it was beautiful.
Or was it? Slowly, painfully, the latent forces of evil were teased out. As User:Yugan Yugaraja put it:
- Avoid becomes - Frog phases of life are modeled by inheritance: Egg Tadpole, AdultFrog.
- Beware type switches - the phase variable in Frog is based on the type of an object (Frog).
- Beware value switches - the swim() method in Tadpole differs in behavior based on the value of an attribute (type).
- Avoid no-op overrides ("Design by Contract") - the derived class Egg overrides the base class's hop() and swim() methods with methods which does nothing.
- One key abstraction - the Move interface contains more than one key abstraction. It contains methods to move such as hop() and swim(), but it also contains a display() method which is a separate key abstraction.
Badness was detected in the following two features, but the reasons remained unclear:
- Toad is a subclass of AdultFrog.
- FrogBrain contains an array of Egg.
And we didn't even get to find out how confused we were by the question:
- Should a Frog be able to export itself?
But then, lurching violently in a different direction, we tried to make a 427 design standard but primarily managed to make Getters and setters look more confusing than they did before. The Encapsulation boundary problem was the cause of the grief.
Week 3
- Some talk was talked about the assignment, and people were encouraged to create Project ideas.
- Greg Searle's project blackjack appeared as an example.
- We hung out in the lab, in a failed attempt to animate the dead tissue of the wiki.
- The export yourself question of the Frogs design led to discovering the inherent tension between Separation of concerns and Keep related data and behaviour together.
- The separating force was reinforced by [One key abstraction]] and the Single responsibility principle.
- The Visitor pattern sprung forth like a superhero to save the day, leading to A froggy visitor.
- Some inconclusive muttering about equals and Shallow and deep copy took place.
Week 4
- Model view controller was sung about and decomposed to the Observer pattern and the Strategy pattern.
- Johnson and Foote 1988 was dangled like a carrott of influential OO goodness -- with particular relevance to Getters and setters debates.
- The Are you gonna eat that system was designed and criticised.
