Forum: Ruby When to use Hashed Parameters for method calls.

I am currently having an internal debate on refactoring some code right 
now
and whether I should convert the method to take in a hash instead of 8
arguments.

What are conventions and rules that you guys use to make this call?

Don't question the type of arguments... Question the number of 
arguments. 8 just reeks of design smell.

I should probably also note that I am working on a chunk of legacy code 
so
a lot of things are pretty stinky right now.

I know that I should refactor it, but being that this method has been
around for 6 years now, I am extremely afraid of changing the interface.

So I guess the more precise question is, during refactoring, how bad 
does
it have to smell to warrant potentially causing code paths to fail,
especially if there will be failures that won't be caught until down the
road.

Subject: Re: When to use Hashed Parameters for method calls.
  Date: Thu 27 Dec 12 06:07:39AM +0900

Quoting Ryan Davis (ryand-ruby@zenspider.com):

> Don't question the type of arguments... Question the number of
> arguments. 8 just reeks of design smell.

Specifically, if you need 8 arguments to specify a situation, it may
well be that these things would better be encapsuled in a class. Not
only you would be passing only the class instance as a parameter, but
it may well be that you could move the subject of the call to a method
of the object.

Every repartition of meaning/content that helps describe better your
problem in terms of object orientation is welcome, in the sense that
things eventually work more lightly / more efficiently.

Carlo

On 27/12/2012, at 10:14 AM, Ricky Ng wrote:

> I should probably also note that I am working on a chunk of legacy code so a lot 
of things are pretty stinky right now.
>
> I know that I should refactor it, but being that this method has been around for 
6 years now, I am extremely afraid of changing the interface.
>
> So I guess the more precise question is, during refactoring, how bad does it 
have to smell to warrant potentially causing code paths to fail, especially if 
there will be failures that won't be caught until down the road.

I get the impression from what you said there are no tests for the 
method you want to refactpr. If so then I understand your fear.

I suggest your first step is write some tests to make sure you 
understand what the code does and to ensure your refactoing doesn't 
break anything. Then write a new method that has the same functionality 
as the original method (and passes the same tests) but is 'better' 
factored, eg. has a nicer interface. The old method can then delegate to 
your new method without breaking any other parts of the system. Then you 
can go hunting for callers of the old method and change them to call the 
new without fear of breaking something because you missed one.

Before you start though watch the following video...

http://www.youtube.com/watch?v=J4dlF0kcThQ

It might give you some inspiration.

Henry


PS. To answer your original question, I personally don't like hashed 
params because they hide the interface, but I occasionally use them 
because sometimes they 'feel' right. Looking back over my code it is 
usually when I have a lot of default or optional params.

On Wed, Dec 26, 2012 at 10:43 PM, Henry Maddocks <hmaddocks@me.com> 
wrote:

> PS. To answer your original question, I personally don't like hashed params 
because they hide the interface, but I occasionally use them because sometimes 
they 'feel' right. Looking back over my code it is usually when I have a lot of 
default or optional params.

Using a Struct generated class might give a bit more type safety since
all possible keys are laid out explicitly.

Kind regards

robert

On 28/12/2012, at 12:06 AM, Robert Klemme <shortcutter@googlemail.com> 
wrote:

> On Wed, Dec 26, 2012 at 10:43 PM, Henry Maddocks <hmaddocks@me.com> wrote:
>
>> PS. To answer your original question, I personally don't like hashed params 
because they hide the interface, but I occasionally use them because sometimes 
they 'feel' right. Looking back over my code it is usually when I have a lot of 
default or optional params.
>
> Using a Struct generated class might give a bit more type safety since
> all possible keys are laid out explicitly.

Yes, this is a good compromise, but it always feels odd to me to create 
such a short lived object. Though I guess the params Has is a short 
lived object too.

Henry

On Thu, Dec 27, 2012 at 11:40 PM, Henry Maddocks <hmaddocks@me.com> 
wrote:
>
> On 28/12/2012, at 12:06 AM, Robert Klemme <shortcutter@googlemail.com> wrote:

>> Using a Struct generated class might give a bit more type safety since
>> all possible keys are laid out explicitly.
>
> Yes, this is a good compromise, but it always feels odd to me to create such a 
short lived object. Though I guess the params Has is a short lived object too.

Maybe if you start reasoning about that Struct you find out it's not
so short lived any more because it can live longer.  Refactorings can
have surprising results at times. :-)

Kind regards

robert