A crucial observation is that the the Ballworld code that manages the GUI (BallGUI) and the ball management (BallControl, Dispatcher, etc.) only deal with the abstract ball, ABall. That is, they represent invariant behavior at the abstract ball level. The display, creation and management of the balls is indepen dent of the particular kinds of concrete balls that is being handled. The main Ballworld framework can thus handle any type of ABall, past, present and future.
StraightBall, CurveBall and WanderBall are thus concrete variants of ABall. They represent the variant behaviors of the system. Other than in their constructors (which will prove to be a significant point when this inheritance-based model is compared to a more advanced composition-based model), these concrete subclasses only code the abstract variant behavior associated with a ball, namely the updateState method. Inheritance gives any instantiation of these classes both the invariant behaviors from the ABall superclass plus the variant behaviors from the subclass.
The Ballworld code demonstrates the importance of the concept of separation of variant and invariant behaviors.
Clearly and cleanly separating the variant and invariant behaviors in a program is crucial for achieving flexible, extensible, robust and correct program execution.
Where and how to separate the variant and invariant behaviors is arguably the most important design consideration made in writing god software.
- 2230 reads
