[REBOL] Re: Object Oriented design
From: greggirwin:mindspring at: 7-Jan-2002 12:52
Hi Patrick,
<< I have the feeling that object orientation could be the way to produce
more
elegant program, even with Rebol. After reading a couple of books, I feel
very frustrated. The subliminal message is OOP can do that, OOP is elegant,
you save time with OOP, etc. >>
Yes and no (IMHO). OOP isn't magic, and is not a silver bullet. It can be
misused and abused just like anything else. I've written a reasonable amount
of OO code but there is only one criteria, of the big three, which I find
indispensible. I can live without inheritance and polymorphism, but
encapsulation is terrifically important I think.
My favorite OO book is 'Object Oriented Software Construction' by Bertrand
Meyer. I'm a big believer in Design by Contract (assertions) because it
makes you *think* about what's valid, what isn't, and what you are going to
do when the rules are broken.
I've only been working with REBOL for about 6 months but my style, and
thinking, are totally different than if I were working in VB (my previous
choice of language). In VB, I know I can produce moderately sized systems
reliably, and I spent a lot of time building up a "toolbox" that makes me
very productive. I'm a tool builder (by nature I suppose). I enjoy writing
tools that make my life easier, and VB is great for that. I don't like huge,
monolithic, systems. Most projects I've architected rely on a small number
of core libraries and are composed of small applications that work together
to form a complete system. I can see using REBOL in the same way, but I also
need to find my "REBOL voice" (i.e. style and work habit), and re-build my
toolbox.
I like to think I'm very pragmatic. I usually target a simple, low tech,
approach whenever possible. I use OO design and construction when I feel
it's appropriate. The key is to use 'as much process as necessary'. If
you're working on a multi-million line project with hundreds of developers,
a very formal methodology may be suitable. If someone says "I need this file
conversion utility by tomorrow" you can probably design and construct it in
a relatively informal manner.
>From the function level, to the module/library level, to the application
level, I like to build small pieces that I can define, construct, and test
independently. If they have well defined interfaces and behave as expected,
it is my experience that integration is greatly facilitated. Those
interfaces may be COM calls, messages sent via sockets, command lines, or
any number of things. This approach provides me with the encapsulation that
I find so helpful and I can do it without using OOP, technically.
IME, OO may help you manage complexity but it also adds complexity. The goal
of using inheritance and polymorphism to reduce and reuse code often leads
to writing more code to support those goals and, again, adds more
complexity.
Just some thoughts. Hope they're helpful.
--Gregg
