From: Jacob Fugal <lukfugl@...>
Date: 2006-01-11T01:35:31+09:00
Subject: Re: global variables are bad??

On 1/9/06, Lyndon Samson <lyndon.samson@gmail.com> wrote:
> On 1/10/06, Steve Litt <slitt@earthlink.net> wrote:
> > On Monday 09 January 2006 10:15 pm, Lyndon Samson wrote:
> > > I guess what I was thinking was, conceivably you could have a class with
> > > say 100s of methods, all with full access to any (
> > > private/protected/public) instance variables. How is that different to 100s of
> > > functions accessing global variables?
> >
> > Why would you do that? With hundreds of methods, wouldn't these hundreds
> > of methods tend to categorize in ways that you could split the big class into
> > smaller ones?
>
> Playing Devils Advocate for the sake of the discussion, a quote from MF :-) [1]
>
> "Another factor is what the language encourages for implementing these
> structures. As Charles Miller[2] said "Java's design *affords* small interfaces,
> and utility functions provided as static methods on helper classes. Ruby's
> design affords larger classes with mixed-in utility methods."

Let me reconcile what Martin Fowler is saying there with Steve's
comment. "Ruby's design affords larger classes with /mixed-in utility
methods/" (emphasis added). The size of Array comes mostly from
Enumerable being mixed in. Take away the Enumerable mixin and you have
many fewer methods. Array may override a few of Enumerable's methods
in C for speed, but Array is a special case as a core language
construct, and it still doesn't override the majority. As such,
Array's implementation follows exactly what Steve recommended of
refactoring the bits out into different maintainable chunks. And all
of the methods mixed in by Enumerable are implementation agnostic --
all they require is that you provide an #each method which they build
upon, usually in a one liner. They don't care about or access your
instance variables, which is what this (sub)thread was about in the
first place.

Jacob Fugal

[1] http://www.martinfowler.com/bliki/DuckInterface.html
[2] http://fishbowl.pastiche.org/2005/12/09/humane_interfaces