Protected Variation: the Importance of Being Closed Craig Larman
Total Page：16
File Type：pdf, Size：1020Kb
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 0740-7459/01/$10.00 © 2001 IEEE May/June 2001 IEEE SOFTWARE 89 DESIGN 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.