On Wednesday 30 June 2004 07:15, Meino Christian Cramer wrote:
> 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?

OOP doesn't say anything about what the contents should be, only that objects 
should encapsulate the contents safely.  You are free to arrange any design 
pattern you want.  Doing either is perfectly acceptable.

>  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"...
>
>  Or in other words: When it comes to data, which travel between the
>  inside world and the outside world of a script I am not sure to
>  decide how much of work the accompanied Class will do with them.

I usually hold command-line options, application-specific environment 
variables and configration file settings grouped together as constants in a 
container module (so they're available globally like MyModule::OPTION) and I 
read all three sources, setting the constants as I go.

>  Is there any "official" rule of OOP, which I can guide me for better
>  deciding in such thing ?

There are lots of things written on the principals of OOP (Google turns up 
many hits on the subject), but once you know the basics, experience is the 
best teacher.

	Sean O'Dell