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.
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…
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.
Subject: Re: When to use Hashed Parameters for method calls.
Date: Thu 27 Dec 12 06:07:39AM +0900
Quoting Ryan D. ([email protected]):
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 Wed, Dec 26, 2012 at 10:43 PM, Henry M. [email protected]
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 K. [email protected]
wrote:
On Wed, Dec 26, 2012 at 10:43 PM, Henry M. [email protected] 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 M. [email protected]
wrote:
On 28/12/2012, at 12:06 AM, Robert K. [email protected] 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