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

[Stefan F. (web.de) <ste...@we...>]

Brett:
the example you gave below is an example of a class that I have created, thus 
I am aware of that ;-)

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. 

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.

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.

Stefan

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