Analyzing Anti-pattern Detection
Southern Methodist University

Abstract
A design pattern is a well-understood, reusable design fragment used to solve a commonly occurring problem in software development. Whereas, antipatterns are common design pitfalls that provide poor solutions to recurring design problems. Developers may unwillingly introduce anti-patterns in their software systems due to time pressure, lack of skills, communication or understanding. Anti-patterns have a negative effect on the comprehension and maintainability of a software system, and thus, understanding and detecting Anti-patterns provides the knowledge to prevent or recover from them.
This paper discusses the anti-patterns of object oriented design, their symptoms, and consequences and issues related to their detection. This study also discusses some of the tools and approaches that are currently being developed and used in the software industry to detect anti-pattern. Towards the end, this paper also highlights some of the problems that are still open, to drive future research direction in this field.

1. Introduction
Now-a-days, most of the software projects deal with large number of components that make the software more complicated and hard for novice designers to design. A design pattern is one of the most simple and powerful techniques used to improve the software design. Unfortunately, due to a number of market/customers constraints, anti-patterns may get introduced into the software systems and deteriorate its software quality. Hence, anti-patterns need to be carefully detected and monitored and, consequently, refactoring operations should be planned and performed to deal with them.
In this paper, we will focus to present the different types of anti-patterns in object-oriented design, their symptoms and consequences, and the challenges and issues in detecting these anti-patterns. In a positive sense, Anti-patterns provide real-world experience in recognizing recurring problems in the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes. It

also helps us to take protective measures at several levels to improve the developing of applications, designing of software and the effective management of software projects. We would support this hypothesis by an empirical evaluation. By analyzing these approaches, we will also discuss some of the tools that are currently being used to detect anti-patterns. In addition to this, we will also discuss the issues that are still open, to drive future direction in this field.

2. Related Work
Several approaches based on different techniques were proposed to detect design defects in object oriented design. Rahma et al. used quality metrics to identify antipatterns in UM. Langelier et al. proposed a visual approach to detect anti-patterns. Kessentini et al proposed an automated approach that was based on detection rules for detecting design defects in software source code. Xue Qing proposed an approach for UML specification of Object oriented anti-patterns.
Stoianov and Sora proposed a logic based detection method using Prolog technique. Abdou Maiga proposed use of Support Vector Machine for anti-pattern detection. A number of tools like AnalystAJ, PMDm and Hammurapi were developed to identify antipatterns.
The research work carried out so far has some amount of limitation. They have limited precision and recall and require extensive knowledge of anti-patterns.
Also, they cannot be applied to subsets of systems.

3. Object-Oriented Design Anti-patterns
It is essential to have a good software structure for system extension and maintenance. Software development is a complex activity, and thus, the implemented structure of systems tends to stray from the planned structure as determined by architecture, analysis and design.
The good part about anti-patterns is that they can be used to identify the common problems and negative effects of the design solution. They also show how to prevent or resolve these problems. Let us discuss a few

types of anti-patterns that we have identified in object oriented design. [2]
1) Anemic Domain Model:
This anti-pattern occurs when the software domain objects contain little or no business logic and when data and behavior are separated in the domain model. The fundamental idea of objectoriented design is to combine data and process together. In contrast, the anemic domain model implements the business logic in separate classes which transforms the state of the domain objects. One solution to this design problem is to combine attributes and processes in one class.
2) Boat Anchor:
A Boat Anchor is a piece of hardware or software in the system that serves no useful purpose [5]. This causes many problems for developers who attempt to maintain the program that contains the obsolete code. The programmers have a hard time in differentiating the working code from the obsolete one.
3) The Blob:
It is a procedural-style design that leads to one object with a lion’s share of responsibilities, whereas other objects only hold data or perform simple tasks or processes. [5] [11]
4) BaseBean:
It is a utility class from which concrete entities have been derived via sub-classing. A class should not inherit from another class just because it contains a function needed in the subclass, and the delegation method should be used instead.
5) Call super:
This anti-pattern occurs when a super class requires subclasses to call an overridden method. In this design pattern, a particular class stipulates that in a derived subclass, the user is required to override method and call back the overridden function itself at a particular point.
6) Spaghetti Code:
This type of anti-pattern occurs when you have an ad-hoc software structure that makes it

difficult to extend and optimize code. It consists of classes without any structure, that have long methods without parameters, and that utilize the global variables for processing [5] [1] [10].
7) Circular Dependency:
This type of ant-pattern occurs when two or more objects or modules, directly or indirectly depend on each other. They are also known as mutually recursive modules. Software engineers may inadvertently introduce circular dependencies if given a very large and complex software design [8]. This anti-pattern can be found and removed by using tools used to analyze software or by using the observer pattern. [14]
8) Cut and paste programming:
This type of anti-pattern occurs when code is reused by copying the source code and simply pasting it to fit with the codebase [5]. This might cause significant maintenance issues. To avoid this anti-pattern, use alternative forms of reuse like black-box reuse. This would reduce maintenance issues by having common source code, testing and documentation. [13]
9) Functional Decomposition:
This anti-pattern occurs when experienced, nonobject-oriented developers design and implement an application in an object-oriented language. The resulting code resembles a structural language like PASCAL, FORTRAN in a class structure. Translating these into objectoriented architecture causes problems. [1] [5]
10) Lava Flow:
This type of anti-pattern occurs when a code that is written under sub-optimal conditions is frozen and put into production while it is still in a developmental state. This is similar to a Lava
Flow with hardening globules of rocky material.
The refactored solution includes a configuration management process that removes dead code and refactors design to increase code quality. [6]
[7] [12]
11) Poltergeists:
These depict type of classes that have very limited responsibilities in the system function

and have very brief life cycle. Poltergeists often start processes for other objects. They are one of the most unwanted anti-patterns because they consume and waste unnecessary resources every time they appear. [5][7][14][17]
12) Golden Hammer:
This anti-pattern is based on the assumption that an architecture, a solution or a software tool is the best solution for every software problem or project. The common notion is that if you have learned to use a tool in one context (golden hammer), now that you are so proud of having learned how to use this complicated tool, all of a sudden you see golden nails everywhere. [18]

4. Symptoms and Consequences of antipatterns
In this section, we will describe some symptoms and consequences of the anti-patterns defined above.
The basic symptom of an Anemic Domain Model anti-pattern is that at first glance, it seems like the real thing. There might be a number of objects that are named after the nouns in the domain space, and these objects might be connected with the rich relationships and structure that true domains have. However, the real catch comes when you look at their behavior and realize that there is hardly any behavior on these objects.
The most common symptoms and consequences of having a Boat Anchor anti-pattern in the code are getting longer compile times and having the risk that programmers may accidentally link working code into the dead code, inadvertently resurrecting it. Also, even if a programmer comes across a dead code, he might waste valuable time before he realizes that the code that he is working with is never executed and thus is not part of the problem he is trying to solve.
The common symptoms of having Blob anti-pattern in a code are having a single class with many attributes and operations, having a single controller class that has simple, data-object classes associated with it, lack of object-oriented design, or having a migrated legacy design. The Blob class is usually too complex for reuse and testing. Also, since it uses excessive resources even for simple operations, it may be an expensive option to load into memory.
The main cause behind BaseBean anti-pattern is when a software developer confuses an IS-A relationship, with a HAS-A relationship. This can be used as a base in detecting this anti-pattern. Call Super is pretty easy to spot. The documentation asks the developers that in order to do your own thing, you

should just sub-class the process method. However, it is important to remember to start your method with a call to the super class. Thus, whenever you have to remember to do something every time, that’s a sign of a bad API.
There are many symptoms and consequences of using a Spaghetti anti-pattern in the code. In this antipattern, the methods are very process-oriented. Most of the times, objects are named as processes and a minimal relationship exists between objects. Also, it becomes easy to predict the pattern of use of objects. In this design pattern, many object methods have no parameters and utilize class or global variables for processing. Code becomes difficult to reuse. In some cases, code is never considered for reuse.
Circular dependencies can cause many unwanted effects in a software program like the tight coupling of the mutually dependent modules which makes separate re-use of a single module impossible. It might also cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects. Also, this anti-pattern may cause memory leaks. Due to cut-and-paste-programming, the same software bug might get duplicated and might reoccur throughout the software, despite many local fixes in the code. There may be unnecessary increase in the lines of code without adding overall productivity or without the expected reduction in the maintenance costs associated with other forms of reuse. Code is considered as selfdocumenting and can be re-used with a minimum effort.
The major consequence of using this anti-pattern is that since the same software bug occurs throughout the code, it becomes difficult to locate and fix all instances of a particular mistake.
The most obvious symptoms of Functional
Decomposition may be the presence of classes with function names such as Calculate_Interest or
Display_Table. There might be no way to clearly document or even explain how the system works that may lead to class models that absolutely make no sense.
Also, this anti-pattern might contain all class attributes that are private and are only used inside the class. All the classes used in this design pattern may only have a single action such as a function and an incredibly degenerate architecture that completely misses the point of object-oriented architecture. This anti-pattern has no leveraging of object-oriented principles such as inheritance and polymorphism. Thus, the use of this design pattern might lead to frustration and hopelessness on the part of testers.
Frequent, unjustifiable variables and code fragments in the system, whole blocks of commented code with no documentation may indicate the presence of a Lava
Flow anti-pattern. The software contains undocumented

complex, important-looking functions, classes or segments that do not clearly relate to the system architecture. Lots of “in flux” or “to be replaced” code areas, unused code just left in are additional symptoms of Lava Flow anti-pattern. This anti-pattern might have some serious consequences. If the process that leads to
Lava Flow is not checked, the problem might grow exponentially as succeeding developers might unknowingly introduce new flaws as they try to work around the original ones.
Poltergeists have unnecessary and redundant navigation paths, transient associations and stateless classes along with the occurrence of temporary and short duration objects or classes. Due to the transient nature of this anti-pattern, it is extremely difficult to understand and analyze such a system and hence impossible to reuse. [17]
When identical tools and products are used for wide array of conceptually diverse products, or when solutions have inferior performance, scalability etc. when compared to other solutions in the industry, they indicate the presence of the Golden Hammer antipattern. The developers become isolated from the industry and demonstrate a lack of knowledge and experience with alternative approaches. The main consequence of this anti-pattern is that the requirements are not fully met, in an attempt to leverage existing investment. As a result, the design and system architecture is dictated by existing products, and the new software development relies completely on a specific vendor product or technology [18].

and other technologies in high-risk areas to enable minimal software rework.
One solution to resolve the problem of Blob antipattern is by refactoring. The main principle used behind this solution is to move behavior away from the Blob by encapsulating data objects in a way that makes these objects more capable and the Blob less complex. We use the following steps in refactoring Blob.
Consider a library system architecture diagram represented with a Bob Class called Library as shown in figure 1.

Figure 1: Library system architecture diagram [11]

1.

Identify or categorize related attributes and operations according to contracts. As shown in figure 2, we would group operations related to

5. Anti-pattern refactoring solutions or approaches used currently
As discussed in the previous sections, the structure of a software plays an important role with respect to system extension and maintenance. One solution to improve the software structure is to use software refactoring. The resulting structure does not have to resemble the original planned structure.
As the programmers learn constraints and approaches that modify the context of the coded solutions, the structure of the software changes. Thus, when used properly, refactoring can be considered as a natural activity in the programming process. Let’s discuss a few refactored solutions that are used to improve the structure of the software in anti-patterns.
To deal with Boat Anchor anti-pattern, the correct solution is to remove them from the codebase and to place them in a separate location, so that they can be referred to if necessary, but will not be compiled or mistaken as working code. Also, technical backups should be identified for most infrastructure technologies

Figure 2: Identified cohesive set of operations and attributes [11] catalog management like Sort_Catalog,,
Search_Catalog, and also identify operations and attributes related to individual items like Print_Item,
Delete_Item, etc.

2.

Find “natural homes” for these contract-based collections of functionality and then migrate them there. As shown in figure 3, we gather related operations and migrate them from
Library class to Catalog class, and from Library class to Item class, thus making Catalog and
Item classes more than simple encapsulated data tables that result in a better object-oriented design. be implemented by the subclasses and have the original method call that method.
The steps involved in eliminating the Spaghetti Code and using a refactored solution are as follows:
 Refactor to generalize: An abstract superclass is created:
1. Subclass function signatures are made compatible 2. Function signatures to the superclass are added 3. Function bodies and variables are made compatible 4. Common code is migrated to the superclass
 Refactor to specialize: Conditionals are simplified: 1. A subclass with matching invariant is created for each condition
2. The code is coped into the subclass
3. Code is simplified based upon the invariant
4. The superclass constructor is specialized


Figure 3: Operations to be migrated to the catalog class [11]

3.

Finally, remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments. As shown in figure 4, we remove the
Item class that is far-coupled to the Library class and migrate Items to Catalogs.

Figure 4: Removing all transient associations [11]

To avoid BaseBean anti-pattern, the inherited functionality should be provided via delegation method.
Delegation (HAS-A relationship) should be used to obtain the business logic or data structure that is required. If applicable, in some cases, a Java utility class containing only static methods can be created to contain the necessary functionality.
One approach to solve the Call Super anti-pattern issue is to use the template method pattern where the superclass includes a purely abstract method that must

Refactor to combine: Aggregations and components are captured:
Type A. Members from an aggregate class are moved to a component class
Type B. Members from a component class are moved to an aggregate class
Type C. Inheritance is converted to aggregation

To avoid Circular Dependency anti-patterns, the developers should use tools to analyze software and to find unwanted circular dependencies. Generally, the circular dependencies are introduced by inexperienced programmers who need to implement some kind of callback functions. However, such unnecessary circular dependencies are avoided by experienced programmers by applying design patterns like observer pattern.
The most effective solution for Cut and Paste
Programming anti-pattern is to refactor the code base into reusable libraries or components that use Black Box reuse method. Black-box reuse reduces maintenance issues by having a common source code, testing and documentation for multiple reuses.

Since there is no direct way to refactor, we redesign using Object-Oriented principles to eliminate
Functional Decomposition. Let us discuss the solution approach used. First, an analysis model is defined for the software to explain the critical features of the software from the user’s point of view. Next, a design model is formulated that incorporates the essential features of the existing system. Here, the focus is to establish a basis for explaining the system as much as possible rather than improving the model. Ideally, the design model will justify or at least rationalize, most of the software modules. The new design model provides insight as to how the overall system fits together.
Finally, examine the design and find similar subsystems. Those would be our reuse candidates. Now, the program can be maintained by refactoring the code base to reuse code between similar subsystems.
The only sure-fire way to prevent Lava Flow antipattern is by ensuring sound architecture is preceding the production code development. This so-called sound architecture must be backed up by a configuration management process that ensures architectural compliance and accommodates the changing requirements (“mission creeps”). If Lava Flow antipattern already exists in the code, then architecture changes should be avoided during active development.
Thus, the management must postpone development until a clear architecture is defined and disseminated to developers. System discovery activities should be used while defining the architecture since it is required to locate the components that are really used and necessary to the system. It also identifies those lines of code that can be safely deleted. However, when suspected dead code is eliminated, bugs could be introduced. The cause of the error should be fully understood to immediately fix the symptoms. To avoid Lava Flow, it is important to establish system-level software interfaces that are stable, well-defined, and clearly documented. Tools that can are used to assist in configuration management are
Source-Code Control System (SCCS).
Poltergeists can be eliminated from the system by removing the class hierarchy altogether as suggested by
Ghostbusters. However, after their removal, the functionality that was provided by the poltergeists must also be replaced. The following steps illustrate the
Poltergeists Refactored Solution:
 Refactor to eliminate the irrelevant classes:
This can be achieved by deleting the external classes (classes that outside the system) and by deleting the classes with no domain relevance.
 Refactor to eliminate the transient “data classes”  Refactor to eliminate “operation classes”



Refactor other classes with short lifecycles or few responsibilities:
This can be achieved by moving into collaborating classes and regrouping into cohesive larger classes.
The key aspect is to move the controlling actions initially encapsulate in the Poltergeist into the related classes that they are invoked. Consider the Peach
Canning example shown in figure 5.
Figure 5: Peach_Canner_Controller is a Poltergeist [13]

As shown in Figure 5, the Peach_Canner_Controller class has redundant navigation paths to all other classes in the system, all of its associations are transient and it has no state. Also, it is a temporary, short-duration class that pops into existence only to invoke other classes through temporary associations.

Figure 6: The Poltergeist class is removed [13]

We remove the Poltergeist class so that the remaining classes lose the ability to interact and there is no longer any ordering of processes as shown in figure 6.
Golden Hammer anti-pattern can be avoided by using two approaches – philosophical and developmental. Philosophically, an organization needs to develop a commitment to an exploration of new technologies. Expanding a knowledge of developers through education, training and book study groups

would expose the developers to new solutions. Apart from that, software systems need to be designed and developed with well-defined boundaries that facilitate the replaceability of individual software components.
Apart from the solutions discussed in this paper, there are several other tools and techniques that are currently being used to detect and analyze the antipatterns in the software design.

6. Challenges and Issues in OOD antipatterns detection techniques
As discussed in the above sections, several techniques are proposed for detecting and preventing anti-patterns in software systems. However, these techniques have some critical issues and challenges that need to be dealt with.
If used appropriately, anti-patterns can be used in recognizing the recurring problems in the software industry and can help in implementing a better product or software.
Addressing the following issues may help antipatterns gain acceptance.
The strength of anti-patterns comes from an expanded knowledge base like that with design patterns.
For anti-patterns to become increasingly useful, it is important to enhance the presence of the online collaboration of resources like Wiki, blogs etc. The developers should be strongly encouraged to refer the knowledge base and follow the guidelines while developing any software code.
Different Design patterns and anti-patterns refer to many different pattern definition languages and corresponding templates. The overall lexicon of Design patterns is consistent. However, due to the lack of a single seminal work, the anti-pattern definitions seem to be inconsistent. Thus, a need for standard lexicon arises.
Since anti-patterns focus on mistakes in the design patterns, a logical extension of that investigation is to search for the person who is responsible for that mistake. However, this creates unwilling participants and threatens the effective use of anti-patterns. In such situations, the administrations usually tend to ignore the fact that anti-patterns can arise through no fault of an individual but might be a result of obsolescence of technology or similar reasons.
Apart from these, there are a number of critical issues with respect to the detection of anti-patterns in the software system. One major issue in anti-pattern detection is in extracting information from source code components in order to identify symptoms of poor design choices. Different sources of information have different design choices. Also, the type of information to be exploited depends on the kind of anti-pattern to be

detected. Thus, building a tool to detect anti-patterns in software system becomes difficult.
Another major issue is in defining the algorithm to identify candidate anti-patterns. Since each algorithm has its own strengths and weaknesses, an algorithm ensuring a fair compromise of strengths and weaknesses must be chosen depending on the anti-pattern that is under analysis.
Also, there are number of disadvantages in using manual and auto detection approaches in detecting antipatterns. Manual detection approach consumes a large amount of time and effort, and suffer from the anomaly detection, such as context-dependence and ambiguous definitions. In order to overcome time and effort problems, auto detection approaches were developed.
However, they suffer from the uncertainty problems that provide no indication of which set of candidate classes should be inspected first for confirmation and correction. Apart from these, there are a number of challenges with respect to using rule based detection technique or
BBN based detection technique and so on.

8. Conclusions
An anti-pattern is a pattern gone bad, and it represents symptoms of poor design and implementation choices. Anti-patterns may result in time-consuming maintenance operations due to their lower comprehensibility and maintainability and hence, seem to be complex [3]. It can be the result of a manager or developer not knowing any better or not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context. [16]
Anti-patterns
mostly generate negative consequences whereas refactored solution generates positive benefits. In this paper, we discussed a number of object-oriented design patterns, their symptoms and consequences. We also discussed the issues and challenges that have to be faced while detecting antipatterns.
Thus, anti-patterns can be used for refactoring, migration, upgrade and reengineering. Having said that, design patterns are widely accepted and have abundant resources, but the concept of anti-patterns is still relatively immature and should be discussed and used more frequently. There are still some open issues that need to be addressed and need more analysis and research. Some of them are - Are anti-patterns really harmful [4], providing a complete support for the identification of anti-patterns, use of historical and lexical analysis to detect anti-pattern, analyzing the usability of detection tools, and so on [1].

9. References
[1] Palomba, F., BAVOTA, G., OLIVETO, R., & DE LUCIA,
A. N. D. R. E. A. (2014). Anti-Pattern Detection: Methods,
Challenges, and Open Issues.ADVANCES IN COMPUTERS,
VOL 95, 95, 201-238.

[2] Din, J., Al-Badareen, A. B., & Jusoh, Y. Y. (2012,
December). Antipatterns detection approaches in ObjectOriented Design: A literature review. InComputing and
Convergence Technology (ICCCT), 2012 7th International
Conference on (pp. 926-931). IEEE.

[9] Design Patterns and Refactoring. (n.d.). Retrieved April
28, 2015, from https://sourcemaking.com/antipatterns
[10] Moha, N., Guéhéneuc, Y. G., Le Meur, A. F., Duchien,
L., & Tiberghien, A. (2010). From a domain analysis to the specification and detection of code and design smells. Formal
Aspects of Computing, 22(3-4), 345-361.
[11] Design Patterns and Refactoring. (n.d.). Retrieved April
28, 2015, from https://sourcemaking.com/antipatterns/theblob
[12] Design Patterns and Refactoring. (n.d.). Retrieved April
28, 2015, from https://sourcemaking.com/antipatterns/lavaflow

[3] Elaasar, M. E. (2012). An Approach to Design Pattern and
Anti-Pattern
Detection in MOF-Based
Modeling
Languages (Doctoral dissertation, Carleton University
Ottawa).

[13] What is Circular dependency and how do we resolve it?
(n.d.).
Retrieved
April
28,
2015,
from http://www.codeproject.com/Articles/616344/What-isCircular-dependency-and-how-do-we-resolve [4] Abbes, M., Khomh, F., Guéhéneuc, Y. G., & Antoniol, G.
(2011, March). An empirical study of the impact of two antipatterns, blob and spaghetti code, on program comprehension. In Software Maintenance and Reengineering
(CSMR), 2011 15th European Conference on (pp. 181-190).
IEEE.

[14] Design Patterns and Refactoring. (n.d.). Retrieved April
28,
2015, from [5] Mowbray, T. J., Brown, W. J., & McCornnick III, H. W.
(1998). AntiPatterns: Refactoring software, architectures, and projects in crisis. ed: John Wiley & Sons, Hoboken, NJ.
[6] Fowler, M. (1997). Refactoring: Improving the Design of
Existing Code.
[7] Stoianov, A., & Sora, I. (2010). Detecting patterns and antipatterns in software using Prolog rules. In Computational
Cybernetics and Technical Informatics (ICCC-CONTI), 2010
International Joint Conference on (pp. 253-258).
[8] Ballis, D., Baruzzo, A., & Comini, M. (2008, April). A minimalist visual notation for design patterns and antipatterns.
In Information Technology: New Generations, 2008. ITNG
2008. Fifth International Conference on (pp. 51-56). IEEE.

https://sourcemaking.com/antipatterns/poltergeists
[15] AntiPattern - Cut-And-Paste Programming. (n.d.).
Retrieved
April
28,
2015, from http://www.darxstudios.com/darxstudios/2014/9/7/antipattern-cut-and-paste-programming
[16] Development AntiPattern:. (n.d.). Retrieved April 28,
2015, from http://www.antipatterns.com/briefing/sld022.htm
[17] Poltergeist-the most unwanted antipattern. (n.d.).
Retrieved
April
28,
2015, from http://icmgworld.com/corp/news/Articles/RS/jan_0302.asp
[18] Software Antipatterns : The Golden Hammer. (n.d.).
Retrieved
April
28,
2015, from http://codebalance.blogspot.com/2010/10/softwareantipatterns-golden-hammer.html