In the case of limited options, like the following example, which is
better?

class String

def align(direction. spacing)
case direction
when :left
...
when :right
...
when :center
...
end
end

OR

def align_left(spacing)
...
end

def align_right(spacing)
...
end

def align_center(spacing)
...
end

Thanks,
T.

2008/3/10, Trans <transfire@gmail.com>:
> In the case of limited options, like the following example, which is
> better?
>
> class String
>
> def align(direction. spacing)
> case direction
> when :left
> ...
> when :right
> ...
> when :center
> ...
> end
> end
>
> OR
>
> def align_left(spacing)
> ...
> end
>
> def align_right(spacing)
> ...
> end
>
> def align_center(spacing)
> ...
> end
>
> Thanks,

The general wisdom suggests to favor multiple methods over a single
method that changes behavior based on arguments. They are easier to
implement (all the switching and conditions are not needed) but most
of all the code is more modular on the interface level. Note that you
can still use a single method to implement behavior internally if that
is more efficient / easier.

Unfortunately I do not have a pointer to a more thorough discussion handy...

Kind regards

robert

--
use.inject do |as, often| as.you_can - without end

I think it's a matter of modularity vs performance of the algorithm you
encapsulate in your methods.
You must balance its needs in your code.
Multiple methods let you get more modular, in fact easy to mantain code.
Multiple arguments oprions are for a method that this type of coding is
coherent.
It works for me.

On Mon, Mar 10, 2008 at 2:40 PM, Robert Klemme <shortcutter@googlemail.com>
wrote:

> 2008/3/10, Trans <transfire@gmail.com>:
> > In the case of limited options, like the following example, which is
> > better?
> >
> > class String
> >
> > def align(direction. spacing)
> > case direction
> > when :left
> > ...
> > when :right
> > ...
> > when :center
> > ...
> > end
> > end
> >
> > OR
> >
> > def align_left(spacing)
> > ...
> > end
> >
> > def align_right(spacing)
> > ...
> > end
> >
> > def align_center(spacing)
> > ...
> > end
> >
> > Thanks,
>
> The general wisdom suggests to favor multiple methods over a single
> method that changes behavior based on arguments. They are easier to
> implement (all the switching and conditions are not needed) but most
> of all the code is more modular on the interface level. Note that you
> can still use a single method to implement behavior internally if that
> is more efficient / easier.
>
> Unfortunately I do not have a pointer to a more thorough discussion
> handy...
>
> Kind regards
>
> robert
>
> --
> use.inject do |as, often| as.you_can - without end
>
>


--=20
Ranieri Barros Teixeira
Ci=EAncia da Computa=E7=E3o - Faculdade de Computa=E7=E3o - Universidade Fe=
deral do
Par=E1 (UFPA)
http://tickruby.blogspot.com
http://rubyxchart.rubyforge.org

Method options are better if you ever want to extend it. I personally
would have both in library code, but would be inclined to keep the
multiple method code private to keep the interface clean.

class String
private
def align(direction. spacing)
case direction
when :left
...
when :right
...
when :center
...
end
end

public
def align_left(spacing)
align(:left,spacing)
end

def align_right(spacing)
align(:right,spacing)
end

def align_center(spacing)
align(:center,spacing)
end
end
--
Posted via http://www.ruby-forum.com/.

Please do not top post.

On 10.03.2008 19:01, Ranieri Teixeira wrote:
> I think it's a matter of modularity vs performance of the algorithm you
> encapsulate in your methods.

How can the single method approach be faster when it has to do more,
namely option checking and branching?

> Multiple methods let you get more modular, in fact easy to mantain code.

Exactly.

> Multiple arguments oprions are for a method that this type of coding is
> coherent.

Sorry, I do not understand what this is supposed to mean. Can you
elaborate, please?

> It works for me.

What exactly?

Kind regards

robert

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.

I tried to come up with a good search string for Google, 'method "do
just one thing"' is currently the closest that reveals some hits about
the matter.

Kind regards

robert

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 via http://www.ruby-forum.com/.

On 10.03.2008 20:50, Paul Mckibbin 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

To be honest, I just briefly looked at the code because it looked too
similar to the original. :-) But even then I would have asked how your
explanation and code fit together. :-)

> 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.

Yep, same here.

Kind regards

robert