Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Picking the Tools -- Marrying processing models to data model s
 David, I don't think your message made it to the list. Perhaps you're having the same problems I've had posting. > The reason that I think that O-O is fading is because O-O required software > developers to make 1 assumption that turned out to be completely incorrect > for performance reasons. That assumption is that the consumer of the > component does not know or care where the data in the component came from. > It turns out that consumers of components almost always care where the data > came from, such as an RDBMS. So the one whole thing that the encapsulation > hid - where the data really is - turned out to be mostly unusable. I think you're dead on here. In Alaric's rejoinder he says you're just cooking up an impedance mismatch, but I don't see his point. Encapsulation is an essential part of OO and encapsulation is one of the most problematic areas I see in OO beyond the packaging of code. The specific goal of encapsulation was originally to minimize bugs that come about when a programmer accidentally mutates variables out of context, quite a common error in languages heavy on expression side-effects. I'm not sure how encapsulation grew from this bit of tidy practice into a general modeling world view, but the result is certainly flawed. > Again, I tried on at least 5 different projects to build these re-usable > components but it just never happened. Eventually I read the einstein quote > about insane people always trying the same thing and expecting different > results, and realized where I fit in the quote. Reusability is one of the biggest lies of OO. I personally think that code reusability is the philosopher's stone: it would be a source of never-ending value, but there is the small problem that it doesn't exist. There is nothing special about OO that makes code resuse magically easier. The strange theory that inheritance is the key to object re-use is one of the reasons I've heard for the insistence of some component models on making inheritance part of large-granularity interfaces. This doesn't lend any magic reusability to components than it does to class libraries. The important thing is to focus on reusing data rather than code, and this is a separate issue from whether the code is procedural, functional, OO, etc. > The great thing about XML is that it doesn't try to head-fake you into this > false assumption that some behaviour will auto-magically wrap the real data. > XML makes you think about coarser grained functionality, while giving you > really high productivity in creating your data or adapting your data from > one system to another. The above belongs in a gallery of quotes somethere. Rem acu tetugisti: you hit the nail on the head. > To me, the biggest benefit of XML is that sooo much > functionality is pushed into parsers, processors etc. That means developers > can make re-use of these coarse grained components in a very high > productivity environment. > > I look at the single most effective way to continue developers productivity > increase is to raise the standardized component infrastructure as high as > possible - through things like XSLT, XQuery, and eventually processing > models and process languages. One nice thing about this thread is learning that I'm not as alone in my thinking as I'd assumed. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
