In the last edition of Building Click, I asked when the appropriate time to re-factor is. The answer to my question was 27 revisions ago. I initially decided to ignore what needed to be fixed because my desire to fix was such that it was preventing the application from being successfully written. It seams that I am now reaching the opposing extreme in that now my code contains much needless repetition. This repletion was allowed for the sake of the simplest solution but now it’s getting to an extent I can no longer ignore in good conscience.
Because of this I have decided to branch the development branch and work on cleaning the existing tests and code up before adding aby new features, at which point I will begin my usual test-re-factor cycle again to avoid accumulating this level of code stench again. I’ll maintain the original concept of implementation simplicity by not going too nuts with the design patterns and architecture, I just want to break the big monolithic blob that is the Game class into a few smaller well-defined classes for the sake of cleanliness and future maintainability
After my refactoring the application will be structured as below:
Acts as the external interface to the system with which the UI will interact. This class will act as a facade over internal classes and will become considerably lighter as most of it’s current responsibilities will be re-assigned to single-purpose classes.
Will contain all game timing functionality and probably game state management logic as the state of the game is heavily dependent on timing.
Responsible for score-keeping functions.
To me these alternations seam simple and well-defined, id anyone (James?) has questions or comments relating to these changes please let me know.