ACM Computing Surveys 28A(4), December 1996, Copyright © 1996 by the Association for Computing Machinery, Inc. See the permissions statement below.

A Position Statement on Object Oriented Design

Doug Lea
State University of New York at Oswego. Oswego NY 13126

Increasingly, Object-Oriented software development practices dominate all realms of software construction, from information appliances to large scale distributed financial systems; from WWW applets to operating systems. Yet, even as OO languages, infrastructures, methods, and tools continue to mature, the design of such OO systems and applications remains something of a black art.

Across most applied science and engineering disciplines, the transition from craftsmanship to engineering took place only when enough basic and applied knowledge was codified so that just about anyone with sufficient training could be expected to apply this knowledge in the creation of artifacts that affected people's lives. Object-Oriented Software Engineering (increasingly indistinguishable from just ``Software Engineering'') is of course not yet at this transition point. We (the research community) are only slowly learning enough about what we (the developer community) already know and/or should know about design to make much headway along these fronts.

Much of this remains at a pre-formal stage, pushed hardest by (mostly non-academic) members of the OO Patterns and software architecture communities collecting, encapsulating, and synthesizing existing design knowledge in a bottom-up manner across an increasingly wide spectrum of domains ranging from user interfaces to control systems to financial systems, and so on. But this is only a beginning. We currently lack some of the tools, formalisms, and even concepts to systematize the analytic study of those aspects of software design that matter most to developers.

The prototypical analytic issues here surround questions of what makes a particular design form good, adequate, or even applicable in a particular system or programming task. Outside of some narrow criteria (time and space complexity, safety, liveness, and reliability) applying only to narrowly construed aspects of structure and functionality, researchers have almost nothing to say about matters that have become the most central aspects of software development. For a random example, what is it about the Observer design pattern that has led to its incorporation in perhaps the majority of OO systems that have ever been built? Currently, the best we can do is invoke ill-defined notions such as extensibility, composibility, reusability, and separation of concerns. While it seems unlikely that there can ever be a universal theory of software design, surely we can do better than this. And until then, those of us who are educators can at least teach future software developers about best practices and design forms even when we are forced to admit that we are not quite sure why they are best.

These concerns become even more pronounced when applied to design problems that lie at the boundaries of our abilities to even characterize. As OO software leaves the realm of self-contained custom systems and shrink-wrapped applications, and enters that of component-based, reactive, dynamically evolving, distributed, open systems (for example residing on the WWW) developers require new design methods, design forms, and analytic techniques. So rather than, or in addition to codifying existing knowledge, researchers and advanced developers have the opportunity to help shape the (near!) future of software design. These include areas of research that in some cases have long existed in isolation, but remain insufficiently developed. For example:

And amid these kinds of issues lies increasing pressure to make software design and implementation simpler. A significant fraction of the people on this planet are or soon will be WWW ``consumers''. Many consumers become ``content providers''. Many content providers become ``untrained'' programmers on the most complex system we have ever built, the internet. The codification of engineering techniques and the development of tools and components that support their application can help all of us to construct software that is, if not correct by construction, at least not stupidly or dangerously wrong.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or

Doug Lea
Last modified: Tue Oct 1 07:30:09 EDT 1996