[Tutor] refactoring book and function size

[Jeff Shannon]

Erik Price wrote:

> On Wednesday, September 18, 2002, at 10:29  AM, Magnus Lycka wrote:
>
> > On one hand, it makes each method trivial, but on the other
> > hand, it might lead to a situation where you are a bit lost
> > with all these methods. In Python there is also the time
> > involved in function call overhead to consider.
>
> I have often wondered about this.  Are classes considered "bloated" if
> they feature a ton of methods to do various things with the data
> contained within the object?  If so, is that true even if it wouldn't
> make sense to move some of these methods to a separate class (say,
> these methods are inherent behaviors that would seem best to go with
> the original object)?

I would agree that it's best to organize classes according to what
logically belongs together.  If that ends up with a few classes being
exceptionally large, then it might make sense to see if there's a
different approach that would logically decompose those large classes.
But it does *not* seem like a good idea to artificially separate a class
that makes logical sense, strictly on the basis of code size.  (If you
look at GUI toolkits, the class for "window object" is invariably large
and complex -- but this is such an important and complex role that it
would be hard to make a case to do otherwise.)


> I find it easier to have a single method that does what I need than to
> have four methods that can be combined to do what I need (unless of
> course I ever have need for one of those four methods individually).
> It's less information about the class's interface that I need to
> remember.  But that might not be the best approach to be taking.

One possible approach to this is to have those four methods be "private",
and then have a single public method that calls them in the proper
combination.  That way, you have the simple interface that you desire, and
yet each method implementation is small, simple, and easy to understand.
In Python, the distinction between public and private methods is blurred,
but still exists to some extent -- if nothing else, method names beginning
with a single underscore are recognized by convention as being private,
and method names beginning with two underscores are mangled with the
classname to "enforce" privacy.  I find it very helpful to be able to
designate some methods as being "for internal use only", and some methods
as "external interface".

Jeff Shannon
Technician/Programmer
Credit International