Protected Variation: the Importance of Being Closed Craig Larman

design

Editor: Martin Fowler, Thought Works ■ [email protected]

Protected Variation: The Importance of Being Closed Craig Larman

he Pattern Almanac 2000 (Addison- OCP and PV formalize and generalize a Wesley, 2000) lists around 500 soft- common and fundamental design principle ware-related patterns—and given this described in many guises. OCP and PV are reading list, the curious developer has two expressions of the same principle— Tno time to program! Of course, there protection against change to the existing are underlying, simplifying themes and code and design at variation and evolution principles to this pattern plethora that de- points—with minor differences in emphasis. velopers have long considered and dis- I am nominating the term protected varia- cussed. One example is Larry Constantine’s tion for general use, as it is short and clear. coupling and cohesion guidelines In OCP, the term module includes all dis- (see “Structured Design,” IBM crete software elements, including methods, Systems J., vol. 13, no. 2, 1974). classes, subsystems, applications, and so forth. Yet, these principles must contin- Also, the phrase “closed with respect to X” ually resurface to help each new means that clients are not affected if X generation of developers and ar- changes. For example, “The class is closed chitects cut through the apparent with respect to instance field definitions.” PV disparity in myriad design ideas uses the term interface in the broad sense of an and help them see the underlying access view—not exactly a Java or COM in- and unifying forces. terface, for example. One such principle, which Bertrand Meyer describes in Ob- Information hiding is PV, ject-Oriented Software Construction (IEEE not data encapsulation Press, 1988), is the Open–Closed Principle: “On the Criteria To Be Used in Decom- Modules should be both open (for extension posing Systems Into Modules” is a classic and adaptation) and closed (to avoid modifi- that is often cited but seldom read. In it, Par- cation that affect clients). OCP is essentially nas introduces information hiding. Many equivalent to the Protected Variation pattern: people have misinterpreted the term as mean- Identify points of predicted variation and cre- ing data encapsulation, and some books er- ate a stable interface around them. Alistair roneously define the concepts as synonyms. Cockburn did not know of OCP when he Parnas intended it to mean hide informa- first wrote about PV (see “Prioritizing Forces tion about the design from other modules, in Software Design,” Patterns Languages of at the points of difficult or likely change. To Program Design, vol. 2, Addison-Wesley, quote his discussion of information hiding 1996). Furthermore, OCP is what David Par- as a guiding design principle: nas really meant by information hiding (see “On the Criteria to Be Used in Decomposing We propose instead that one begins with a Systems into Modules” Comm. ACM, vol. list of difficult design decisions or design 12, no. 2, Dec. 1972). decisions which are likely to change. Each

module is then designed to hide tional mapping, property files, reading guage services protect the system from such a decision from the others. in window layouts, and much more. the impact of logic or external code The system is protected from the im- variations. We could also consider this That is, Parnas’s information hiding is pact of data, metadata, or declarative a special case of data-driven designs. the same principle expressed in PV or variations by externalizing the variant, OCP—it is not simply data encapsula- reading the behavior-influencing data Pick your battles tion, which is but one of many tech- in, and reasoning with it. As an example of PV’s application, niques to hide design information. a client explained that the logistical However, the term has been so Service lookup support application used by an airline widely reinterpreted as a synonym for Service lookup includes techniques was a maintenance headache. There data encapsulation that it is no longer such as using naming services (for ex- was frequent modification of the possible to use it in its original sense ample, JNDI) or traders to obtain a business logic to support the logistics. without misunderstanding it. This arti- service (such as Jini). This approach How do you protect the system from cle should be called, “The Importance uses the stable interface of the lookup variations at this point? From the of Information Hiding,” in honor of service to protect clients from varia- mechanisms to support PV (data en- Parnas’s description of the PV princi- tions in the location of services. It is a capsulation, interfaces, indirection, ple. Dijkstra earlier alludes to the prin- special case of data-driven designs. …), a rule-based design was chosen: ciple in the “THE” project, but Parnas A rules engine was added to the sys- gave it focus and shape (Dijkstra, “The Interpreter-driven designs tem, and an external rule editor let Structure of the ‘THE’ Multiprogram- Interpreter-driven designs include the subject matter experts update the ming System,” Comm. ACM, 1968). rule interpreters that execute rules read rules without requiring changes to the from an external source, script or lan- source code of the system. Mechanisms motivated by PV guage interpreters that read and run Low coupling and protection PV is a root principle motivating programs, virtual machines, neural net- against variations is not motivated in most of the mechanisms and patterns work engines that execute nets, con- all areas. You must pick your battles in programming and design that pro- straint logic engines that read and rea- in design, be they at the macro-archi- vide flexibility and protection from son with constraint sets, and so forth. tectural level or the humble instance variations. Here are some examples. This approach lets you change or para- field. A good designer can identify the meterize a system’s behavior through likely points of instability or variation Familiar PV mechanisms external logic expressions. The system and apply PV to those points but not PV motivates data encapsulation, is protected from the impact of logic others. Otherwise, effort is wasted interfaces, polymorphism, indirec- variations by externalizing the logic, and complexity may arise (and with tion, and standards. Components reading it in (for example, rules or a it, the chance for defects). such as brokers and virtual machines neural net), and using an interpreter. For example, I recall being surprised are complex examples of indirection. by the occasional use of static public fi- Reflective or metalevel designs nal fields in the Java technology li- Uniform access An example of a reflective or meta- braries (after spending many years with Languages such as Ada, Eiffel, and level design includes using the java. the Smalltalk libraries). Some might be C# support a syntactic construct to beans.Introspector to obtain a Bean- poorly conceived, but some, such as express both a method and field ac- Info object, asking for the getter the Color static fields red, black, white, cess in the same way. For example, Method object for bean property X and so forth, are extremely stable; the aCircle.radius might invoke a ra- (that is, the method getX), and calling likelihood of instability is so low that dius():float method or directly refer Method.invoke. Reflective algorithms making them private and adding ac- to a public field, depending on the that use introspection and metalan- cessing methods is just object purism. definition of the class. You can As a counterexample, I know of change public fields to access meth- a pager-message-handling system in ods without changing the client code. You must which the architect added a fancy scripting language and interpreter to Data-driven designs pick your battles support some flexibility. However, dur- Data-driven designs cover a broad in design, be they at the ing rework in an incremental release, family of techniques, including reading the complex (and inefficient) scripting codes, values, class file paths, class macro-architectural was removed—it wasn’t needed. names, and so forth, from an external level or the humble source in order to change the behavior instance field. Judicious PV and the of or “parameterize” a system in some Diamond Sutra way at runtime. Other variants include Constantine’s guideline to design style sheets, metadata for object-rela- with low coupling is a truly core prin-

90 IEEE SOFTWARE May/June 2001 DESIGN ciple of design, and it can be argued and brittle designs. If the need for PV is a fundamental design principle that PV derives from it. We can priori- flexibility and PV is immediately ap- that applies to everything from the tize our goals and strategies as follows: plicable, then applying PV is justified. largest architectural concerns to the However, if you’re using PV for smallest coding decision. Furthermore, 1. We wish to save time and money, speculative future proofing or reuse, it underlies the motivation and advice reduce the introduction of new then deciding which strategy to use is of most other patterns and principles. defects, and reduce the pain and not as clear-cut. Novice developers As Parnas explained 30 years ago— suffering inflicted on overworked tend toward brittle designs, and inter- and as has resurfaced in the writings of developers. mediates tend toward overly fancy Meyer and Cockburn—each genera- 2. To achieve this, we design to min- and flexible generalized ones (in ways tion of software developers needs help imize the impact of change. that never get used). Experts choose seeing mountains as mountains again 3. To minimize change impact, we de- with insight—perhaps choosing a sim- —especially after four years of com- sign with the goal of low coupling. ple and brittle design whose cost of puter science and 500 patterns! 4. To design for low coupling, we change is balanced against its likeli- design for PVs. hood. The journey is analogous to the well-known stanza from the Diamond Acknowledgments Low coupling and PV are just one Sutra: OCP, as described here, was brought to my set of mechanisms to achieve the goals attention by Bob Martin in The Open-Closed Principle: C++ Report, SIGS Publications, of saving time, money, and so forth. Before practicing Zen, mountains 1996. Sometimes, the cost of speculative fu- were mountains and rivers were ture proofing to achieve these goals rivers. outweighs the cost incurred by a simple, highly coupled “brittle” design While practicing Zen, mountains that is reworked as necessary in re- are no longer mountains and Craig Larman is director of process and methodology at Valtech, an international consulting group. He holds a BSc and sponse to true change pressures. That rivers are no longer rivers. an MSc in computer science, with research emphasis in artificial is, the cost of engineering protection intelligence. He is the author of Applying UML and Patterns: An at evolution points can be higher than After realization, mountains are Introduction to Object-Oriented Analysis and Design, and he is writing a second edition that will include OCP/PV as one of the reworking a simple design. mountains and rivers are rivers fundamental design principles. He is a member of the IEEE and My point is not to advocate rework again. ACM. Contact him at [email protected].

How to Reach Us

Writers Subscription Change of Address For detailed information on submitting articles, write for Send change-of-address requests for magazine subscriptions to our Editorial Guidelines (software@ computer.org), or [email protected]. Be sure to specify IEEE Software. access computer.org/software/author.htm. Membership Change of Address Letters to the Editor Send change-of-address requests for the membership directory to Send letters to [email protected]. Letters Editor IEEE Software Missing or Damaged Copies 10662 Los Vaqueros Circle If you are missing an issue or you received a damaged copy, contact Los Alamitos, CA 90720 [email protected]. [email protected] Reprints of Articles Please provide an email address or daytime phone num- For price information or to order reprints, send email to ber with your letter. [email protected] or fax +1 714 821 4010.

On the Web Reprint Permission Access computer.org/software for information about To obtain permission to reprint an article, contact William Hagen, IEEE Software. IEEE Copyrights and Trademarks Manager, at [email protected].

May/June 2001 IEEE SOFTWARE 91