COMP 310 Fall 2012	HW05: Command-dispatching Ballworld with Inter-ball Interactions

Assignment Instructions 

To turn in assignment:  branch your HW04 to a new HW05 project in SVN.   Do NOT name your assignment anything other than "HW05"!   Points WILL be deducted for misnamed projects.

In this assignment, you will get collisions and inter-ball interactions working in your Ballworld system.    The interactions will be in response to some sort of criteria that determines whether or not the interaction will take place, for instance, a ball will only "kill" another ball if it overlaps (collides) with it.    You are free to design whatever kinds of interactions and criteria you choose and are encouraged to seek your own models, designs and implementations for ball-to-ball interaction.  You are NOT required to follow the design presented in class!   Creativity and innovation will be rewarded!

Since this is the last Ballworld-based project, at least for a while, one of the goals here is to neatly "wrap up" this project.  When you are finished, all the documentation should be in order, all the classes and interfaces should be in packages that make logical and architectural sense, etc.   A basic rule-of-thumb criteria would be to make this project ready to hand off to another developer who is not familiar with your work and all that they will get is what is contained in the project (this is a very realistic situation!).

Problems Viewing UML Diagrams?

Requirements

1. All classes should be in packages that correspond to the semantics of the classes.         (5 pts)
   •  BE EXTREMELY CAREFUL WHEN MOVING PACKAGES AND FOLDERS!!  FOLLOW THESE DIRECTIONS EXACTLY!
   • The packages should be in a logical hierarchy.
   • Unlike classes should not be in the same packages.
   • Decoupling should be maximized.
2. Full documentation of all classes and interfaces, including all fields and methods.   Documentation must be generated in a "doc" folder in your project that holds the generated Javadocs.   See the instructions on how to create Javadocs in Eclipse.  (15 pts)
3. Add IUpdateStrategy initialization capability
   • Must properly initialize no matter when the strategy is added to the ball.  (5 pts)
   • Must properly cascade the initializations to composees in composite strategies. (5 pts)
4. Add an elastic collision strategy.  Suggestion: Initially, to get collisions working, comment out the delegation to any post-collision behaviors.  Then, after you've gotten collisions working, add in the infrastructure for post collision behaviors. (10 pts)
5. Add at least 3 ball-to-ball interactions based on some sort of interaction criteria, i.e. not every pairs of balls will interact, with at least one each of the following:   (45 pts total)
   1. Interaction criteria is that the balls must have collided, i.e. are overlapping.
   2. Interaction critera is something other than having collided.
      The interactions that were covered in class and lab, i.e. InfectStrategy, SpawnStrategy and KillStrategy, do NOT qualify as submissions.
6. All controls on the GUI must have tool tips.    Tool tips can be easily set in the properties of each component in Jigloo.   The user should be able to gather enough information  to use your program just from the tool tips. (5 pts)
7. Discretionary points, including critiques of the designs used. ( 10 pts)
8. UML diagrams that cover the entire ballworld system are not required, but HIGHLY RECOMMENDED.  The following criteria must be met:  (10 pts extra credit)
   •  Each diagram must make sense as a single diagram.  
   • Save diagrams as JPG or PNG files in a SINGLE, COMMON clearly identified folder that is included in your SVN commit.  
   • All classes and interfaces must be represented on at least one diagram.  
   • Diagrams should be logically laid out and as aesthetically pleasing as possible.   The number of crossed lines should be minimized.
   • Overlapping arrows should be used whenever possible to help minimize the number of lines on the diagrams. 
9. Creativity will be rewarded!   0-10 pts extra rewarded for creative/innovative solutions, design and capabilities of your program!

Development Advice

It is HIGHLY recommended that you do Steps 1-3 above FIRST and make sure that your code works before proceeding.   This will create a much better organization of your code and will help clarify what your system does to you, making the rest of the assignment much, much easier.   Fill in the missing parts of Steps 2 and 3 as you create the new classes and possibly packages in the remaining steps.

Start EARLY!!   This assignment is due in a week, so ask questions early--do NOT wait until the last minute.   If you encounter problems or if you have not followed the directions carefully in Step 1, it could take a significant amount of time with the staff's help to get your code back to working order, so get this done and out of the way so it won't derail you at the last moment.

On Switchers and Initializations....

There are some sticky issues regarding the initialization of the decoree strategy in the SwitcherStrategy.   These issues include, but are not limited to:  

1.  The initialization of a strategy requires an input parameter of a host Ball, but there is no Ball available for such a parameter when the strategy switching occurs.

2. The decoree strategy is a single strategy instance that is shared amongst many host Balls, so which Ball should be used for initialization?

3. If the initialization of the decoree strategy mutates that strategy as per the properties of its host ball, since the strategy is shared by multiple balls, what should the net effect be on the decoree strategy?    

Possible solutions, none of which is 100% satisfactory, include  

• By using a state design pattern or some sort of boolean flag value, delay the initialization until the first time the decoree strategy updates each of its host balls.   This, unfortunately, does not address the last issue above.  

• Use a “null” Ball to perform the initialization of the decoree strategy.    This, unfortunately, would negate any mutating effect the initialization might have on the host ball, e.g. setting the host’s color.    

Overall, the issue is wrapped up in notions of state in the strategy and the ability to share a stateful object amongst multiple hosts.    This is a non-trivial issue with non-trivial consequences and is certainly worth any the study by any student of OOP/D.  

However, in the interest of minimizing distractions for Comp310 students in completing this assignment, you will NOT be required to perform a re-initialization of the decoree strategy when doing a switch operation on a SwitcherStrategy.      

Do revisit the problem when you are more relaxed as it is a very serious issue that could potentially create serious consequences if ignored in a large system.  

© 2012 by Stephen Wong