On Mon, Mar 7, 2011 at 10:56 AM, Nathan Strutz wrote:
> If you have a lot of arguments, one way to refactor that is to make a
> component that encompasses those arguments - essentially a bean, maybe a
> couple of beans if the arguments are unrelated. In your first public method,
> instantiate tha
On Mon, Mar 7, 2011 at 11:57 AM, Judah McAuley wrote:
>
> On Mon, Mar 7, 2011 at 9:24 AM, Matt Quackenbush wrote:
> > That's the beauty of refactoring, though. Unless you need to, don't.
> And
> > if no other method is calling it (or expected to call it), then it is not
> > needed. If it becom
> I generally agree with this notion but I think it starts to fall apart
> with more complex methods. You might have a whole routine that only
> gets called one place but is complex enough that there are benefits to
> breaking it up into multiple methods that have single concerns. Doing
> so makes
On Mon, Mar 7, 2011 at 9:24 AM, Matt Quackenbush wrote:
> That's the beauty of refactoring, though. Unless you need to, don't. And
> if no other method is calling it (or expected to call it), then it is not
> needed. If it becomes needed, refactor and add it in. :-)
I generally agree with th
If you have a lot of arguments, one way to refactor that is to make a
component that encompasses those arguments - essentially a bean, maybe a
couple of beans if the arguments are unrelated. In your first public method,
instantiate that bean with the arguments, then just pass that bean around.
Fol
On Mon, Mar 7, 2011 at 11:21 AM, Dave Watts wrote:
>
> > If, however, multiple methods do not call that private method, then there
> is
> > no need for the private method to exist.
>
> I wouldn't go as far as that. Private methods like this can serve the
> same purpose as functions or subroutines
> If, however, multiple methods do not call that private method, then there is
> no need for the private method to exist.
I wouldn't go as far as that. Private methods like this can serve the
same purpose as functions or subroutines anywhere else - to limit the
amount of code in the "main" method
Presumably your private method is being called by multiple methods. It is
definitely much better - at least in terms of documentation - to have those
arguments clearly defined. :-)
If, however, multiple methods do not call that private method, then there is
no need for the private method to exi
Hello,
Just a quick "Best Practices" question. I have a CFC, I call a method and
pass a slew of arguments to it. Internally it calls a private method using
argumentCollection=arguments. My question is, should I repeat the argument
definitions on the private method?
The arguments are avail
9 matches
Mail list logo
