Anti-Patterns

1
Anti-Patterns
2
AntiPatterns

• Prevalent, recurring road-blocks to successful
  software development
• An anti-pattern identifies the problem, describes
  how to fix it, and how to avoid repeating it in
  the future
• Might apply to development, architecture, or
  project management

3
Design Patterns vs. AntiPatterns
Context Causes
Problem
Context Forces
AntiPattern Solution
Over Time New Context
Symptoms Consequences
Solution
Benefits Related Solutions Consequences
Refactored Solution
Benefits etc.
4
Root causes for AntiPatterns

• Haste (compromises software quality)
• Apathy (lack of partitioning)
• Narrow-mindedness
• Sloth (lack of configuration control)
• Avarice (excessive design complexity)
• Ignorance
• Pride (no reuse, reinventing)

5
AntiPattern Template

• Name
• Scale
• Anecdotal Evidence
• General form (diagram)
• Symptoms and Consequences
• Typical Causes
• Known exceptions
• Refactored Solutions
• Variations
• Example

6
The Blob

• This is the class that is really the heart of
  our architecture
• Also known as the God Class
• Large number of attribute and methods
• Lack of cohesiveness
• OK if used as a wrapper of a stable system
• Refactor by redistributing responsibilities

7
Lava Flow

• Also known as Dead Code
• Frequent unjustifiable variables and code
  fragments in the system
• Whole blocks of commented-out code with no
  explanation
• Cause Lack of configuration management
• Painful to cure (not easy to throw away code
  without careful consideration)

8
Functional Decomposition

• Classes with names such as Calculate_Interest or
  Display_Table
• All class attributes are private
• Classes with only one method
• No inheritance or polymorphism
• Caused by lack of OO understanding
• Refactor function classes into methods
• Combine several classes into a new class that
  satisfies a design objective

9
Poltergeists

• Classes with limited responsibilities
• They clutter software designs with unnecessary
  abstractions
• Complex and hard to understand
• Redundant navigation paths
• Temporary, short-duration objects and classes
• Solution Remove the Poltergeist class

10
Golden Hammer

• Maybe we shouldnt have used Excel macros for
  this after all
• Identical tools and products used in many diverse
  situations
• Inferior performance and scalability
• Financial reasons often the cause
• Solution requires change in development philosophy

11
Spaghetti code

• Very little software structure
• Impossible to reuse
• Tight coupling between many classes
• Cost of maintenance comparable to cost of
  complete rewrite
• Active refactoring and a proper object-oriented
  analysis process required

12
Cut-and-Paste Programming

• Man, you guys work fast. Over 400,000 lines of
  code in three weeks is outstanding progress
• Easier but wrong way to reuse
• The same bugs reoccur despite many local fixes
• Elimination of duplicate code important for the
  evolution of a software system