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
···
On Wed, 30 Jun 2004, Meino Christian Cramer wrote:
--
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
===============================================================================
