A Position Statement on Object Oriented Design

Doug Lea
State University of New York at Oswego. Oswego NY 13126
dl@cs.oswego.edu http://g.oswego.edu/dl

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:

• Specification and design techniques that reflect the intrinsic incompleteness and uncertainty of open systems, in several different senses. For example, dynamically evolving components and their configurations; open implementations in which other developers and users can selectively customize functionality; the presence of distributed failure; authentication and security as only relative qualities.
• Architectures and protocols that deal with access to and quality of software services, bandwidth, persistent storage, and other resources as commodities in an open computational market.
• Design across multiple computational models. The term Object has grown to apply to computational entities ranging from hardware-level objects to procedural C++ objects to concurrent Java objects, to mobile Obliq objects, to active-database objects, to fine-grained parallel Actor objects to coarse-grained distributed CORBA objects, and many points in between. While they share core features and semantics, each of these models forms the basis for differing sets of design forms and programming techniques. The inevitable mixtures necessitate intrinsically reflective methods and components that map across models.

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 permissions@acm.org.