From: Robert Dober on
On Sat, Apr 17, 2010 at 2:38 PM, Derek Cannon
<novellterminator(a)gmail.com> wrote:
>> Given that certain people (YHS included) consider methods of a length
>> of more than  ~10 lines very bad[1] you will re-factor your "one clean
>> method". Given that most of these folks consider long classes (and/or
>> source files) a problem too (for me 300 lines is a pain, I prefer 100)
>> you will get lots of modules to be mixed in.
>
> Thanks for the info. Based on what you've said on classes, do you think
> I should create another class for comparing the classes? For example:
> Course (to hold individual course data), CourseController (to hold the
> instantiated Courses), and CourseComparer (to provide methods to
> determine if courses overlap, courses are compatible, etc). Does this
> sound like better OOP?
> --
> Posted via http://www.ruby-forum.com/.
IMVHO it sounds like as a Course class should be responsible of
comparing itself, there is no a priori reason for refactoring this
into a different class. But there might be many reasons for doing so
in given contexts.
Maybe you should follow Einstein's advice: "As simple as possible, but
not simpler" for starters and follow with your code as it evolves,
that's a little bit what agile is about, right?
An alternative approach is to do implement it both ways and judge for
yourself what is "better" in 'given contexts', e.g. what would I need
to do if I abstracted over Courses, what if I wanted to split/unify
certain responsibilities, what if I needed a plugin system, etc. etc.
This all is much work, I agree, but you will probably learn much more
about your system than by any other means. Of course there are
"guidelines" and "philosophies" but the best way to construct a
*given* application is the best way to construct *that given*
application and I doubt that it can be known in advance. After all SW
design is an art, not a science.
So I only can humbly hope that you like some of my ideas, but if you
do not, just do not follow them and see what happens, might be as
valuable.

HTH
R.



--
The best way to predict the future is to invent it.
-- Alan Kay