Helper Methods
Leslie Sanford
implementation of classes, but I thought I would bring it up here
anyway. Comments appreciated.
In implementing classes, I sometimes find it helpful to write private
"helper methods." These are methods that, as their name implies, help
implement a class's functionality. They can improve class quality by
breaking up a task a class needs to perform into a series of steps. So
instead of one long public method, you have one public method which in
turn calls several private helper methods. This is basically functional
decomposition. But it's hidden inside a class.
Anyway, I've been coming to the conclusion that these helper methods
should be designed as true functions, i.e. they have no side-effects and
do not depend on the state of the class.
If we consider an object a kind of world unto itself, then its fields
could be considered global data at the object level. If private methods
modify an object's fields, then within the context of the object, we
could consider these methods operating on global data.
I've been finding that this may not be such a good idea. In practise,
I've found that private methods modifying state has the same pitfalls
associated with using global data. A better approach may be to design
private helper methods as static methods that have no knowledge of an
object's state. State is passed into the helper methods by a top public
method where the operation was initiated.
A couple of advantages I've found with this approach are 1) it makes it
easier to reason about what is going on in my class. I don't look at a
call to a private helper method and have to ask myself in what way does
it modify state. 2) if a public method initiates an operation that can
fail, it can be useful to write changes to temporary values until the
operation completes. Then the state of an object can be updated. This
helps prevent a object being left in an undefined state if an operation
fails before all of its steps have been performed.
While we're on the subject, could helper methods be considered a code
smell? I can see the possibility of factoring these methods into a
seperate class. But I have to say that sometimes you just need good 'ol
fashion functional decomposition to perform a task that from the outside
world is seen as atomic.
Anyway, thanks for your time.
Daniel T.
"Leslie Sanford" <jabber...@BiteMeHotmail.com> wrote:
A couple of comments. If the private method doesn't change state, then
how is it associated with the class. I mean sure the class uses the
method, but is there any inherent reason other classes couldn't use the
same method? As such, why is the method private?
As far as your idea about class fields being like global fields (within
this context...) Have you ever noticed how often people use global
fields when the program only contains a few functions? There's nothing
wrong with globals in that case, globals only cause a problem when the
program grows very big, because it becomes hard to track all the places
the global is affected. Each class can be thought of as a small program.
Leslie Sanford
"Daniel T." wrote:
> "Leslie Sanford" wrote:
>
>> Well, this is a low-level concern; it has to do with low-level
>> implementation of classes, but I thought I would bring it up here
>> anyway. Comments appreciated.
>>
>> In implementing classes, I sometimes find it helpful to write private
>> "helper methods." These are methods that, as their name implies, help
>> implement a class's functionality. They can improve class quality by
>> breaking up a task a class needs to perform into a series of steps.
>> So instead of one long public method, you have one public method
>> which in turn calls several private helper methods. This is basically
>> functional decomposition. But it's hidden inside a class.
>>
>> Anyway, I've been coming to the conclusion that these helper methods
>> should be designed as true functions, i.e. they have no side-effects
>> and do not depend on the state of the class.
<snip>
> A couple of comments. If the private method doesn't change state, then
> how is it associated with the class. I mean sure the class uses the
> method, but is there any inherent reason other classes couldn't use
> the same method? As such, why is the method private?
Hmm, well no reason really, now that you mention it. It's just that
these functions are concerned with some pretty low level tasks. The
class that uses these functions belongs to a higher level of
abstraction. Exposing these methods seems like exposing implementation
details. Other classes in my library really have no business using them.
> As far as your idea about class fields being like global fields
> (within this context...) Have you ever noticed how often people use
> global fields when the program only contains a few functions? There's
> nothing wrong with globals in that case, globals only cause a problem
> when the program grows very big, because it becomes hard to track all
> the places the global is affected. Each class can be thought of as a
> small program.
Good point. So if I begin to have trouble reasoning about my helper
methods altering state, it might be a sign that my class has gotten too
big?
fre...@gmail.com
> should be designed as true functions, i.e. they have no side-effects and
> do not depend on the state of the class.
If possible one should always try to make true functions without
side-effects. It makes testing and analyzing easier. The problem is
that it is not always possible. (True functional languages uses
something called monads to solve the problem).
> If we consider an object a kind of world unto itself, then its fields
> could be considered global data at the object level. If private methods
> modify an object's fields, then within the context of the object, we
> could consider these methods operating on global data.
Indeed true. For large classes, member fields share the same
disadvantages as global data.
> I've been finding that this may not be such a good idea. In practise,
> I've found that private methods modifying state has the same pitfalls
> associated with using global data. A better approach may be to design
> private helper methods as static methods that have no knowledge of an
> object's state. State is passed into the helper methods by a top public
> method where the operation was initiated.
You are obviously using a language that forces you to use classes, like
Java. If you use a language like Python you can use both classes as
functions. In that case you don't need to use static methods. But in
Java that is the only option.
> While we're on the subject, could helper methods be considered a code
> smell? I can see the possibility of factoring these methods into a
> seperate class.
Or as true functions. Not everything belong to a class.
Fredrik Bertilsson
http://frebe.php0h.com
Daniel T.
"Leslie Sanford" <jabber...@BiteMeHotmail.com> wrote:
No business using them, or no need to? Are these methods so specialized
that it wouldn't make any sense for some other class to use them on its
data?
> > As far as your idea about class fields being like global fields
> > (within this context...) Have you ever noticed how often people use
> > global fields when the program only contains a few functions? There's
> > nothing wrong with globals in that case, globals only cause a problem
> > when the program grows very big, because it becomes hard to track all
> > the places the global is affected. Each class can be thought of as a
> > small program.
>
> Good point. So if I begin to have trouble reasoning about my helper
> methods altering state, it might be a sign that my class has gotten too
> big?
I'd say yes.
H. S. Lahman
I basically agree with Daniel T. but with a somewhat different spin on
reuse.
> Well, this is a low-level concern; it has to do with low-level
> implementation of classes, but I thought I would bring it up here
> anyway. Comments appreciated.
>
> In implementing classes, I sometimes find it helpful to write private
> "helper methods." These are methods that, as their name implies, help
> implement a class's functionality. They can improve class quality by
> breaking up a task a class needs to perform into a series of steps. So
> instead of one long public method, you have one public method which in
> turn calls several private helper methods. This is basically functional
> decomposition. But it's hidden inside a class.
>
> Anyway, I've been coming to the conclusion that these helper methods
> should be designed as true functions, i.e. they have no side-effects and
> do not depend on the state of the class.
This is true for helper methods that are reusable across classes like OS
run time library calls. Such methods should return the modified data to
the caller and let it make the assignments to local attributes. That
decouples the reuse context from the helper functionality. This is
necessary because state variables will be defined for the particular
context. IOW, the decoupling is necessary /because/ of the reuse.
However, there is no need for that in private methods that simply
decompose public behavior responsibilities or capture common processing
in multiple public methods of the same object. Any state variable
changes are already implicit in the definition of the public
responsibility. All the private method does is internally delegate some
of those responsibilities in a manner that is hidden from the client.
For example, you cannot specify DbC contracts for the public method that
do not include the specification of what the private method does. That
is clear because if one did not decompose the public method, its
specification would have to include that behavior. Nor can one unit
test the public method without an implementation of the private method.
So the private method is just an extension of the public
responsibility and any "side effects" are already explicitly part of the
public method's responsibility. IOW, using private methods this way is
an implementation choice rather than a semantic choice so it is
transparent to the client.
> If we consider an object a kind of world unto itself, then its fields
> could be considered global data at the object level. If private methods
> modify an object's fields, then within the context of the object, we
> could consider these methods operating on global data.
>
> I've been finding that this may not be such a good idea. In practise,
> I've found that private methods modifying state has the same pitfalls
> associated with using global data. A better approach may be to design
> private helper methods as static methods that have no knowledge of an
> object's state. State is passed into the helper methods by a top public
> method where the operation was initiated.
>
> A couple of advantages I've found with this approach are 1) it makes it
> easier to reason about what is going on in my class. I don't look at a
> call to a private helper method and have to ask myself in what way does
> it modify state. 2) if a public method initiates an operation that can
> fail, it can be useful to write changes to temporary values until the
> operation completes. Then the state of an object can be updated. This
> helps prevent a object being left in an undefined state if an operation
> fails before all of its steps have been performed.
>
> While we're on the subject, could helper methods be considered a code
> smell? I can see the possibility of factoring these methods into a
> seperate class. But I have to say that sometimes you just need good 'ol
> fashion functional decomposition to perform a task that from the outside
> world is seen as atomic.
No smell. How an object responds in a collaboration can be arbitrarily
complex but it is a matter of private implementation. Where OO makes
things maintainable is by ensuring that method implementations are
self-contained and properly encapsulated relative to the level of
abstraction of the role of the object in the overall solution --
regardless of how complex the lower level processing may be.
In fact, this ability to use abstraction to provide flow of control for
the unique features of the solution while hiding details that do not
affect that flow of control or exist beyond the solution scope is one of
the more powerful tools in the OO arsenal.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Nick Malik [Microsoft]
Some comments,
"Leslie Sanford" <jabber...@BiteMeHotmail.com> wrote in message
news:0K6dncP6OKpoykfZ...@comcast.com...
>
> "Daniel T." wrote:
>> "Leslie Sanford" wrote:
>>
>>> In implementing classes, I sometimes find it helpful to write private
>>> "helper methods." These are methods that, as their name implies, help
>>> implement a class's functionality. They can improve class quality by
>>> breaking up a task a class needs to perform into a series of steps.
>>> So instead of one long public method, you have one public method
>>> which in turn calls several private helper methods. This is basically
>>> functional decomposition. But it's hidden inside a class.
A number of design patterns can leverage this idea, including Strategy. It
is clearly not a bad idea.
>>>
>>> Anyway, I've been coming to the conclusion that these helper methods
>>> should be designed as true functions, i.e. they have no side-effects
>>> and do not depend on the state of the class.
>
> <snip>
>
>> A couple of comments. If the private method doesn't change state, then
>> how is it associated with the class. I mean sure the class uses the
>> method, but is there any inherent reason other classes couldn't use
>> the same method? As such, why is the method private?
>
> Hmm, well no reason really, now that you mention it. It's just that
> these functions are concerned with some pretty low level tasks. The
> class that uses these functions belongs to a higher level of
> abstraction. Exposing these methods seems like exposing implementation
> details. Other classes in my library really have no business using them.
>
I can hear the soundtrack to a horror movie... "no one has the right to use
my functions... they are MINE!" (evil laugh).
If the functions are truly at another level of abstraction, then leave them
private, by all means. If, in a later revision of your system, you decide
that another class needs to call them, then factor them out to a class that
operates at a lower level, and have both this class and your new class call
the helper.
>> As far as your idea about class fields being like global fields
>> (within this context...) Have you ever noticed how often people use
>> global fields when the program only contains a few functions? There's
>> nothing wrong with globals in that case, globals only cause a problem
>> when the program grows very big, because it becomes hard to track all the
>> places the global is affected. Each class can be thought of as a small
>> program.
>
> Good point. So if I begin to have trouble reasoning about my helper
> methods altering state, it might be a sign that my class has gotten too
> big?
>
I'm not sure if you are trying to develop a set of ideas that you will use
when creating a new class or when refactoring an existing one. I'm
hesitant, in my practice, to recommend 'good practices' at the creation time
that make code complex unless there is a good cause for it. So I like the
notion of "you know you are too big when... " since it is a rule that
applies at 'refactoring time.'
I would suggest that you may want to consider something else: your helper
methods operate at a different level of abstraction. Perhaps they are
modifying state that has to do with that level of abstraction? If so, then
you really do have two classes in one body of code. It is perfectly OK to
create a class that has only one customer. I can see a great case for it if
your helper functions are cohesive and surround their own bit of state.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
AndyW
I would suggest that you are talking about what I call service methods
and service classes. I dont view these as objects, but routines that
are used to perform actions on data. Related service routines can be
put into service classes.
Most common place one might find them is down in the application
service layer of an OSI style layered application (below the object
framework layer).
Things like common event handlers, database routines and the like. The
tools that objects might use to do things so to speak. If you have a
good set of these things you can build what I suspect is called an
application framework.
To me when you put service methods into a service class with a public
method and private helpers, it could be considered a basic form of the
template method for pattern enthusiasts.