Re: [Rails-devel] Implementation details for revenue calculation

[brett l. <bre...@gm...>]

On Tue, Apr 27, 2010 at 4:22 PM, Stefan Frey (web.de)
<ste...@we...> wrote:
> Brett:
> the example you gave below is an example of a class that I have created, thus
> I am aware of that ;-)

I know. That's why I used it. It proves that you're aware of the
design pattern. ;-)

> And I think that is not the path to choose for the cases we are discussing
> here.
>
> Subclassing implies that the interface to the subclasses includes all
> implementation details of the parent class: This is a blessing and a curse at
> the same time. It makes the implementation of the details easy, as you can
> change everything you like. The price to pay is that you cannot change the
> parent class anymore without checking that you do not break any of your (or
> even worse someone else's) subclasses.
>

This is also an argument for good documentation... ;-)

> For the revenue calculator I prefer an approach similar to the strategy
> pattern to define the different special rules to the subclassing approach.
>
> Another reason is that the revenue calculator itself implements some
> optimizations, that require advanced knowledge of the problem to solve. Thus
> it would be easy to write special rules subclasses, that would not work
> anymore with some of the optimizations. By narrowing the possible extensions
> I keep control of that.
>

See above comment about documentation.  If it requires advanced
knowledge, that advanced knowledge needs to be written down so that
others don't need to gain it through experimentation.

The down side is that you seem to be committing to the "big ball of
mud" development strategy ( http://www.laputan.org/mud/ ). I certainly
could be wrong here, feel free to rebut. :-)

I don't believe it will be possible or, more importantly, maintainable
to have a single set of classes handle all cases for route calculation
across all games. Consider that we do want to support games, such as
2038, that have radically different concepts of "trains" and "routes".

It may be necessary to take a different approach to modularity. The
approach used for "plugging in" different rules exceptions may not
work in the calculator case, but I don't agree that a single
calculator will fit all possibilities.


> I admit that some of the arguments are also valid for other classes in Rails.
> Many important classes (as for example OR) are available for subclassing.
> This imposes a high risk of breaking something if you change any of those
> classes. But I also admit that those risks are most likely (over)compensated
> by  the easeness to allow the implementation of specific game rules.

That's axiomatic in the definition of a subclass.  Changing the parent
*always* runs the risk of breaking the child if the child is depending
on the behavior of non-overridden parent methods, but that's not an
argument for avoiding subclassing altogether. That's simply the cost
of doing object-oriented business.

Judging by RevenueAdapter's addTrainByString() method, you've already
hit cases where subclassing would make sense. Rather than having to do
string parsing, it would seem to make sense to subclass NetworkTrain
into NetworkTrainDiesel, NetworkTrainExpress, etc. and simply have
classes of trains that "know" what parameters to use (or, possibly
better, avoid having this hard-coded and instead have these parameters
defined within a trains.xml...).

In general with Java, if you're doing string parsing and you're not
writing a text or mark-up parser, you're solving the wrong problem.
You should be doing "instanceof", not string matching. This isn't
Perl. ;-)

>
> Stefan
>

---Brett.


> On Wednesday 28 April 2010 00:52:30 brett lentz wrote:
>>
>> 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.
>>
>> ---------------------------------------------------------------------------
>>--- _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>