COMP 310 Fall 2012	Lec09:  Composing Behaviors

Never Satisfied...

"Too much is never enough"  -- Mick Jagger

While the ability to dynamically load new classes and run them is nothing to sneeze at, why stop there?  Our inheritance-based Ballworld system is quite capable, but yet suffers from limitations imposed by its architecture.

What if we wanted more?     For instance, right now we cannot create a ball that both curves around and changes color without copying code and we certainly cannot create such a beast at run time!

 New Composition-based Ballworld Demo

The discussion continues in the following Connexions module linked below.  

IMPORTANT NOTE:   The UML diagram for the composition-based Ballworld is NOT the same as you will be creating. In particular, it is not a true MVC design (the model and the controller are fused together) and uses a different method of communicating between the model and the view.   The composite structures being discussed are identical to those needed for this class though.

Refer to the UML diagrams below for this class.   Do NOT reference the Ballworld UML diagrams in the Connexions module!

 Go to the Connexions Module on Composition-based Ballworld

Do NOT take the following UML diagram as gospel!   Your code may look different depending on how you have done things and still be correct.   Use variable names that make sense to you, not just ones copied rote from someone else's design. 

UML Diagram of the Model with the Ball and its IUpdateStrategy:

UML diagram of the IUpdateStrategy hierarchy, showing composite structures:

UML Diagram of the Model-View-Controller Architecture of the Ballworld System:

What happens to all the ABall subclasses?  What happens to ABall?

After all the changes, which model do you think had more lines of code (i.e. ignoring the MVC-related code and the view, just comparing the models), the inheritance-based or composition-based systems?  Which had more capabilities?

© 2012 by Stephen Wong