[ruby-talk:14117] Re: OO

-- James Ponder <[e-mail]> wrote:
> On Mon, Apr 23, 2001 at 09:42:42AM +0900, chad
> fowler wrote:
> > What kind of data will be stored in the "Options"
> > object?  What do the individual classes need from
> it? 
> > It sounds like you are creating a static
> configuration
> > mechanism.  Another coupling-related fear that I
> would
> > have is that, when you pass a full "Options" into
> an
> > object, you are probably giving that object access
> to
> > any of the data in "Options".  So, you're creating
> > possible dependencies between every object that
> uses
> > "Options" and every possible "Option".
> 
> I think I understand what you are saying, but I
> don't see how I can achieve
> this in practice.  For example, my options file
> might contain "debug=1",
> and I don't want to have to alter my classes each
> time I come up with a new
> option that several classes need to know about.
> 

Again, this is all dependent on what the "Options"
are, but with your example, you've provided a little
window into what you're trying to do.  My answer for
the "debug=1" example would be that each class
shouldn't inherently know what debugging behaviour is.
 I would centralize the debugging in a class that can
decide independently how to deal with things that ask
to be debugged.  I'm guessing that "debug=1" will
cause level 1 verbosity (however you have that
defined) logging in your application to happen.  In
that case, I would probably define a logger object
that could handle both the implementation of what it
means to actually log something and the decision of
*when* to log something (i.e. "if(debug=1)
logDebugMessage(myMessage)").

> I've been discussing this with some Java people, and
> they think I should
> be using a "singleton" - although this word appears
> to be used in Ruby as
> a way of adding methods to objects I've not seen it
> used in the same way
> that Java people use it.  Apparently in Java you do
> this by creating
> a private constructor (so that nobody can
> instantiate the class) and have a
> class variable that holds one instance of the
> object.  The object is normally
> instantiated in the class init code or in a
> "unless(obj) obj = MyClass.new()"
> way within each class method.

This is the singleton design pattern.  You might find
http://www.c2.com/cgi/wiki?SingletonPattern to be
helpful as a starting point.

> 
> > The solution I would propose is that you keep
> > "Options" outside of any objects that don't
> > specifically need it.  Then, from a controller
> object
> > (probably the same one that actually instantiates
> each
> > object), you can read "Options" and pass any
> required
> > data to the objects that need it.  With this
> approach,
> > "Options" doesn't know about your objects, and
> your
> > objects don't know about "Options".
> 
> To me, if I add an option that is applicable to one
> particular class, it
> seems bad that I have to alter the controller code,
> the class code
> AND the constructor.
> 

It could be possible to reflectively automate a lot of
this so you wouldn't have to modify each of these
classes.  It's also possible that a certain amount of
refactoring could cut down on the number of global
options your application requires.

> Or am I still thinking about this in the wrong way?
> 

Not wrong.  Just different (from me). 

later,
Chad

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/