Software Development - PowerPoint Presentation

Slide1

Software Development Antipatterns

Ameneh

Gholipour

Elham

Akbari

Spring 1390Slide2

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

The Blob

Two

major forms of the Blob

AntiPattern

:

Behavioral Form: an objectthat contains a centralizedprocess that interacts withmost other parts of the system.Data Form: an object thatcontains shared data usedby most other objects inthe system.Slide4

The Blob

characterized by a

class

diagram

composed

of a single complex controller class surrounded by simple data classes.Slide5

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 objectsA migrated legacy design that has not been properly refactored into an object−oriented architectureSlide6

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 architectureSlide7

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

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 demonstrationsacrificing documentationSlide9

Lava Flow

Symptoms:

Frequent

unjustifiable

variables and code fragmentsUndocumented complex, important−looking functions, classes, or segmentsWhole blocks of commented codeUnused, inexplicable, or obsolete interfaces located in header filesIf the process that leads to Lava Flow is not checked, there can be exponential growth as succeeding developersSlide10

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 developmentSlide11

Golden Hammer

A familiar technology or concept applied obsessively to many software problems.

One of the most common

AntiPatterns

in the industry.

"When your onlytool is a hammer,everything elseis a nail."Slide12

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

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

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 developmentsForm book study clubs to track new publicationsIndustry conferencesManagement:Hire people from different areas and from different backgroundsSlide15

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

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

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

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

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

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

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

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

Solution

Change of Architecture:

Removing the Poltergeist class.

Its functionality must be fulfilled by other “real” classes.

See the example!Slide24

Example: Peach Canner System

Process_TIMER

Peaches

Washer

Peeler

Peach_Canner_Controller

EvaluateRoleBase

Chopper

Canner

CalendarSlide25

Example: Correct Peach Canner

Washer

Peeler

Chopper

Canner

Calendar

Peach_Canner_System

SortRawPeaches

()

ScheduleJob

()

AssignTasks

()

AllocateResources

()

Inventory()

Machine

Raw_

Peaches

Canned_

PeachesSlide26

References