Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring
Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390 LOGO
The Blob v Also Known As: Winnebago [Akroyd 96] and The God Class [Riel 96] v Procedural−style design leads to one object with most of the responsibilities, while most other objects only hold data or simple operations. v Anecdotal Evidence: “This is the class that is really the heart of our architecture. ”
The Blob v Two major forms of the Blob Anti. Pattern: § Behavioral Form: an object that contains a centralized process that interacts with most other parts of the system. § Data Form: an object that contains shared data used by most other objects in the system.
The Blob v characterized by a class diagram composed of a single complex controller class surrounded by simple data classes.
The Blob v Symptoms: § A class with 60 or more attributes and operations usually indicates the presence of the Blob. § An overall lack of cohesiveness of the attributes and operations is typical of the Blob. § An absence of object−oriented design. A program main loop inside the Blob class associated with relatively passive data objects § A migrated legacy design that has not been properly refactored into an object−oriented architecture
The Blob v Solution: § Decompose the class and redistribute the responsibilities. § move behavior away from the Blob. § reallocate behavior to some of the encapsulated data objects. § Results in buttom-up refactoring of the class architecture
Lava Flow v Also Known As: Dead Code v 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. After all, it works doesn’t it? !”
Lava Flow v Lavalike “flows” of previous developmental versions scattered in the code. v Immovable, generally useless mass of code that no one can remember much v Result of trying out several ways of accomplishing things v typically in a rush to deliver some kind of demonstration § sacrificing documentation
Lava Flow v Symptoms: § Frequent unjustifiable variables and code fragments § Undocumented complex, important−looking functions, classes, or segments § Whole blocks of commented code § Unused, inexplicable, or obsolete interfaces located in header files § If the process that leads to Lava Flow is not checked, there can be exponential growth as succeeding developers
Lava Flow v Solution: § include a configuration management process that eliminates dead code and evolves or refactors design toward increasing quality. v To avoid: § ensure that sound architecture precedes code development
Golden Hammer v A familiar technology or concept applied obsessively to many software problems. v One of the most common Anti. Patterns in the industry. v "When your only tool is a hammer, everything else is a nail. "
Golden Hammer v Causes: § Several successes have used a particular approach. § Large investment has been made in training and/or gaining experience in a product or technology. § Developers and managers are comfortable with an existing approach and unwilling to learn and apply one that is better suited.
Golden Hammer v Symptoms: § Identical tools and products are used for wide array of conceptually diverse products. § Solutions have inferior performance, scalability, and so on when compared to other solutions in the industry. § Developers become isolated from the industry. They demonstrate a lack of knowledge and experience with alternative approaches. § Existing products dictate design and system architecture.
Golden Hammer v Solution: § An organization needs to develop a commitment to an exploration of new technologies § Developers: • To be up to date on technology trends – Establish groups to discuss technical developments – Form book study clubs to track new publications – Industry conferences § Management: • Hire people from different areas and from different backgrounds
Cut−And−Paste Programming v Several similar segments of code interspersed throughout the software project. v Many programmers learning to develop software by modifying code that has been proven to work in similar situations. v Evidence: § “Hey, I thought you fixed that bug already, so why is it doing this again? ” § “Man, you guys work fast. Over 400, 000 lines of code in three weeks is outstanding progress!”
Causes v It’s easy to extend the code. § the developer has full control over the code in his/her application. v It takes a great deal of effort to create reusable code. v The organization does not advocate reusable components. § development speed is the only thing that matters. v People are unfamiliar with new technology or tools.
Consequences v Software defects are replicated through the system. v Developers create multiple unique fixes for bugs. § No method of resolving the variations into a standard fix. v Leads to excessive software maintenance costs.
Refactored Solution v Black−box reuse: § Object is used as−is, through its specified interface. • Implementation of an object can be made independent of the object’s interface. • The supported services are limited to those supported by the same interface. v To reduce or eliminate cloning: § Modifying code to emphasize black−box reuse of duplicated software segments. § Difficult, long, and costly. § Requires management support.
Poltergeists v Poltergeists represent “restless ghosts” that cause “bump−in−the−night ” types of phenomena. v Evidence: “I’m not exactly sure what this class does, but it sure is important!”
Causes v Designers familiar with process modeling but new to object−oriented design define architectures. § Problem in architecture. v Incorrect tool for the job. § The object−oriented approach isn’t necessarily the right solution for every job. § “There is no right way to do the wrong thing. ”
Symptoms v Redundant navigation paths. v Stateless classes. v Temporary, short−duration objects and classes. v Single−operation classes that exist only to “seed” or “invoke” other classes through temporary associations.
Consequences v They are unnecessary, so they waste resources every time they “appear. ” v They are inefficient because they utilize several redundant navigation paths. v They get in the way of proper object−oriented design by needlessly cluttering the object model.
Solution v Change of Architecture: § Removing the Poltergeist class. § Its functionality must be fulfilled by other “real” classes. § See the example!
Example: Peach Canner System Process_TIMER Peaches Washer Peeler Peach_Canner_C ontroller Evaluate. Role. Base Calendar Chopper Canner
Example: Correct Peach Canner Peach_Canner_System Sort. Raw. Peaches() Schedule. Job() Assign. Tasks() Allocate. Resources() Inventory() Raw_ Peaches Calendar Machine Washer Peeler Chopper Canned_ Peaches
References
- Slides: 26