Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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