Unlearning Object-Oriented Theory

Back in the programming nursery, life seemed simple. An object was introduced to us as a data structure that you could give instructions to, using things called methods. We were taught all about inheritance, encapsulation and polymorphism, and a great future beckoned. All we had to do was use objects all the time and our software would be better structured, more maintainable and, joy of joys, reusable! So, every time we saw something that looked like a data structure, we dutifully wrapped it up inside an object, and waited to reap the rich rewards that would in time accrue to us.

Since then, one or two curious things have happened.

First of all, reusable software is still largely a fiction that exists only in the minds of managers who are eager to cut costs. I recently met an object-oriented design guru, who, of all people, would surely have been eager to promote the concept. However, according to him, the standard greeting when one object-orientation guru meets another at a conference is “Seen any re-use yet?” to which the standard reply is “Nah.”
Secondly, Visual C++ and Visual Basic have emerged to dominate the market for object-oriented software on the Windows platform. Setting aside any question of whether Visual Basic is object-oriented or not, the net result is that object-oriented programming is often seen simply as a neat way of wrapping up the idiosyncrasies of Windows messaging, and making the manipulation of visual controls simpler.
Thirdly, object-oriented databases have (so far) failed to deliver, and the relational model remains firmly entrenched. There seems to be little value in maintaining persistent data in an object-oriented format.

Does this mean, then, that we should pack non-visual objects in altogether? Obviously not, because, for one thing, that would undermine most of the rationale for this book. Besides, objects (and COM objects in particular) turn out to be excellent vehicles for representing business processes, and, in particular, transactions. However, if we are to develop really useful business objects, we’re going to have to separate the business logic from the underlying data.

I think it’s time to introduce the three-tier model. (I’m still itching to do some MTS coding, by the way. It’s just that there’s a lot of stuff we need to get out of the way before we get going…)