SE251:Session6Ian

Assessment criteria	Score
The session content is relevant to the course	5
The session has been a useful aid to your own learning	5
The team presenting the session has demonstrated that they have understood what they have presented	4
You have learnt something new from the session	5

Justification for the above scores

On the whole, this was a very good review of Bounce I. Where possible the group aired much of the solution space.

The UML model, for task 1, was well-formed, captured all key classes and interfaces, and offered an appropriate abstraction of the supplied software. Minor note – the attribute named shapes in class AnimationViewer need not be included as it is redundant, being shown an (aggregation) relationship between AnimationViewer and Shape.

The discussion of OvalShape was good. While very thorough, was all the testing concerning movement of a OvalShape necessary though – given that OvalShape does not change movement code inherited by from Shape and that this code has been tested via RectangleShape? GemShape was similarly well treated. As observed during the session, some of the labelling (x, y, and width) was inaccurate – with the labels given it would have been possible for GemShapes to leave the 2-D world as parts of a GemShape exceeded the shape’s bounding box.

Class DynamicRectangleShape was covered in depth with a number of good implementations. To recap part of the solution space for this class and to clarify the Template Method based design:

1. In DynamicRectangleShape, override method move( ) to detect a bounce and use instance variable(s), defined by DynamicRectangleShape, to record any bounce. In DynamicRectangleShape’s paint( ) method, inspect the new instance variables and paint accordingly.
2. Modify Shape’s move( ) method to detect bounces and set instance variables, defined by class Shape, to record the bounce. In class DynamicRectangleShape, override paint( ) to inspect the new instance variables and paint accordingly. This kind of approach is perhaps better than solution 1 because all Shape subclasses inherit bounce detection behaviour; hence any new Shape subclass that is interested in bouncing need not have to implement similar functionality to solution 1’s DynamicRectangleShape class.
3. Use the Template Method pattern. In class Shape define a “hook” method, e.g. hasBounced( ), – that Shape subclasses can (optionally) implement if they are interested in bouncing. Change method move( ) in class Shape to detect bouncing and call hasBounced( ) if a bounce is detected. hasBounced( ) would need to include an argument describing which wall(s) have been bounced off. In DynamicRectangleShape, implement hasBounced( ) to set a new instance variable recording the bounce. In DynamicRectangleShape’s paint( ) method, paint according to whether a bounce has been recorded. Approach 3 is similar to approach 2 in that all shape subclasses inherit bounce detection; unlike approach 2, additional instance variables need not be maintained by class Shape, and, arguably, it is clearer that a Shape subclass has a well-defined response to bounce detection.

A couple of optional tasks were presented. It was great to see these tied into the design material – showing that one of the aggregate shape solutions was an improvement of an earlier implementation in terms of flexibility (i.e. not hard-coding knowledge of the types of the “part” classes). Also presentation of the optional task included a nice review of important prior material – e.g. default constructors, dynamic binding, casting, etc. Finally, introducing the idea of reflection and having class objects (objects that represent classes) was useful and timely. This was put to good use in the aggregate shape class as the constructor for this class was able to take as arguments a couple of class objects (expected to be Shape subclasses – see notes on the Adapter pattern to see how, using generics, the parameters can be restricted to Shape subclasses) and instantiate these such that their dimensions, speed, velocity etc. were necessarily the same as the aggregate shape. A similar technique has now been presented as one way of implementing a StackAdapter as a strict composition of some List object. In both cases, this technique is used to enforce integrity.

One aspect of the session that was particularly good

Thorough treatment of the topic; evidence of critiquing solution space.

One part of the session that could have been improved

Minor point - the presentation could have been improved slightly - one of the demos was seemingly using the wrong code.