[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Which is better -- method option or multiple methods?

Trans

3/10/2008 5:24:00 PM

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

Robert Klemme

3/10/2008 5:40:00 PM

0

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

Ranieri Teixeira

3/10/2008 6:01:00 PM

0

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.bl...
http://rubyxchart.rub...

Paul Mckibbin

3/10/2008 7:09:00 PM

0

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

Robert Klemme

3/10/2008 7:21:00 PM

0


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

Robert Klemme

3/10/2008 7:35:00 PM

0

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

Paul Mckibbin

3/10/2008 7:51:00 PM

0

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

Robert Klemme

3/10/2008 9:16:00 PM

0

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

Lionel Bouton

3/10/2008 10:29:00 PM

0

Trans wrote:
> In the case of limited options, like the following example, which is
> better?
>
> class String
>
> def align(direction. spacing)
> case direction
> [...]
> end
>
> OR
>
> def align_left(spacing)
> ...
> end
> [...]

If the direction is supposed to be static everywhere in the code, I'd
use the align_<direction>(*args) methods.

But if the direction is dynamic (based on a property, a preference, any
algorithm, ...) then I'd use the align(direction, *args) method.
Otherwise you will get

case direction
when :left
align_left(...)
when :right
align_right(...)
when :center
align_center(...)
end

constructs everywhere...

But I'd probably use the align_* methods to implement align(direction,
....) for readability and flexibility anyway. In this case align_* would
be private if you don't need them to simplify the API or public if you
actually need them.

Lionel

Paul Mckibbin

3/10/2008 11:43:00 PM

0

Lionel Bouton wrote:
> Trans wrote:
>> In the case of limited options, like the following example, which is
>> better?

> If the direction is supposed to be static everywhere in the code, I'd
> use the align_<direction>(*args) methods.
>
> But if the direction is dynamic (based on a property, a preference, any
> algorithm, ...) then I'd use the align(direction, *args) method.
> Otherwise you will get
>
> case direction
> when :left
> align_left(...)
> when :right
> align_right(...)
> when :center
> align_center(...)
> end
>
> constructs everywhere...
>
> But I'd probably use the align_* methods to implement align(direction,
> ...) for readability and flexibility anyway. In this case align_* would
> be private if you don't need them to simplify the API or public if you
> actually need them.
>
> Lionel

Surely then there would then be a decision making process that would set
the variable <direction>, and how is that simpler than calling the
function?

In any case, you can replace your "case direction" constructs with

send("align_#{direction}",spacing)

Mac
--
Posted via http://www.ruby-....

Lionel Bouton

3/10/2008 11:56:00 PM

0

Paul Mckibbin wrote:
> Lionel Bouton wrote:
>> If the direction is supposed to be static everywhere in the code, I'd
>> use the align_<direction>(*args) methods.
>>
>> But if the direction is dynamic (based on a property, a preference, any
>> algorithm, ...) then I'd use the align(direction, *args) method.
>> Otherwise you will get
>>
>> case direction
>> when :left
>> align_left(...)
>> when :right
>> align_right(...)
>> when :center
>> align_center(...)
>> end
>>
>> constructs everywhere...
>>
>> But I'd probably use the align_* methods to implement align(direction,
>> ...) for readability and flexibility anyway. In this case align_* would
>> be private if you don't need them to simplify the API or public if you
>> actually need them.
>>
>> Lionel
>
> Surely then there would then be a decision making process that would set
> the variable <direction>

That's what I meant by "dynamic"...

>, and how is that simpler than calling the
> function?

It's not. It's why it was used as an argument for the case where you'd
prefer to make this function public (assuming we speak of
align(direction, *args)): the "dynamic" one.

Was my post so confusing?

>
> In any case, you can replace your "case direction" constructs with
>
> send("align_#{direction}",spacing)

Of course you can. But I won't: I don't find this coding-style very
maintainable or easy to read. It's a matter of taste, I only presented
mine...

Lionel