From: brett l. <bre...@gm...> - 2010-04-27 22:52:56
|
On Tue, Apr 27, 2010 at 3:37 PM, Stefan Frey (web.de) <ste...@we...> wrote: > Back after some travel: Fortunately I could assign some travel time (it is > special fun to work on Rails at times you travel on rails) to think about the > special rules and prepare some refactoring for it. > And I thank for all the comments on the revenue details. > > Stefan > > I assume that the order of games supported will be > 1. 1830, 1889 > 2. 1856, 18AL > 3. 1835, 18Kaas > 4. 18EU, 1851 > > Most likely only 1830 and 1889 will be supported in the first release of > revenue calculation. > > Some general remark first: > The revenue calculator works on a abstract level, where vertexes consists only > of the numerical id, the value and their neighbors. The trains are only > defined by their length and if they count minors(towns). > > In a similar fashion bonuses will be defined on the abstract objects. > The transformation of the specific (and usually more complex) rules is the > task of the revenue adapter and if the rules are game specific only of > classes that use defined interfaces of the revenue adapter. > > The main idea is to protect the revenue calculator against the specific rules > of the games which could potentially conflict with the correctness of the > calculation and to allow refactoring of the calculator without breaking the > implementation of the specific rules. > This is probably where you may want to look to the rules-enforcement for guidance. We've tried to create a class hierarchy that allows us to describe objects in the general sense, and then specify game-specific objects that implement specific exceptions when necessary. Example: OperatingRound vs. OperatingRound_1889. In the same way, you'll likely want a generic calculator that covers "normal" cases, and then for games that use special rules, subclass out the specific exceptions they create and override the parent class methods with more specific implementations. ---Brett. |