From: Sam Smoot <ssmoot@...>
Date: 2008-03-12T03:25:14+09:00
Subject: Re: Which is better -- method option or multiple methods?

On Mar 10, 2:50 pm, Paul Mckibbin <pmckib...@gmail.com> wrote:
> Robert Klemme wrote:
> > On 10.03.2008 20:09, Paul Mckibbin wrote:
> >> Method options are better if you ever want to extend it.
>
> > How is that?  How can a single method that switches over one or more
> > arguments to decide what to do be easier extended?  What if you detect
> > that the new or one of the algorithms needs an additional argument which
> > is not needed by other algorithms?
>
> >> I personally
> >> would have both in library code, but would be inclined to keep the
> >> multiple method code private to keep the interface clean.
>
> > A clean interface in my world is one where one method does exactly one
> > thing - and not multiple things.  If all those algorithms share some
> > common code this should go into another method that all of them use.
> > Much cleaner, more maintainable and easier to understand.  Just think
> > about a method's documentation, that can do 5 different things vs. five
> > methods with their own documentation.
>
> You are quite right. My code showed what I intended, but I garbled the
> explanation. Single method with switches should be private for
> implementation, and I tend to use that to make the code DRYer. Multiple
> methods for the exposed interface.
> Normally I'd start with multiple (separate) methods and create the
> private function when there was an obvious need to refactor and
> opportunity to make the code DRYer.
> --
> Posted viahttp://www.ruby-forum.com/.

This topic really bothers me. ;-) The tendency to see more Ruby
(mostly Rails) code use option hashes all over the place is sloppy
(IMO). The interface is less clear. Behaviour breaks or changes
unexpectedly. It's just bad practice.

Branching isn't DRY. So maybe there's a responsibility they all share
that could be extracted. In this case maybe that's generating X
characters of padding. That could be extracted. But making a "meta-
method" is not in itself DRY. In fact, the goal of DRYness seems to
lately be trumping longer standing lessons of loose coupling, cohesive
code, composition over inheritance, seperation of concerns, etc. All
of these should be much higher priority than DRYness. In fact, to go
to an extreme, you'll end up with much nicer code if you completely
abandon attempts at DRYness outside of your business layer and instead
focus on composition, cohesion and SoC.

Just one ranter's opinion. ;-)

DRY is the new new, and like every other that came before it, the most
recent probably being Design Patterns, it's being over-used and abused
to the detriment of code quality.