From: Robert Klemme <bob.news@...>
Date: 2004-07-01T17:12:50+09:00
Subject: Re: SOT (slightly offtopic): General OOP question


While others have answered this competent I'd like to add some remarks:

"Meino Christian Cramer" <Meino.Cramer@gmx.de> schrieb im Newsbeitrag
news:20040630.161538.39157221.Meino.Cramer@gmx.de...
> Hi,
>
>  I have a general question about OOP.
>
>  There is no problem for me to decide how arrange and design classes
>  _inside_ of a program but I get a "problem" regulary, when trying to
>  decide what to do with "things between" the program and the outside
>  world.
>
>  For example:
>  A Ruby script should read a file and do something with its contents.
>  What does the "clean white rule of OOP" say:
>  The "physics of the file" (open(),read(),close() and the according
>  error handling) become a class returning an object "containing"
>  the Filehandle? Or the contents of that file?

That depends on the usage.  If you do something stream oriented, you will
likely be working with an IO instance - that is already an abstraction of
a stream.  On other occations, where you just need the contents of a file
you might just write a function that returns the whole contents in a
string or in some other kind of object.

>  Other example:
>  I want to write a script which correspond with the user with the
>  classic UNIX-like opetions.
>
>  Shall i make a class for handling the options alone and returning an
>  object containing...what? The accordingly set configuration
>  variables? The options alone, so that the other classes can take the
>  informations they want?
>
>  Or is it more "OOP-like" when this class will handle "more"...

If you have a huge complex application, having a single class with all the
settings has the drawback, that all modules / components of your
application physically depend on this class and this class in turn depends
conceptually on all components.  Although this is not a circular
dependency in the strictest meaning of the term, I regard it problematic,
because the single settings class will quite likely grow very large and
thus the likelyhood of name collisions increases; plus you can't separate
all modules easily from each other.

Having one config class per component is IMHO a superior approach.  Of
course you then need a single place in the program that fetches config
info from the outside world (command line, rc file, a database - whatever)
and initializes individual settings classes.

But, of course that depends on your application's size.  You might have
only a single instance of some class at the top script level that does all
the work and thus will carry config info as well.  In that case
introducing an extra class for this would be overhead.

As always, these kind of questions can't be answered on a general basis.
It depends... :-)

Kind regards

    robert