Re: [Rails-devel] Current implementation, branch Rails 2.0?

[Stefan F. <ste...@we...>]

> All fine, but so what?  Is size bad per se?
> 

Erik,
No certainly not. All this is not about good or bad. In one sense the size 
shows the thoughts and efforts for all details you have put into those 
classes.

It is the other way around: As I do not have the time and the memory to 
understand all thoughts and conditions you considered, that created that code, 
I would prefer to digest all that in little portions. 

Organizing code into classes allows to review only the relevant classes that 
you need know. It is like organizing stuff into little boxes where you put 
labels on the boxes what is inside. This makes it much easier to find things 
and to understand the big picture: Maybe like in a big department store: It is 
much easier to get an overview by studying the directory of the store instead 
of searching every shelf.

An object orientated languages allows storing pieces of code in classes and if 
I want rewrite/change/add something to a class, I have to make sure that after 
my changes everything works as before. If the class is small, it is easier to 
check if I do not introduce side effects and I only have to test the part 
where the class is responsible for: So take the example for the 
OperatingRound. If I change anything inside I have to test all functionality 
which is managed by the OperatingRound. Thus I change something related to 
token lay, it can potentially have side effects on tile laying, revenue 
payouts, train buying, loans etc. 

If the token lay code is inside in a separate class it is impossible to effect 
the other functionality of OperatingRound. 

I had the issue more than a year ago: I started adding the NoMap 
functionalities which in principle should only change Tile and Token Lay. 
However due to side effects of my (at that time bad understanding) of the step 
mechanism inside the OperatingRound I broke the 1856 loan mechanism.
And I was not even aware of that code as this code was part of a subclass of 
OperatingRound.

The same issue about the size of classes effects writing unit tests: For 
refactoring the best is to have the class covered fully by unit tests. If you 
have two small classes instead of one large you can start refactoring earlier 
than you had to write all tests first.

And the other good thing is, that with smaller classes it is less likely that 
two people work at the same time on the same class, thus it makes merging and 
potential merge conflicts less likely.

For my daily job I have to deal with large programs in non-object orientated 
languages and even there I prefer to split problems into smaller, independent 
pieces. Especially if you come back to those programs several years later, it 
makes it much easier to enhance or fix something. 

OK enough text, but it is not about fashionable or good/bad, it is simply
about making coding easier and so increase the fun part of it.

Stefan

´