COMP 310
Spring 2019

Lec09:  Composing Behaviors 

Home  Info  Canvas   Java Resources  Eclipse Resources  Piazza

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:

Click for full-sized view
Ballworld composition -- balls

UML diagram of the Ball and its IUpdateStrategy, including the IUpdateStrategy hierarchy, showing composite and decorator structures:

Click for full-sized view
Ballworld composition - strategies


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

Click for full-size view
Ballworld composition - MVC

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?


While not shown in the above code and diagrams or in the referenced materials, a very useful improvement is to also pass the Dispatcher along to the IUpdateStrategy's updateState() method as a second parameter, i.e. void updateState(Ball context, Dispatcher disp). This will enable greater capabilities in the strategy and will be needed in future advancements of the architecture. Philosophically, the strategy's total world consists of not only the context ball but also the world in which the ball lives, namely the dispatcher. Thus the entirety of this environment should be passed to the strategy so that it has its full benefits when it executes.

Question: Why not simply instantiate the strategy with its context ball and dispatcher?


© 2019 by Stephen Wong