Presentation on theme: "LOGO Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390."— Presentation transcript:
LOGO Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390
The Blob Also Known As: Winnebago [Akroyd 96] and The God Class [Riel 96] Procedural−style design leads to one object with most of the responsibilities, while most other objects only hold data or simple operations. Anecdotal Evidence: “This is the class that is really the heart of our architecture.”
The Blob Two major forms of the Blob AntiPattern: 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 characterized by a class diagram composed of a single complex controller class surrounded by simple data classes.
The Blob 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 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 Also Known As: Dead Code 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 Lavalike “flows” of previous developmental versions scattered in the code. Immovable, generally useless mass of code that no one can remember much Result of trying out several ways of accomplishing things typically in a rush to deliver some kind of demonstration sacrificing documentation
Lava Flow 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 Solution: include a configuration management process that eliminates dead code and evolves or refactors design toward increasing quality. To avoid: ensure that sound architecture precedes code development
Golden Hammer A familiar technology or concept applied obsessively to many software problems. One of the most common AntiPatterns in the industry. "When your only tool is a hammer, everything else is a nail."
Golden Hammer 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 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 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 Several similar segments of code interspersed throughout the software project. Many programmers learning to develop software by modifying code that has been proven to work in similar situations. 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 It’s easy to extend the code. the developer has full control over the code in his/her application. It takes a great deal of effort to create reusable code. The organization does not advocate reusable components. development speed is the only thing that matters. People are unfamiliar with new technology or tools.
Consequences Software defects are replicated through the system. Developers create multiple unique fixes for bugs. No method of resolving the variations into a standard fix. Leads to excessive software maintenance costs.
Refactored Solution 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. To reduce or eliminate cloning: Modifying code to emphasize black−box reuse of duplicated software segments. Difficult, long, and costly. Requires management support.
Poltergeists Poltergeists represent “restless ghosts” that cause “bump−in−the−night ” types of phenomena. Evidence: “I’m not exactly sure what this class does, but it sure is important!”
Causes Designers familiar with process modeling but new to object−oriented design define architectures. Problem in architecture. 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 Redundant navigation paths. Stateless classes. Temporary, short−duration objects and classes. Single−operation classes that exist only to “seed” or “invoke” other classes through temporary associations.
Consequences They are unnecessary, so they waste resources every time they “appear.” They are inefficient because they utilize several redundant navigation paths. They get in the way of proper object−oriented design by needlessly cluttering the object model.
Solution Change of Architecture: Removing the Poltergeist class. Its functionality must be fulfilled by other “real” classes. See the example!