6/24/2009

Software Design Defects

Software Design Defects
Design Patterns are “good” solutions to
recurring design problems
◦ Where you want to be in terms of good design

Design Defects are “bad” solutions to
recurring problems
◦ Where you should not find yourself in software
development

Design Defects lessen the quality of OO
architectures and impede their evolution and
their maintenance

Patterns and Software Defects AntiPatterns

To Err Is Human

2 categories:
◦ High-level (global) problems: AntiPatterns
◦ Low-level (local) problems: Code Smells

“ deviations from specifications or expectations
which might lead to failures in operation ”

They describe in general what not to do

Arise due to lack of knowledge and experience

A good form of problem-solving approach

AntiPatterns provide patterns that have
negative consequences on software
development effort
◦ Reality of a good number of software projects

Help identifying problems in software
◦ Bad design results from common mistakes and
misunderstandings

Provide common vocabulary to discuss
problems and their solutions in software
industry

Understanding AntiPatterns provides the
knowledge to prevent or recover from them

Well--known AntiPatterns
Well
AntiPatterns

Root causes

AntiPatterns are all around us. They’re often ◦ Haste
used as tools for social control.  Good design is a product of careful study
 Trimming budgets, unrealistic committeements

SOCIAL AntiPatterns  Leads to compromises in software quality
◦ Apathy
◦ Criminal  Not caring about solving known problems
◦ Narrow-mindedness
◦ Drug Addict  Refusal to accept widely known solutions
◦ Laziness (Sloth)
◦ Witch  Configuration management
◦ Ignorance
◦ PickPocket  Failing to seek understanding
◦ Pride
 Not-invented-here syndrome: avoids using or buying already existing
products

1
 6/24/2009

AntiPatterns The Blob

Blob (Huge Class)

Describe context and causes

“ Procedural-style design

Describe symptoms to detect an leads to one object with a
lion’s share of the
AntiPattern in legacy software responsibilities while most
other objects only hold

Describe their consequences data or execute simple

Describe a roadmap for their solution processes ”

Large controller class

Many fields and methods
with a low cohesion

In this course, we shall only cover
Dependent on the data
AntiPatterns related to software code stored in associated data
classes

The Blob
The Blob Causes and Consequences
Library_Main_Control Item
Person
Current_Catalog Title

Typical Causes
Name Current_Item ISBN
User_ID User_ID Author ◦ Lack of proper Object-Oriented architecture
Items_Out Fine_Amount Publisher
Fines Etc.
Cost
Data_In
◦ Prototype software evolves into a product
…
Do_Inventory()
Check_Out_Item(Item)
Qty
…
◦ Lack of architectural enforcement
Check_In_Item(Item)
Add_Item(Item)
Consequences
Delete_Item(Item) Catalog
Print_Catalog()
Topic
◦ Modular continuity is compromised
Sort_Catalog()
Search_Catalog(Params)
Inventory
…
◦ Too complex for reuse and testing
Print()
Issue_Library_Card() ◦ Expensive to load into memory even for small
Calculate_Late_Fine()
operations

The Blob
The Blob - Solution
Solution
Library_Main_Control Item

Avoid it Person
Current_Catalog Title
Name Current_Item ISBN
◦ Managers should review program design User_ID User_ID Author
Items_Out Publisher
regularly Fines
Fine_Amount
Etc.
Cost
… Data_In

Refactor it Do_Inventory()
Check_Out_Item(Item)
Qty
…
Check_In_Item(Item)
◦ Move behavior away from the Blob Add_Item(Item)
Delete_Item(Item)
◦ Construct cohesive classes: cohesive set of Print_Catalog()
Catalog
Topic
attributes and methods are encapsulated Sort_Catalog()
Search_Catalog(Params)
Inventory
…
together Print()
Issue_Library_Card()
◦ Remove far-coupling Calculate_Late_Fine()

2
 6/24/2009

Spaghetti Code
Spaghetti Code Causes and Consequences

“ Ad hoc software structure makes it difficult
Typical Causes
to extend and optimize code.”

Code with very little software structure, ◦ Inexperience with Object-Oriented design
lack clarity technologies

Implementation invokes a process flow ◦ Ineffective code reviews

Lack of structure : no inheritance, no ◦ No initial software design
reuse, no polymorphism

Long methods process oriented with no
Consequences
parameters and low cohesion ◦ Code reuse is difficult

Procedural names of classes and methods ◦ Follow-on maintenance efforts contribute to the

Negligible degree of interaction between problem
objects

Use of global variables for processing ◦ Software reaches point of diminishing returns: the
effort involved to maintain existing code exceeds the
cost of developing a new “ground up” solution

public boolean startElement(int, XMLAttrList) if (prefix == -1) {

...
throws Exception {
if (!fValidating && !fNamespacesEnabled) {
return false;
if (elementURI != -1) {
fStringPool.setURIForQName(...);
•No Objects
•Process Flow
Spaghetti Code
}
}
if (contentSpecType == -1 && fValidating) {
}
else {
•Conditionals
•Complexity
Solution
... ...
} if (elementURI == -1) { •Cannot be
The best way is to prevent spaghetti code by first
if (... && elementIndex != -1) {
... }
... reused thinking and then developing. To avoid:
}
}
fStringPool.setURIForQName(.elementURI); ◦ Domain model even when it is well-understood
if (DEBUG_PRINT_ATTRIBUTES) {
... if (attrIndex != -1) { ◦ OO Analysis
} int index = attrList.getFirstAttr(attrIndex);
if (fNamespacesEnabled) {
while (index != -1) { ◦ OO Design
int attName = attrList.getAttrName(index);
fNamespacesScope.increaseDepth();
if (attrIndex != -1) {
if (!fStringPool.equalNames(...)) { ◦ Objects should be sufficiently refined
...
int index = attrList.getFirstAttr(attrIndex); if (attPrefix != fNamespacesPrefix) {
When adding new features, remove code defects
while (index != -1) { if (attPrefix == -1) {
... ...
Write accessor functions for member variables
if (fStringPool.equalNames(...)) { }
... else {
Refactor code into methods
} if (uri == -1) {
else {...} …
Remove obsolete code
} }
index = attrList.getNextAttr(index); fStringPool.setURIForQName(attName, uri);
Rename classes, functions, data types to conform
if (fElementDepth >= 0) {
}
}
fElementDepth++; to industry standards
if (fElementDepth == fElementTypeStack.length) {
int prefix =
...
fStringPool.getPrefixForQName(elementType); } }}}
int elementURI; return contentSpecType == fCHILDRENSymbol; }

Functional Decomposition
Functional Decomposition Causes and Consequences

One main routine that calls several other
Typical Causes
subroutines ◦ No use of OO concepts like inheritance or

Invoked subroutines are implemented as polymorphism
classes ◦ Lack of understanding of OO concepts

Classes with single action such as a ◦ Lack of architecture enforcement
function
Consequences

Attributes are private and used only ◦ Difficult to reuse
inside the class ◦ Expensive to maintain

The resulting code resembles a structural ◦ no way to clearly document (or explain) how
the system works
language like C and is incredibly complex

3

Functional Decomposition
Solution

Find the original Use Cases to ascertain
features from user view point

OO reengineering process

Find matching OO design model

Combine classes which assist each other

Combine classes which try to achieve the
same design objective

Find similar subsystems (reuse of code)
Functional Decomposition
Cut--and
Cut and--Paste Programming

“Man, you guys work fast. Over 400,000 lines of
code in just three weeks is outstanding progress.”

Cut-and-Paste Programming is a
very common degenerate form of
software reuse that causes
maintenance nightmares.

Less experienced programmers
learn by changing code of
experienced developers

Presence of several similar
segments of code

Creates code duplication

Positive short-term consequences
such as boosting line count metrics
6/24/2009
Functional Decomposition
A customer loan scenario

Adding a new customer

Updating a customers address

Calculating a loan to a customer

Calculating the interest on a loan

Calculating a payment schedule for a
customer loan

Altering a payment schedule
OO Version
Cut--and
Cut and--Paste Programming
Causes and Consequences

Typical Causes
◦ Reusable code is difficult to create and organizations prefer
short term benefits
◦ Easier to modify existing code than writing from scratch
◦ Lack of abstraction in developers
◦ Lack of knowledge of tools and technologies, hence working
examples are modified to create new components
◦ Lack of forward thinking

Consequences
◦ Software defects and bugs are replicated
◦ Difficult to locate all instances of a bug
◦ Code reviews and inspections are needlessly extended
◦ Excessive software maintenance costs
◦ Duplication of testing, review, bug fixing efforts
4
 6/24/2009

Cut--and
Cut and--Paste Programming
Swiss Army Knife
Solution

A Swiss Army knife is a

Three step approach brand of multi-function
◦ Identify Code duplication pocket knife or multi-tool.

Excessively complex class
◦ Refactoring duplicates into libraries or interface
components for black-box reuse
Designer attempts to
◦ Configuration management : code inspection, provide for all possible
uses of the class.
reviews and validation efforts in future to
Large number of interface
avoid Cut-and-Paste Programming signatures

No clear abstraction or
focus of the class interface

Swiss Army Knife Swiss Army Knife

Causes and Consequences Solution

Causes
Describe a profile for the class
◦ No focused responsibility
Profile documents the way to use a
◦ Class attempting to provide too much complex technology
functionality

Consequences
Profile for an interface describe the
◦ More != Better signatures and parameter values
◦ Confusion
◦ Maintenance problems
◦ Each interface requires implementation of
items on that interface

Conclusions Code Smells

“If it stinks, change it”

AntiPatterns provide patterns that have negative
consequences on software development effort

Each AntiPattern includes a solution + solution pair

Hint that something has gone wrong
◦ AntiPattern Solution Generates mostly negative
consequences
Opportunities for improving program
◦ Refactored Solution Generates mostly positive design
benefits

AntiPatterns are useful for refactoring, migration,
Code smells indicate the need for the
upgrade, and reengineering application of a possible refactoring

5
 6/24/2009

Code Smells - Examples Code Smells – More Examples

Duplicate Code
◦ Duplication of bugs, tests, reviews
◦ Same (or nearly) code in multiple places
◦ Frequently the result of cut-and-paste coding

Long Method
◦ OO puts premium on short methods
◦ Long procedures always harder to understand

Large Class
◦ Class has poor cohesion
◦ Too many instance variables or methods means a class is
doing too much
◦ Class interface does not provide consistent level of
abstraction

Long Parameter List
◦ Programs harder to understand
◦ Difficult to reuse and change
◦ Parameter lists should be shorter in OO
programs than in traditional programs

Divergent Change
◦ One class commonly changed in different
ways for different reasons
◦ Some methods changed in one case
◦ Other methods changed in another

Code Smells – More Examples

Feature Envy
◦ Method seems more interested in a class other
than the one it is in
◦ Most common focus is data (lots of getter calls)

Data Clumps
◦ Same data items in multiple classes
◦ Parameter lists of several methods
◦ If after deleting one from clump the rest wouldn’t
make sense, a clear candidate for refactoring