1. Copyright W. Howden1 Software Development AntiPatterns and Refactoring

2. Copyright W. Howden2 Definitions Pattern: good ideas AntiPatterns: bad ideas Refactoring: better ideas

3. Copyright W. Howden3 Kinds of AntiPatterns AntiPatterns, W.H. Brown et al, Wiley, 1998 –  Software Development –Software Architecture –Software Project Management

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

5. Copyright W. Howden5 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.”

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

7. Copyright W. Howden7 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

8. Copyright W. Howden8 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?!”

9. 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 AntiPatterns, 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. Howden9

10. 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. Howden10

11. 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. Howden11

12. 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. Howden12

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

14. Symptoms And Consequences This AntiPattern is the result of experienced, non- object−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. Howden14

15. Symptoms And Consequences Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern. 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. Howden15

16. 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. Howden16

17. 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. Howden17

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

19. After Refactoring Copyright W. Howden19

20. Copyright W. Howden20 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”

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

22. 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. Howden22

23. Refactored Solution Copyright W. Howden23