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 hasmore 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 identifiable template 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


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


Functional Decomposition■ Solutions:– Merge the class which contains a single behavior to an existing class in the systemwhere its related data resides

– If a class does not contain any state information, convert that class into a behaviorand insert that behavior into an appropriate existing class in the system

– Create new classes that satisfies the object oriented design and merge existingincompatible 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 functionalityto the related classes

– Simplify the system by removing all the classes with transient associations andmake direct associations among related classes


Cut & Paste Programming


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 alreadyavailableand 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


Cut & Paste Programming■ 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 analternative and more appropriate solution

■ Using same architecture to solve diverse problems

■ Symptoms:– Using same or identical tools to solve conceptually different problems– Solution is changed depending on the available toolset

■ 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 appropriate toolset 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


Education

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