copyright w. howden1 software development antipatterns and refactoring
Post on 31-Dec-2015
213 Views
Preview:
TRANSCRIPT
Copyright W. Howden 1
Software Development AntiPatterns and Refactoring
Copyright W. Howden 2
Definitions
• Pattern: good ideas
• AntiPatterns: bad ideas
• Refactoring: better ideas
Copyright W. Howden 3
Kinds of AntiPatterns
• AntiPatterns, W.H. Brown et al, Wiley, 1998 Software Development– Software Architecture– Software Project Management
Copyright W. Howden 4
Software Development Anti-Patterns
1. Control Freak
2. Old Baggage
3. Functional Decomposition
4. Gadget Clutter
Copyright W. Howden 5
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 6
Control Freak/The Blob
• Solution:– Refactoring of Responsibilities
Copyright W. Howden 7
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 8
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?!”
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. 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 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. Howden 14
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. 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
Copyright W. Howden 20
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”
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
top related