3-Software Anti Design Patterns (Object Oriented Software Engineering - BNU Spring 2017)

Software Design
Anti Patterns
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Anti Pattern
■ A pattern that tells how to go from a problem to a bad solution
■ Defines what seems like an appropriate and effective solution to a problem but has
more bad consequences than good ones
– How not to solve a problem
– Negative solution to a problem
– Bad practice and common mistakes in a solution
■ Provides an identifiabletemplate for the problem and discuss its solutions
– Common vocabulary for identifying a problem and its solution
– Measures that can be taken to improve the solution
– Lessons learned from failures and their remedies

Blob

Blob
■ One class does most of the processing, and other classes only encapsulate data
■ Procedural design, where one class contains the majority of the process and other
classes contain the data
■ Majority of the responsibilities are allocated to a single class known as blob class
■ Symptoms:
– Single class in a system that knows too much or does too much
– One class with a large number of attributes, behaviors, or both
– One big class doing all the tasks while other classes only hold data
■ Consequences:
– Modification becomes difficult and expensive, modifying blob class affect others
– Blob class is complex to reuse or test
– Blob class may use excessive resources for simple operations

Blob
■ Solutions:
– Increase cohesion in all the classes specially in blob class
– Migrate behaviors from blob class to their related data classes
– Identify related attributes and behaviors in blob class and move them to a new class

Functional Decomposition

■ A real world action is turned into a class instead of a real world object
■ An approach that turns a subroutine into a class
■ No object oriented principles such as inheritance and polymorphism
■ Symptoms:
– Class with a functional name (named on a function instead of an object)
– Class with only a single behavior
■ Consequences:
– Hard to reuse and modify
– Documentation becomes difficult
– Lack of object oriented design

■ Solutions:
– Merge the class which contains a single behavior to an existing class in the system
where its related data resides
– If a class does not contain any state information, convert that class into a behavior
and insert that behavior into an appropriate existing class in the system
– Create new classes that satisfies the object oriented design and merge existing
incompatible classes into them

Poltergeist

Poltergeist
■ Class with limited and redundant responsibilities and short life cycle
■ Stateless class that creates unnecessary abstraction and complexity
■ Temporary class that adds an extra redundant step in navigation path
■ Symptoms:
– Class with single operations that only invoke other classes
– Class with short duration objects that only begin operations and do nothing else
■ Consequences:
– System becomes redundant and complex
– Wastage of resources
– Clutters the object oriented design

Poltergeist
■ Solutions:
– Remove the stateless redundant class from the hierarchy and move its functionality
to the related classes
– Simplify the system by removing all the classes with transient associations and
make direct associations among related classes

Cut & Paste Programming

■ Use existing code which is proven to work in similar situations with modification
■ Duplicate and extend already written code
■ Similar segments of code present throughout the project
■ Symptoms:
– Instead of writing code from scratch, use pre-written or partial code already
availableand extend it further
– Use an existing solution as a basis to define a new solution
■ Consequences:
– Code can be reused with minimum effort
– Same bugs reoccur throughout the software
– Difficult to review and maintain the code

■ Solutions:
– Code Mining: Find the multiple occurrences of the code segment
– Refactoring: Develop a standardized version of the code segment and replace with it
– Configuration Management: Prevent future occurrences of such code segments

Golden Hammer

Golden Hammer
■ To address different problems with only one solution every time
■ Forcing the one known or practiced solution to every problem instead of finding an
alternativeand more appropriatesolution
■ Using same architecture to solve diverse problems
■ Symptoms:
– Using same or identical tools to solve conceptually different problems
– Solution is changed depending on the availabletoolset
■ Consequences:
– Requirements are tailored to what the toolset does best
– Quality and performance of the solution is compromised
– Isolation from the industry

Golden Hammer
■ Solutions:
– Select most suitable and appropriatetoolset with respect to requirements
– Explore new technologies and find best possible solutions to the problem

Reference
■ AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.
Brown, Raphael C. Malveau, Hays W. McCormick, Thomas J. Mowbray, John Wiley &
Sons, 1998

3-Software Anti Design Patterns (Object Oriented Software Engineering - BNU Spring 2017)

More Related Content

Viewers also liked (20)

Similar to 3-Software Anti Design Patterns (Object Oriented Software Engineering - BNU Spring 2017) (20)

More from Hafiz Ammar Siddiqui (7)

Recently uploaded (20)

3-Software Anti Design Patterns (Object Oriented Software Engineering - BNU Spring 2017)