18.7 Making the Objects Option Work

This stuff isn't designed to be easy for the beginner, and the complexities are more than syntax-deep. In addition to the operational limitations we have discussed, the act of "thinking objects" is not a trait that comes naturally to programmers schooled in database or structured approaches. But if you feel intimidated, take heart from this advice: "There may be an OO revolution, but that does not mean you have to make the change all at once. Instead, you can incorporate what you know worked before, and bring in the best that OO has to offer, a little at a time as you understand it."[16]

[16] See Rick Mercer and A. Michael Berman, "Object-Oriented Technology and C++ in the First Year: Ten Lessons Learned." Presented at the Northeastern Small College Computing Conference, April 18- 20, 1996, and on the web at http://www.rowan.edu/~berman/tenLessons/paper.htm.

If object technology is such a challenge, what is it that drives many organizations to consider object approaches in the first place? The overriding interest of managers seems to be their desire to reuse rather than reinvent the software needed to run their businesses.[17] In industries whose automation needs are not satisfied by off-the-shelf solutions, IS managers are continuously squeezed by the need to deliver more and more solutions while maintaining their legacy code, all while attempting to keep costs under control.

[17] See Ivar Jacobson, "Reuse in Reality: The Reuse-Driven Software-Engineering Business." Presented at Object Expo Paris, available at http://www.rational.com/support/techpapers/objex_ivar.pdf.

It may not be obvious from our examples just how the objects option is going to facilitate reuse, particularly given Oracle8.0's lack of inheritance and difficulties with schema evolution. Indeed, the benefits of an object approach do not automatically accrue to the practitioner; large systems, in particular, must exhibit other characteristics.[18] Achieving reuse requires careful planning and deliberate execution.

[18] See Grady Booch, Object-Oriented Analysis and Design with Applications, Addison-Wesley 1994.

Experts recommend not attempting object approaches just because someone says they are cool or because everyone else is doing it. Without a financial and time commitment to understanding, and without taking advantage of a different programming model, you are not likely to get much benefit, and yours will join the landscape of projects that didn't deliver.

Yes, object approaches can be a way to do more with less. In fact, computer industry pundits assert that "componentware" is becoming the dominant form of software, and that application development is evolving into a process of wiring together components -- whether built in-house or procured -- rather than developing software from scratch. These components are typically built using object design (to specify the component's interfaces, and what it will and won't do) and object-oriented programming languages. The game isn't over, though; we need look only as close as the nearest desktop computer to see both the benefits and the perils of componentware. Windows DLLs, for example, allow module sharing and dynamic loading, but lack a superstructure for managing multiple versions. Other component models exist (CORBA, ActiveX, COM, JavaBeans) in varying states of industry acceptance.

Almost certainly, Oracle Corporation will be adding needed features such as inheritance and schema evolution tools to their objects option. One day, objects may even be a standard part of the server. Until the technology matures, early adopters will enjoy the pleasures of finding workarounds, and will gain a deeper appreciation of features that appear later in the product.