Here are some of the decisions that you faced in designing and implementing your LightsOut project:
- This project involves "lights," among other things.
Decision: What type of object should a light be?
- When the program starts, a collection of 25 lights (5 by 5) must appear.
- However, the user can increase or decrease the number of such lights while the program is running.
Decision: What data structure should you use for this collection of lights?
- You must display lights and controls.
- The lights are to be displayed in a square grid.
- The controls can be displayed however you think best.
Decision: How do you want the controls to be displayed?
Decision: How do you organize your project to allow the lights and controls to be displayed as you wish?
- When the user selects a light, the neighbors of that light must toggle their states (on to off or vice versa).
- In most designs, this means that one light must communicate with other lights.
Decision: Does the light talk directly to its neighbors, or through a chain of other intermediate objects?
- If the former, how does one light "get" its neighbors?
- If the latter, what chain do you use and how does that chain of communication get established?
- When the user presses a light, things should happen. That suggests asking the light to add a Listener.
Decision: What type of Listener should you use?
Decision: What object(s) should do the listening?
- When the user selects a light, the neighbors of that light must toggle their states (on to off or vice versa). But:
- Lights in the middle of the grid have four neighbors.
- Lights on the edges of the grid have three neighbors.
- Lights in the corners of the grid have two neighbors.
Decision: How do you arrange that lights behave properly, regardless of where they are in the grid?
- The five controls are similar in some ways, different in others.
Decision: What class or classes should the controls be instances of?