Software Development Anti Patterns and Refactoring Copyright W

Software Development Anti. Patterns and Refactoring Copyright W. Howden 1

Definitions • Pattern: good ideas • Anti. Patterns: bad ideas • Refactoring: better ideas Copyright W. Howden 2

Kinds of Anti. Patterns • Anti. Patterns, W. H. Brown et al, Wiley, 1998 – Software Development – Software Architecture – Software Project Management Copyright W. Howden 3

Software Development Anti-Patterns 1. 2. 3. 4. Control Freak Old Baggage Functional Decomposition Gadget Clutter Copyright W. Howden 4

1. Control Freak/The Blob • Description – large object with all the control, which accesses simple data classes • Other names: Blob, Winnebago, God Class • Consequences – difficult to modify functionality – not based on domain model – difficult to test and reuse • Anecdotal Evidence “This is the class that is really the heart of our architecture. ” Copyright W. Howden 5

Control Freak/The Blob • Solution: – Refactoring of Responsibilities Copyright W. Howden 6

2. Old Baggage • Description – system contains many classes whose purpose is not known • Other names: Lava Flow, Dead Code – More common in research based projects: • much of the code is left over from previous ideas and no longer has a purpose • was once fluid and useful, now is solid lava that you are afraid to remove • Consequences – difficult to maintain, just gets worse Copyright W. Howden 7

Old Baggage • Anecdotal Evidence: “Oh that! Well Ray and Emil (they’re no longer with the company) wrote that routine back when Jim (who left last month) was trying a workaround for Irene’s input processing code (she’s in another department now, too). I don’t think it’s used anywhere now, but I’m not really sure. Irene didn’t really document it very clearly, so we figured we would just leave well enough alone for now. After all, the bloomin’ thing works doesn’t it? !” Copyright W. Howden 8

Symptoms And Consequences • Lava Flows are expensive to analyze, verify, and test. • Lava Flow code can be expensive to load into memory, wasting important resources and impacting performance. • As with many Anti. Patterns, you lose many of the inherent advantages of an object−oriented design. In this case, you lose the ability to leverage modularization and reuse without further proliferating the Lava Flow globules. Copyright W. Howden 9

Symptoms And Consequences • Frequent unjustifiable variables and code fragments in the system. • Undocumented complex, important−looking functions, classes, or segments that don’t clearly relate to the system architecture. • Whole blocks of commented−out code with no explanation or documentation. Copyright W. Howden 10

Symptoms And Consequences • If existing Lava Flow code is not removed, it can continue to proliferate as code is reused in other areas. • If the process that leads to Lava Flow is not checked, there can be exponential growth as succeeding developers, too rushed or intimidated to analyze the original flows, continue to produce new, secondary flows as they try to work around the original ones, this compounds the problem. Copyright W. Howden 11

Refactored Solution • Ensure that sound architecture precedes production code development. • This architecture must be backed up by a configuration management process that ensures architectural compliance and accommodates “mission creep” (changing requirements). Copyright W. Howden 12

3. Functional Decomposition • Anecdotal Evidence: “This is our ‘main’ routine, here in the class called LISTENER. ” Copyright W. Howden 13

Symptoms And Consequences • This Anti. Pattern is the result of experienced, nonobject−oriented developers who design and implement an application in an object−oriented language. • When developers are comfortable with a “main” function that calls numerous functions, they may tend to make every function a class, ignoring class hierarchy altogether (and pretty much ignoring object orientation entirely). • The resulting code resembles a structural language such as Pascal or FORTRAN in class structure. Copyright W. Howden 14

Symptoms And Consequences • Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this Anti. Pattern. • All class attributes are private and used only inside the class. • Classes with a single action such as a function. • An incredibly degenerate architecture that completely misses the point of object−oriented architecture (such as inheritance and polymorphism). Copyright W. Howden 15

Refactored Solution • If it is still possible to ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. • Next, formulate a design model that incorporates the essential pieces of the existing system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible. Copyright W. Howden 16

Refactored Solution • For classes that fall outside of the design model, use the following guidelines: – If the class has a single method, try to better model it as part of an existing class. – Attempt to combine several classes into a new class that captures a broader domain concept than the previous finer−grained classes. – For example, rather than have classes to manage device access, to filter information to and from the devices, and to control the device, combine them into a single device controller object with methods that perform the activities previously spread out among several classes. Copyright W. Howden 17

Example: System with Functional Decomposition Anti-Pattern Copyright W. Howden 18

After Refactoring Copyright W. Howden 19

4. Gadget Clutter • Description – Transient classes whose objects are created to perform some temporary responsibility • Other names: Proliferation of classes, poltergeists, popups – unnecessary abstractions that clutter the design • Consequences – clutter up the design – non-object oriented classes with names like “start up counter”, “initialize data base” Copyright W. Howden 20

Anecdotal Evidence “I’m not exactly sure what this class does, but it sure is important!” Copyright W. Howden 21

Example PEACH_CANNER_CONTROLLER is a Poltergeist because • • It has redundant navigation paths to all other classes in the system. All of its associations are transient. It has no state. It is a temporary, short-duration class that pops into existence only to invoke other classes through temporary associations. Copyright W. Howden 22

Refactored Solution Copyright W. Howden 23