Object Technology
.
Design Patterns and Language Design Joseph (Yossi) Gil, IBM T.J. Watson Research Center David H. Lorenz, Technion, Israel Institute of Technology
espite many similarities, there are important differences between design patterns and programming language mechanisms. Nevertheless, we can classify patterns in terms of how far they are from becoming actual language features. Treating patterns as mechanisms that are candidates for being language features—rather than treating them as what they are meant to be—can help demystify them. Clichés, for example, can be defined as sophisticated macros of existing features—that is, mechanisms that are so trivial they are not worthy of implementing as features. And idioms are just a matter of emulating a language feature by a language that misses it. But cadets are the “real patterns,” the abstractions that are not yet sufficiently mature or important enough to be language features. Still, the know-how cadets capture is important enough to be collected and recorded as patterns. Indeed, a systematic approach to patterns can be achieved only if we disregard intent—a much too glorified component of patterns.
D
Editor: Bertrand Meyer, EiffelSoft, ISE Bldg., 2nd Fl., 270 Storke Rd., Goleta, CA 93117; voice (805) 685-6869; ot-column@ eiffel.com
118
Computer
expressed—may be subjected to an analytic approach. Mathematics provides a good analogy for this distinction: There is no mathematical theory to deal with the intellectual process of coming up with a new theorem and a proof for it. But theorems and proofs are expressible using wellunderstood mathematical theory. In the software world, while we can’t be precise in the theory of the design process, the means for expressing the details of a design—such as languages and notations—can be the subject of analytic study. Viewed from this perspective, each language is a toolbox of abstraction mechanisms. Object, class, and inheritance, for example, are the fundamental abstraction mechanisms in object-oriented languages. Although the majority of the modern software engineering community is united in believing in these particular mechanisms, there is an immense variation in the way mechanisms are manifest in different languages.
ABSTRACTION IN LANGUAGES
The process of discovery cannot be studied in the same way that the laws of physics are studied and analyzed.
ABSTRACTION Abstraction, a fundamental objective of good software development, is the process of identifying commonalities and then capturing them in abstraction mechanisms. There are two distinct aspects to abstraction: process and mechanism. Regretfully, understanding the manner in which we identify abstractions is beyond the domain of exact sciences. The process of discovery cannot be studied in the same way that the laws of physics are studied and analyzed, although these laws themselves are the product of a discovery process. In contrast, the abstraction mechanisms—the means by which the discoveries are
An exact definition of a mechanism or a feature must cover many different details and must answer many questions. Is multiple inheritance allowed? How should ambiguity be dealt with? Can data members be overridden by methods? No language designer can rest before all of these questions are an-swered. It is even more difficult to combine several mechanisms. And of course weird combinations of language features must be taken care of in order to give even absurd programs a well-defined semantics. Language design is an art as much as it is a delicate and extremely difficult engineering task. The designer picks the most useful, powerful, and definable mechanisms and endeavors to strike a careful and coherent balance between utility and complexity. Language designer testimonials are indicative of the amount of effort put into creating a language and the severity of the incurred internal struggle. Protocols of language standardization committees show how difficult it is to introduce a feature to an existing one. Most current OO languages stay at the
.
level of abstraction in which the class serves as a module and in which one variation of the inheritance notion is the main tool of system assembly. These abstraction mechanisms are low level and deal with relatively small subsystems. Higher level lingual abstraction mechanisms—those that specify the simultaneous interaction of several classes, a system, or a framework—are rarities. They are too costly to articulate as part of a programming language and too specialized to justify the price. Although high-level mechanisms are what the software engineer most desperately needs, programming languages can only provide lower level ones. This problem—which we can call the mechanismlevel barrier—is not overcome by the fact that any good language allows its users to formulate their own abstractions using existing mechanisms, such as procedure libraries or collections of reusable classes. However, while languages do not typically provide the means for the user to develop higher-level abstractions, design patterns do.
DESIGN PATTERNS Design patterns enhance the power of object-oriented mechanisms by capturing nontrivial relationships and interoperations. Just as a procedure is more powerful than the set of assembly instructions required to implement it, design patterns are effectively greater than the sum of their parts. A design pattern does not have to be a closed solution, nor must it work in all circumstances and with all other mechanisms, which means that design patterns can break through the mechanism-level barrier. As opposed to a compiler, which must be prepared to deal somehow with any application of a lingual mechanism, a human applying a pattern mechanism can consider and adapt to the specific circumstances of each application. Design patterns therefore offer a kind of pay-per-use approach: A software engineer can use an entire toolbox of abstraction mechanisms that can be manually adapted to various circumstances. What is saved is the up-front expense of a well-integrated set of general-purpose mechanisms.
Design patterns are therefore nothing but “puppy” features. In other words, design patterns could—and sometimes should—grow to be language features, although they aren’t generally implemented as such. Consider, for example, the language independence trait in which many design and analysis methods (such as Open and Catalysis) and notations (such as Comm and UML) pride themselves. Design patterns candidly admit they are not language-independent.
If we are not careful, progress in thinking about patterns might be as illusory as progress in the world of fashion. IDIOMS Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Design Patterns—Elements of Reusable ObjectOriented Software, Addison-Wesley, 1994) have said: “Point of view affects one’s interpretation of what is and isn’t a pattern. One person’s pattern can be another person’s primitive.” The Gang of Four also suggest that “Choice of programming language is important because it influences one’s point of view.” Many patterns—which we shall call idioms— are features of some existing language, but not the ones in which they are being applied. An alternative, somewhat cynical description of idioms suggests they are cover-ups for the shortcomings of a language. According to this position, the worst languages are the best greenhouses for growing idiom patterns. Unfortunately, we cannot always wait for an idiom to become a feature in some language and then afford the transition to that new language. Indeed, the Gang of Four state: “If we assumed procedural languages [as opposed to OO languages], we might have included patterns called inheritance, encapsulation, and polymorphism.” Conversely, if a programmer uses Eiffel, then idiom patterns such as prototype and memento wouldn’t exist because
their purpose would be served by that language’s deep copy and persistence mechanisms. Similarly, there is very little need for the visitor pattern if you use multimethod OO languages such as CLOS and Cecil.
A SMALL TAXONOMY In contrast to idioms, cadets are patterns that are candidates for making their way into a language, but are not yet a feature of any language because • They do not constitute a substantial elevation of abstraction over what is available in the language. In other words, the pattern can be adequately described with few simple guidelines (or even just one). The template-method pattern, for example, is a standard technique for using dynamically bound methods. Some more examples of these are null object and facade. Such low-level patterns are better called clichés. • They are not cohesive enough to become a language feature. For example, the semantics of the state pattern is somewhat vague in its current form. • They are not prevalent enough to justify inclusion as a feature in a general-purpose language. The command pattern, for example, is peculiar to GUI systems. Similarly, the flyweight pattern can be thought of as an optimization technique. Among cadets, we can distinguish two kinds: relators and architects. Relators are those patterns that capture the relationship between a small number (typically two) of language entities, such as objects and classes. Relators can include patterns like adapter, bridge, decorator, proxy, chain of responsibility, mediator, memento, observer, state, and strategy. In many ways, relators offer a variation on the inheritance theme because they prescribe various kinds of responsibility delegation among classes. Architects, on the other hand, are patterns that describe the architectural structure of a large number of entities, including patterns such as composite and builder. Architects grow out of their linMarch 1998
119
.
Object Technology
®
CALL FOR SUBMISSIONS
gual infancy into new language paradigms. For example, in terms of this definition of architects, dataflow languages can be thought of as a more mature form of the pipeline architecture. (See M. Shawand and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996.)
UNBUNDLING THE INTENT
D IGITAL L IBRARIES : T ECHNOLOGICAL A DVANCEMENTS AND S OCIAL I MPACTS Submissions Due: May 15 Acceptance By: November 1 Publication Date: February 1999 Specific areas of interest include: ❖ Large-scale projects to develop real-world electronic testbeds for actual users and that aim to develop new, user-friendly technology for digital libraries. ❖ Research projects that examine the broad social, economic, legal, ethical, and cross-cultural contexts and impacts of digital library research.
Guest Editors: Hsinchun Chen University of Arizona
[email protected] Bruce R. Schatz University of Illinois
[email protected] For more information, see the complete call on p. 92 of this issue and the detailed author guidelines at http://computer.org/computer
120
Computer
This taxonomy can help us better understand the relationships between language features and patterns, but it does not help us understand the patterns themselves. Despite the similarities between patterns and well-defined language features, patterns have so far defied all attempts at analytic description. For example, pattern taxonomy is still a largely elusive goal, as is evident from the numerous failures to achieve it. This might seem odd at first sight: Being half-baked mechanisms, patterns seem to be ideally suited to be objects of investigation. The fundamental reason behind failures to successfully analyze patterns, however, is the spreading fallacy of bundling—within a pattern— both the pattern’s internal working and its intent. Intent transgresses the boundaries of exact science, which is limited to “how” rather than “why” questions. A systematic approach to patterns can be achieved only if the intent is disregarded. This is not to say that patterns—and abstraction mechanisms in general—should be beautifully abstract mathematical creatures, void of intent. Any tool must have an intent, but intent should be broad, open to variation, and never inscribed in the tool itself. The best tools are versatile. A good can opener, for example, should work for oval and round cans or for both Campbell soup and Starkist tuna. Or, to draw an example from mathematics, when group theory was conceived, its applications to modern physics could not have been fathomed. The basic mathematical structures—field, ring, group, and so forth—are understood not by their many uses but by the rules that govern their behavior. For example, the inheritance mechanism has proved to be powerful because it does not impose only
one kind of use. (See B. Meyer, ObjectOriented Software Construction, Prentice Hall, 1997, and T. Budd, Introduction To OO Programming, Prentice Hall, 1997.) An example of an interesting way to determine the tool’s intent is the creative writers’ workshop technique of presenting newly discovered patterns. The writers workshop has made the description of a technical tool (like a design pattern) into something very different from an engineering task. Writers workshops are new to exact science, but the technique is not entirely novel. It is applied extensively to all kinds of creative writing environments, therapeutic or educational. In these environments, the author’s style—not the document with its novelty—is put at the center of the evaluation process. Abandoning the analytic world collects tolls. It becomes impossible to tell whether two separately described patterns are the same or not, or whether something is a pattern at all. No agreed-upon taxonomy of patterns exists, and there is no established path for learning about or searching for patterns. In place of taxonomies, illusive notions (like “quality without a name”) generate endless futile debate.
little chaos and some wasted time are only minor consequences when compared to the real danger, which is that, in the absence of objective criteria, progress in the theory of patterns becomes hard to recognize or appreciate. If we are not careful, progress in thinking about patterns might be as illusory as progress in the world of fashion, which moves with hemlines but not toward any recognizable goal. ❖
A
Joseph (Yossi) Gil is a visiting scientist at IBM’s T.J. Watson Research Center. Contact him at
[email protected].
David H. Lorenz is a PhD candidate at the department of computer science at Technion-Israel Institute of Technology. Contact him at
[email protected]. ac.il.