COMP 310
Spring 2019
Lec09: Composing Behaviors
COMP 310
|
Lec09: Composing Behaviors |
|
|
"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 Ball and its IUpdateStrategy, including the IUpdateStrategy hierarchy, showing composite and decorator 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?
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
