WIXLIB

THE EVOLUTION OF A COPY PROGRAMBY PANKAJ KAMTHAN1. INTRODUCTIONThis document tells a ‘story’ of the evolution of a program caused by the unforeseenchanges in the requirements [Martin, 2002; Martin, Martin, 2006].Let I be the set of input devices, O be the set of output devices, and let P be the program.Then the story is about the impact on the design of P due to variations in I and O ,where · denotes the cardinality.The moral of the story is that, unless there is adequate preparation for change inadvance, the quality of the design of a program can rapidly deteriorate to the point thatthe loss can become irreversible.2. CONVENTIONThere are certain statements in the rest of the document that are associated with specificgraphical notations.The presence of the ‘dangerous bend’ symbol1 illustrated below should be interpreted asa warning.The warnings reflect a violation of the underlying philosophy of object-oriented design(OOD) aiming for ‘high-quality’, in general, and, by reference, a violation of one or moreobject-oriented design principles (OODP), in particular.1The symbol is an electronic rendering of that shown in [Knuth, 1984].1

The presence of the smiley icon [Sanderson, 1997] illustrated below should be interpretedas a (negative) impact on (solution) quality.3. “SOLID” OBJECT-ORIENTED DESIGN AND PROGRAMMINGThe more science becomes divided into specialized disciplines, the more important it becomes tofind unifying principles.― Hermann HakenSOLID is a mnemonic acronym for five basic principles of object-oriented design andprogramming [Martin, Martin, 2006], summarized in Table 1.AcronymSRPOCPLSPISPDIPOOD PrincipleThe SingleResponsibilityPrincipleStatementA class should have only one reason to change.The Open-ClosedPrincipleA class should be open for extension, but closed formodification.The LiskovSubstitutionPrincipleThe sub-types must be substitutable for their supertypes.The InterfaceSegregationPrincipleA client should not be forced to depend uponoperations that it does not use. Also, an interfacebelongs to a client, not to the hierarchy.The DependencyInversion PrincipleThe abstractions should not depend upon details.The details should depend upon abstractions.Table 1. A collection of object-oriented design principles for classes.3.1. SOLID SCOPEThe default target for SOLID is a new design.2

However, if (1) a design ‘smell’ is discovered, and (2) it is possible to ‘refactor’, thenSOLID, particularly those for classes, can also be used to improve the quality of an old(legacy) design, specifically the readability and maintainability of the source code.3

4. EPISODE I: LE DÉBUTIn its first incarnation, a copy program2 is supposed to accept characters as input from thekeyboard, and provide a copy of them to a printer as output.There are three procedures3 in the copy program. The Copy procedure calls the othertwo, namely the ReadKeyboard that reads characters from the keyboard, and theWritePrinter that writes those characters to a printer.The structure chart and the listing of the copy program are shown in Figure 1 and Listing1, respectively.Figure 1. The design of the first version of the copier program.// Copy Program: Incarnation Ipublic class Copier {public static void Copy() {int c;while((c Keyboard.Read()) ! -1) {Printer.Write(c);}}}Listing 1. The C# source code of the first version of the copy program.2The program is in C#, and could be implemented in one of the other members of the C ‘family’ oflanguages. However, the underlying programming language is not relevant to the discussion.3For the sake of this document, terms such as function, method, module, procedure, routine, sub-program,and other similar constructs, are considered synonymous and therefore interchangeable.4

5. EPISODE II: UN MOIS PLUS TARDThere is passage of time. There is a change in the input device requirements due tointernal demands (coming from inside the organization, such as from otherprogrammers).The copy program should also be able to read characters that are input from the Braillereader. (This is, for example, to support users with visual disabilities, includingblindness.)The program in Listing 1 is not designed for a Braille reader.To accommodate the change in the input device, a Boolean argument is added to theCopy procedure. If True, it reads from the Braille reader; if False, it reads from thekeyboard as before.A change in the interface is not feasible at this stage as, with the passage of time,several other programs use the copy program.To let the copy program know that it must read from the Braille reader, a globalvariable4 along with the ?: (ternary) operator5 are used.The result of accommodating the aforementioned changes is given in Listing 2.4The use of global variables in programs is usually considered ‘poor’ practice because of their nonlocality. For example, a global variable can potentially be modified from anywhere, and any part of theprogram may depend on it. Therefore, a global variable has an unlimited potential for creating mutualdependencies and, in general, addition of mutual dependencies increases structural complexity. The useof global variables also affects adversely the readability and understandability of a program. There areprogramming languages, such as Java, that do not have global variables. (In Java, all variables that are notlocal variables are fields of a class. Hence, all variables are in the scope of either a class or a method.)5The origin of the ?: ternary operator lies in the programming language CPL, introduced in the early1960s [Strachey, 2000]. In C#, if the condition is true, first expression is evaluated and becomes the result;if the condition is false, the second expression is evaluated and becomes the result. In this sense, the ?:ternary operator is similar, but not identical, to the if-then-else clause. It has been pointed out in[Boswell, Foucher, 2012, Pages 73-74] that the ternary operator should be avoided in all but the simplestcases.5

// Copy Program: Incarnation IIpublic class Copier {// Reset Flagpublic static bool BFlag false;public static void Copy() {int c;while((c (BFlag ? Braille.Read() : Keyboard.Read())) ! -1) {Printer.Write(c);}}}Listing 2. The C# source code of the second version of the copy program.6

6. EPISODE III: DEUX MOIS PLUS TARDThere is further passage of time. There is a change in the requirements due to externaldemands (coming from outside the organization, such as from customers).The copy program should also be able to output to the screen.The callers of Copy that want to read from the Braille reader must first set the BFlag toTrue and then call Copy. Upon return of Copy, the caller must reset the BFlag; or elsethe next caller may mistakenly read from the Braille reader rather than from thekeyboard. This is made explicit in a comment.The result given in Listing 3 is a change in design that is similar to Episode II. It requiresyet another global variable and another ?: operator.// Copy Program: Incarnation IIIpublic class Copier {// Reset Flagspublic static bool BFlag false;public static bool SFlag false;public static void Copy() {int c;while((c (BFlag ? Braille.Read() : Keyboard.Read())) ! -1) {SFlag ? Screen.Write(c) : Printer.Write(c);}}}Listing 3. The C# source code of the third version of the copy program.There are a few notable issues in the foregoing change. There is an increase in pressurethat manifests in degradation of quality at both process and product levels.6.1. PROCESSThe design of the copy program given in Figure 1 is not based on software engineeringprinciple of anticipation of change [Ghezzi, Jazayeri, Mandrioli, 2003]. The changesare incorporated in the evolution of design (manifested in Listings 1-3) after requestsfor changing the requirements are received.7

The accommodation of changes is becoming increasingly difficult. This, in turn, islikely to adversely affect productivity. (There is reaction—not anticipation—tochange.)6.2. PRODUCTThe evolution of design is based on ‘patchwork’. The structure of the copy program isbeginning to deteriorate6. In other words, patchwork is adversely affecting thereadability and maintainability of the source code.6For example, further changes to the input device is likely to involve a completely restructuring of thewhile loop conditional.8

7. EPISODE IV: LA LEÇONThe top-down design of the copy program given in Figure 1 has issues.It is inflexible because of the direction of its dependencies. The high-level Copyprocedure depends directly on the low-level details of the ReadKeyboard and theWritePrinter procedures. Thus, a change in the low-level details affects the highlevel policy.Board Time!Give the meaning of the Domino Effect7.Therefore, a completely new approach to the original design is required, such that thechange is transparent to a user. The new design has the following characteristics: By following the Open-Closed Principle (OCP), an abstract class is included forabsorbing the input. The possibility of a new input device can now be accommodatedwithout modifying the copy program. By following the Dependency Inversion Principle (DIP), the dependency from theCopy procedure to the input device is inverted. The STRATEGY pattern [Gamma,Helm, Johnson, Vlissides, 1995; Shalloway, Trott, 2005, Chapter 9; Martin, 2014,Chapter 7; Shvets, 2015; Shvets, 2019] is used to create the desired inversion.(The STRATEGY pattern is also known as the POLICY pattern, and is aligned withthe OCP and the DIP.)The result of recasting Listing 1 (by refactoring to a pattern) is shown in Listing 4.7A domino effect “is the cumulative effect produced when one event sets off a chain of similar events”[Wikipedia].9

// Copy Program: Incarnation IV// Open for Extension, Closed for Modificationpublic interface Reader {int Read();}// Program to an Interface, Not an Implementationpublic class KeyboardReader : Reader {public int Read() {return Keyboard.Read();}}public class Copier {public static Reader reader new KeyboardReader();public static void Copy() {int c;while ((c (reader.Read())) ! -1) {Printer.Write(c);}}}Listing 4. The C# source code of the first version of the copy program based on SOLID.7.1. OBSERVATIONSObservation [Detect, Diagnose, Solve]. The new design is based on interplay betweenthree aspects: (1) detecting the problem by following certain agile practices, (2)diagnosing the problem by applying design principles, and (3) solving the problem byapplying an appropriate design pattern8.There are known knowns. These are things we know that we know. There are known unknowns.That is to say, there are things that we know we don’t know. But there are also unknownunknowns. There are things we don’t know we don’t know.— Donald RumsfeldObservation [Design for Change: Revisited]. The causes (or origins) of a change indesign are not always in the control of a designer and may not always be known to adesigner. It is better to focus on making a design ‘change-proof’ rather than focus onthe causes of a change in design.8In the STRATEGY pattern, the behaviors of a class are not inherited, but encapsulated using interfaces.The behaviors are defined as separate interfaces, and specific classes that implement and encapsulatethese interfaces. This allows better decoupling between the behavior and the class that uses the behavior.The behavior can be changed without ‘breaking’ the classes that use it. (Source: Wikipedia.)10