Presentation is loading. Please wait.

Presentation is loading. Please wait.

LOGO Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390.

Similar presentations

Presentation on theme: "LOGO Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390."— Presentation transcript:

1 LOGO Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390

2 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.”

3 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.

4 The Blob  characterized by a class diagram composed of a single complex controller class surrounded by simple data classes.

5 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

6 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

7 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?!”

8 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

9 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

10 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

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

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

13 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.

14 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

15 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!”

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

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

18 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.

19 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!”

20 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.”

21 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.

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

23 Solution  Change of Architecture:  Removing the Poltergeist class.  Its functionality must be fulfilled by other “real” classes.  See the example!

24 Example: Peach Canner System Process_TIMER PeachesWasherPeeler Peach_Canner_ Controller EvaluateRoleBase Chopper Canner Calendar

25 Example: Correct Peach Canner WasherPeeler Chopper Canner Calendar Peach_Canner_System SortRawPeaches() ScheduleJob() AssignTasks() AllocateResources() Inventory() Machine Raw_ Peaches Canned_ Peaches

26 References

Download ppt "LOGO Software Development Antipatterns Ameneh Gholipour Elham Akbari Spring 1390."

Similar presentations

Ads by Google