From: "Ara.T.Howard" <ahoward@...>
Date: 2004-07-01T00:42:56+09:00
Subject: Re: SOT (slightly offtopic): General OOP question

On Wed, 30 Jun 2004, 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?

i would agree with that.  the only time you have problems are if the files are
huge.  in that case you may have to provide iterators.  i have a class that
does exactly that for dmsp satelite data.  the data is organized like:

start header
key=value
k2=v2
end header
....
binary records
....
binary records
...

so i parse the header and then mmap in the rest of the file (massive kernel
bug with this for rhe.  note to all interested parties) and provide accessors
for header values and scanlines

   satelite = ols.header[ %r/sat/o ]
   scanline = ols[ 42000 ]

and i've also provided iterators like

   ols.each_scanline do |scanline|
     scanline[0..42] = 255
   end

which map back changes made to the scanline

i'm quite happy with the abstraction and have been able to do a lot of useful
work quickyly with the design...  i've got similar classes for envi header
files and other data formats.


> 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?

i've struggled with this one alot.  but lately i've been making 'Main' classes
which parse their options into a hash removing the leading '--' chars.  for a
while i was a fan of using symbols as hash keys, but now use only strings.
this is mostly due to the wonderful ease of using yaml files as
configuration files.  when developing i make even unrecognized options load
cleanly into the options hash without warning.  then i pass this hash to
relevent methods, for instance

   class Main
     def run
       @opts = parse_opts
       @config = parse_config
       @options = @config.update @opts

       @worker = Worker.new arg, @options
     end
   end

   class Worker
     def intialize arg, opts = {}
       @arg = arg
       @opts = opts
     end
     def do_work
       if @opts['some_option']
         ...
       elseif @opts['some_new_option_just_passed_from_command_line']
         ...
       end
     end
   end

which allows me to quickly get info from the command line or a yaml config
file deeply into my code without having to explictly pass it or make some sort
of globally accessible config.  now that i think about it this is probably
terrbile OO design according to meyer or someone like that... but for the
people up the hall asking 'can you add XXX in 5 minutes' it's probably 'good'
OO design.  ;-)


> 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.
>
> Is there any "official" rule of OOP, which I can guide me for better
> deciding in such thing ?

i choose the path that solves the problem quickly and that can adapt to
variations quickly - over extreme robustness - but i'm probably in the
minority.

> Thank you very much in advance for any help ! :O)
>
> Kind rgards,
> Meino

very cool questions.

-a
--
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. 
|   --Dogen
===============================================================================