Software AntiPatterns

Why do we care about Quality?

Req. & Specification

• Development cost • Correction cost & source

– Specification : 6% Req. & Specification 56%

– Design : 5% Design 24%
– Coding : 7% Coding 10%
– V&V (Testing) : 15% Other 10%
– Maintenance : 67%

2
 Quality seen by the customer

• When customers associate Quality or High Quality with software

system, it is an indication that few, if any, defects are expected to
occur during its operations or when problems do occur, the negative
impact is expected to be minimized.
• Key of the correctness aspect of software quality is the concept of
defect, failure, fault and error.
• The term “defect” refers to some problem with the software either
with its external or with internal characteristics.

3
 Software errors, faults and failures

An error can be a grammatical/syntactic error in one or more of the code

lines, or a logical error in carrying out one or more of the client’s
requirements.

Not all software errors become software faults. in some cases, the
software error can cause improper functioning of the software. In
many other cases, erroneous code lines will not affect the functionality
of the software as a whole.

A failure is said to occur whenever the external behavior of a system

does not conform to that prescribed in the system specification. A
software fault becomes a software failure only when it is “activated”.

4
 Causes of software failures

1. Faulty requirements definition

2. Client-developer miscommunication/misunderstanding
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding
instructions
7. Shortcomings of the testing process
8. Wrong testing process
9. Documentation errors
5
 Definition of Quality
Errors, faults, failures

© Aditya P. Mathur 6
2009
 OO paradigm

• There is many benefits in using OO for analysis, design, coding.

• These benefits include better understandability, easier
modifications, greater productivity, and simpler reuse.
• The literature suggests many explanations for the apparent lack of
use of OO:
• OO notions (objects, polymorphism, inheritance, encapsulation…)
are not easy to learn and use adequately.
• The lack of use of OO impacts negatively the understandability of
systems.
• Lack of use of design patterns deteriorate the quality of OO systems
and make them harder to maintain. This is known as defects
 Design defects

• Software Quality is…

– Meet the customer satisfaction (J. Juran)
– compliance to standards (W.E. Perry)
– zero defects (Crosby)
OO paradigm
OO paradigm

?
 Design defects

• Defects, symptoms that:

– are introduced during the initial design or
during evolution
– make the design harder to understand, to
change
– adversely affect the development of a software
– Examples: Large Class, Feature Envy,
Duplicated Code.
 Design defects

• Refactoring
– The process of improving a code after it has been written by
changing its internal structure without changing the external
behavior (Fowler et al., ‘99)
– Examples: Move method, extract class, move attribute...
• Refactoring steps
– Detection of code fragments to improve (e.g., defects)
– Identification of refactoring operations

12
 Detection strategy

• A detection strategy is a metrics-based predicate to

identify candidate software artifacts that conform to (or
violate) a particular design rule.
 Class Blue print

• Initialization: Constructors
• External interface: Libraries, Inheritance,
Interfaces etc.
• Internal Implementation: Class own methods,
polymorphic functions.
God Class

• A God Class centralizes intelligence in the

system and tends to concentrate functionality
from several unrelated classes
– Impacts understandability
– Increases system fragility
 Design defects
ModelFacade (ArgoUML)

• 453 methods
• 114 attributes
• over 3500 LOC
• all methods
and all
attributes are
static
 Design defects
Data Class

• A Data Class provides data to other classes but

little or no functionality of its own
Design defects

Property
 Design defects
Refused Parent Bequest

• The relation between a parent class and its

children is intended to be an inheritance one,
more special than the collaboration between
two unrelated classes. if a child class refuses to
use this special bequest prepared by its parent,
then this is a sign that something is wrong
within that inheritance relation
Design defects
Refused Parent Bequest
 Design defects
Brain Method

• Often a method starts out as a “normal” method

but then more and more functionality is added to
it until it gets out of control. Brain Methods tend
to centralize the functionality of a class, in the
same way as a God Class centralizes the
functionality of an entire subsystem, or
sometimes even a whole system.
 Design defects

Modeller Class
 Design defects
Feature Envy

• Methods that are more interested in data of

other classes than their own [Fowler et al. 99].
This situation is a string indication that the
affected method was probably misplaced and
that it should be moved to the capsule that
defines the "envied data".
Design defects

ClassDiagramLayouter
 Design defects
Shotgun Surgery

• A change in an operation implies many (small)

changes to a lot of different operations and
classes. This particular flaw tackles the issue of
strong afferent (incoming) coupling and it
regards not only the coupling strength but also
the coupling dispersion
Design defects
Illustrative Example
Design defects
Project
 Design defects
• Refactoring
 Software Refactoring

Refactoring

Move method
Extract class
Move field
?
Add association
…

Millions of possible combinations of refactorings

Generating the list of best refactorings is infeasible on a reasonable time
Exhaustive techniques fall short to provide solutions

7/4/2022 29
 Test Smells

• Are defined as anti-patterns.

• They have a formal definition but their detection

strategy may differ based on the target technology /
language.

• It is important to detect them then refactor them to

improve the quality of the test set.

• In the following we will discuss popular test smells

 Assertion Roulette

• Fix:
– Remove unneeded assertions
– Add Assertion Explanation
 Assertion Roulette

• This smell comes from having a number of

assertions in a test method that have no
explanation.
• Thus, if an assertion fails, the identification of
the assert that failed can be difficult.
 Eager Test

• Fix:
– Apply Extract Method refactoring to split the test
method in order to specialize its responsibilities.
 Eager Test

• A test that checks more than one method of

the class to be tested.
• Makes the comprehension of the actual test
target difficult.
 Mystery Guest

• Fix:
– Setup External Resource operation is suggested,
no definitive solution for this smell.
 Mystery Guest

• A test uses external resources (e.g., a file

containing test data)
• It is not self-contained.
• Difficult to comprehend and maintain, due to
the lack of information about their design.
 Conditional Test Logic

• Fix:
– The application of an Extract Method to break
down the testing logic into separate methods.
 Conditional Test Logic
• Test methods need to be simple and execute all
statements in the production method.
• Conditions within the test method will alter the
behavior of the test and its expected output, and
would lead to situations where the test fails to
detect defects in the production method since
test statements were not executed as a condition
was not met.
• Deep nested Conditional code within a test
method negatively impacts the ease of
comprehension.
 Constructor Initialization

• Fix:
– Use setup instead of the constructor when
applying any initialization.
 Constructor Initialization

• Ideally, the test suite should not have a

constructor.
• Initialization of fields should be in the setUp()
method.
• Developers who are unaware of the purpose
of setUp() method would define a constructor
for the test suite.
 Default Test

• Fix:
– Use proper naming convention and use the
default test file as a template and not as one of
the main testing files.
 Default Test
• By default some IDEs create default test classes
when a project is created. These classes are
meant to serve as an example for developers
when wring unit tests and should either be
removed or renamed.
• Having such files in the project will cause
developers to start adding test methods into
these files, making the default test class a
container of all test cases.
• This also would possibly cause problems when
the classes need to be renamed in the future.
 Empty Test

• Fix:
– Remove all empty tests.
 Empty Test
• Occurs when a test method does not contain
executable statements. Such methods are possibly
created for debugging purposes and then forgotten
about or contains commented out code.
• An empty test can be considered problematic and
more dangerous than not having a test case at all since
JUnit will indicate that the test passes even if there are
no executable statements present in the method body.
• As such, developers introducing behavior breaking
changes into production class, will not be notified of
the alternated outcomes as JUnit will report the test as
passing.
 Unknown Test

• Fix:
– Change the testing logic to use asserts.
 Unknown Test
• An assertion statement is used to declare an
expected Boolean condition for a test method. By
examining the assertion statement it is possible
to understand the purpose of the test method.
• However, It is possible for a test method to
written without an assertion statement, in such
an instance JUnit will show the test method as
passing if the statements within the test method
did not result in an exception, when executed.
• Difficult in understanding the purpose of such
test methods (more so if the name of the test
method is not descriptive enough).
Design defects

History of code smells

 Defects summary by Fowler (2002)

•Parallel Inheritance Hierarchies

•Duplicated Code •Lazy Class
•Long Method •Speculative Generality
•Large Class •Temporary Field
•Long Parameter List •Message Chains
•Divergent Change •Middle Man
•Shotgun Surgery •Inappropriate Intimacy
•Feature Envy •Alternative Classes with Different Interfaces
•Data Clumps •Incomplete Library Class
•Primitive Obsession •Data Class
•Switch Statements •Refused Bequest
•Comments
 Test Smells by Van Deursen (2002)

•Mystery Guest
•Resource Optimism
•Test Run War
•General Fixture
•Eager Test
•Lazy Test
•Assertion Roulette
•Indirect Testing
•For Testers Only
•Sensitive Equlity
•Test Code Duplication
 Defects summary by Fowler (2002)
1. Duplicated code: means that the same code structure appears in more than one place.
2. Long method: is a method that is too long, so it is difficult to understand, change, or extend.
3. Large class: means that a class is trying to do too much. These classes have too many instances, variables or methods.
4. God class: usually called also design flaw, refer to class that tends to centralize the intelligence of the system.
5. Divergent Change: Adding a small feature to the code requires updating more than one class or method, Extract class solve this by putting them together.
6. Shotgun surgery: Similar to Divergent Change but in opposite way, changing a small feature requires more small changes that are hard to find.
7. Long parameter list: a long list of parameters in a procedure or function make readability and code quality worse.
8. Feature envy: A method is more interested in other classes than the one where it is located. It is in the wrong place since it is more tightly coupled to the other classes.
9. Contrived complexity: forced usage of overly complicated design pattern where simpler design would suffice.
10. Complex conditionals: branches that check lots of unrelated conditions and edge cases that don't seem to capture the meaning of a block of code.
11. Primitive obsession: the smell represents a case where primitives are used instead of small classes.
12. Switch statement: the smell means a case where type codes or runtime class type detection are used instead of polymorphism.
13. Data clumps: the smell means that software has data items that often appear together.
14. Temporary fields: the smell means that class has a variable which is only used in some situation.
15. Refused bequest: the smell means that a child class does not fully support all the methods or data it inherits.
16. Lazy class: a class that is doing nothing enough and should be removed.
17. Data class: a class that contain data, but hardly any logic for it.
18. Middle man: it means that a class is delegating most of its tasks to subsequent classes.
19. Divergent change: the smell means that one class need to be continuously changed for different reasons.
20. Parallel Inheritance Hierarchies: Special case of shotgun surgery, The creation of a subclass of one class leads to creation of a subclass of another class.
21. Speculative Generality: A code which is too general: Long hierarchies with many abstract classes and many delegations.
22. Message Chains: When called action creates a chain of objects that communicate to get to the last one to respond to the requested action.
Defects summary by Mantaya (2003)
Defects summary by Marienscu (2003)
Defects summary by Marienscu (2006)
Moha’s smells classification (2009)
 Android Smells by Reimann (2014)
•Data Transmission Without •Rigid Alarm Manager
Compression •Slow Loop
•Debuggable Release •Unclosed Closable
•Durable Wakelock •Etc. (15 more).
•Inefficient Data Format and
Parser
•Inefficient Data Structure
•Inefficient SQL Query
•Internal Getter and Setter
•Leaking Innder Class
•Leaking Thread
•Member Ignoring Method
•No low Memory Resolver
•Public Data
 Summary
Richard Soley - CEO - Object Management Group – About Standardizing
defects metrics:
http://www.youtube.com/watch?v=bMYv6FYVOVA#t=104

56