SWEN 262 Engineering of Software Subsystems Anti-Patterns
References An anti pattern is a common ● response to a recurring problem that is usually ineffective and risks being highly counterproductive. Anti Patterns: Refactoring ● Software, Architectures, and Projects in Crisis Brown, Malveau, McCormick III, & ○ Mowbray John Wiley & Sons, 1998 ○ Software Anti-Patterns Cheat ● Sheet
Anti Patterns A pattern of practice that is ● commonly found in use. When practiced, anti patterns often result ○ in negative consequences. A software engineer must develop and ● implement strategies to repair and remove anti patterns when they are It is worth remembering that encountered. refactoring takes time (and Solve through safely refactoring the code. ○ money) and risks breaking Work incrementally. ○ code that works. There are many alternatives to consider. ○ Beware of the cure being worse than the ○ Keep this in mind when disease. considering removing an antipattern.
W W A A N N T T E E D D The Blob Anecdotal Evidence: ● Classes with names like “System,” ○ “Manager,” or “Controller.” Lots of little data classes. ○ UML class diagram that is larger than ○ all of the other classes. Possible Causes: THE BLOB ● “Just put it in main.” ○ A.K.A. The Winnebago, God Class, The Information Expert taken to the ○ Kitchen Sink extreme. Like the blob in the movie, starts out small No Pure Fabrication. ○ and grows over time. “This class is the heart Problems: ● of our system.” Too complex to test. ○ If found : Categorize related attributes and No hope for reuse. ○ operations, extract class . Apply Low cohesion. ○ information expert to data classes. High coupling. ○
ANTED W Copy-and-Paste Programming Anecdotal Evidence: ● “I thought you already fixed this ○ bug?” Possible Causes: ● People unfamiliar with tools or ○ E T technology copy and modify a working S A P - D N A - Y P O example. C G N I M Laziness/time pressure. M ○ A R G O R P Low coupling and/or Law of Demeter ○ “Man, you guys work fast! Over 400,000 taken to the extreme. lines of code written in three weeks!” Problems: ● Code duplication (DRY!). ○ If found: Apply information expert and pure fabrication to create a single, standard Same bugs occur multiple times. ○ Information expert broken. implementation. Replace duplication with ○ Low cohesion. ○ Higher maintenance costs. ○ method calls.
WANTED Lava Flow Anecdotal Evidence: ● IDE flags unused code. ○ No one is sure what a method or class ○ does, but is afraid to remove it. Large blocks of commented code. ○ Possible Causes: ● LAV Lack of confidence in refactored A FLOW ○ implementations (old code kept “just A . K . A . D e a d C o d e in case”). Change in development team members. ○ Code, like lava, is fluid when it starts life but Research code moved into production. ○ becomes hard and immovable later. Time. ○ Problems: ● If found : Write characterization tests, then slowly remove dead code. Rerun tests to Classes with no relationships. ○ make sure that nothing is broken. Moving Code glut/increased lines of code. ○ forward, safely refactor code (tests). Unused methods with duplicate ○ behavior.
ANTED W Poltergeists Anecdotal Evidence: ● Transient associations. ○ Short-lived, stateless classes. ○ Classes created to invoke methods in ○ other classes, then go out of scope. Possible Causes: ● THE POLTERGEIST Using OO when it is not appropriate. ○ Poorly implemented Command Pattern. ○ Poorly implemented MVC. ○ “I’m not exactly sure what this class does, Problems: ● but it sure seems important.” Transient Higher coupling. ○ associations that go “bump in the night.” Lots of little, extra classes. ○ If found : Remove poltergeists by moving controlling actions to related classes.
WANTED The Golden Hammer Anecdotal Evidence: ● “Our database drives our ○ architecture.” “The entire program is implemented ○ with Excel macros!” Identical tools used for conceptually ○ THE GOLDEN HAMMER different problems. Possible Causes: ● r e e l l Y d O l A . . . K A “The customer asked us to use .net, ○ When the only tool you have is a hammer, but I already know Python, so...” everything starts to look like a nail. Lack of training, outdated skills. ○ No diversity of background. ○ If found : Diversify team skills. Commit to Problems: ● professional development. Explore new technologies. Use open systems and Tools determine the architecture. ○ Non-functional requirements ignored. ○ architectures. Customer/Product Owner ignored. ○ Poor performance & scalability. ○
WANTED Functional Decomposition Anecdotal Evidence: ● Classes have names that sound like ○ methods, e.g. CalculateInterest, FUNCTIONAL DECOMPOSITION DisplayTable. Classes with a single method. ○ A.K.A. No OO Possible Causes: ● “ O b j e c t High cohesion taken to the extreme. o r ○ i e n t e d p r o g r a m m i n g i j u s e s t a p s y u t ! Y e o Lack of object oriented experience. v e u ○ r y t h i n g i n a c l a s s ! ” Problems: ● I f f o u n d : P e r f o r m d o m a i n a n a l y No hope of reuse. d s i ○ o s , m u s a i n e d r i v e n d e s i g n . A p p l y i n Class explosion. f o ○ e x r p m e r a t t . i o C n o m b i n e c l a s s e s w i t h r e High coupling. s l a ○ t a t e t e / d b e h a v i o r . U s e s t a t i c f u n c t i o n a p s p r w o p h e r n i a t e .
Recommend
More recommend
