8-bad-smells

4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 1

Before rushing into the design smells It is wise to make a
reasonable effort to refer to clean code,
Modularization, refactoring and
software metrics slides.

https://www.researchgate.net/profile/Simon_Hacks/publication/338854879_Towards_a_Catalog_of
_Enterprise_Architecture_Smells/links/5e2ff4a34585152d156f7b2d/Towards-a-Catalog-of-
Enterprise-Architecture-Smells.pdf
http://www.tusharma.in/smells/DESIGN.html

 Introduction
 Abstraction Smells
 Encapsulation Smells
 Modularization Smells
 Hierarchy Smells
 Conclusions

 Technical debt is the additional work needed to
complete software development.
 Technical debt is the difference between what
was promised and what was actually delivered.

 Technical Debt is regarded as a critical issue in terms of the negative
consequences such as increased software development cost, low
product quality, decreased maintainability.
 Technical Debt describes the delayed technical development activities
for getting short-term payoffs such as a timely release of a specific
software.
 Furthermore, Technical Debt is explained as the effect of immature
software artifacts, which requires extra effort on software maintenance
in the future.

 Definition:
 Design smells are certain structures in the design that indicate violation of
fundamental design principles and negatively impact design quality.
 Bad smells are certain structures in code that indicate the violation of
fundamental design principles and negatively impact software quality.
 Examples:
 Design smells:
- Classes with multiple responsibilities,
- Cyclically dependent classes.

 Architecture smells:
- Layering violations: Accesses from a lower level to a higher level layer,
- Tangled modules: Modules tightly coupled because of loops,
- Large interfaces: Components exposing large number of methods,
- In summary whatever violates modularity principles.
 Implementation smells:
- Loops that perform multiple tasks,
- Large methods,
- Complex conditional statements.
- In summary whatever violates clean code principles.

1.Alternative Classes with Different
Interfaces
2.Broken Hierarchy
3.Broken Modularization
4.Cut and Paste Programming
5.Cyclic Hierarchy
6.Cyclically-dependent Modularization
7.Data Class
8.Data Clumps
9.Deep Hierarchy
10.Deficient Encapsulation
11.Divergent Change
12.Duplicate Abstraction
13.Feature Envy
14.Functional Decomposition
15.God Class
16. God Class
17.Golden Hammer
18.Hub-like Modularization
19.Imperative Abstraction
20.Inappropriate Intimacy
21.Incomplete Abstraction
22.Incomplete Library Class
23.Inheritance Hierarchies
Without Polymorphic
Assignments
24.Insufficient Modularization
25.Large Class
26.Lava Flow
27.Lazy Class
28.Leaky Encapsulation
29.List-like Inheritance Hierarchy
30.Message Chains

31. Missing Abstraction
32. Missing Encapsulation
33. Missing Hierarchy
34. Multifaceted Abstraction
35. Multipath Hierarchy
36. Obsolete Classes
37. Parallel Inheritance Hierarchies
38. Poltergeist
39. Primitive Obsession
40. Rebellious Hierarchy
41. Refused Bequest
42. Shotgun Surgery
43. Spaghetti Code
44. Speculative Generality
45. Speculative Hierarchy
46. Static Cycles in Dependency Graphs
47. Subclasses Do Not Redefine Methods
48. Swiss Army Knife
49. Switch Statement
50. The Blob
51. Too Deep Inheritance
Hierarchy
52. Tree-like Dependency Graph
53. Type Queries
54. Unexploited Encapsulation
55. Unfactored Hierarchy
56. Unhealthy Inheritance
Hierarchy
57. Unnecessary Abstraction
58. Unnecessary Hierarchy
59. Unutilized Abstraction
60. Visibility of Dependency
Graphs
61. Wide Hierarchy
http://www.tusharma.in/smells/DESIGN.html

 Most harmful smells in priority order :
- God Class (or Large Class);,
- Brain Method (or Long Method);
- Shotgun Surgery;
- Message Chains;
- Dispersed Coupling;
- Intensive Coupling;
- Feature Envy.

 Metrics are used as a basis for automatic identification of code smells.
 Detection of smells requires a method to automatically derive thresholds for
design metrics.
Ref. JCodeOdor: A Software Quality Advisor Through Design Flaws
Detection

For Example

The four fundamental object oriented design principles are:
1. Abstraction:
 Distinguishes an object from all other kinds of objects,
 Provides conceptual boundaries, relative to the perspective of the
viewer.
2. Encapsulation:
 The process of compartmentalizing the elements of an abstraction that
constitute its structure and behavior;
 Serves to separate the contractual interface of an abstraction and its
implementation.

3. Modularity
 Modularity is the property of a system that has been decomposed into
a set of cohesive and loosely coupled modules.
2. Inheritance:
 Hierarchy is a ranking or ordering of abstractions.
All design smells in object oriented design could be traced back to
violations of the above four principles.

https://www.researchgate.net/publication/247152741_Towards_a_Principle-based_Classification_of_Structural_Design_Smells/figures?lo=1
Design Smells
Violation of O.O. design
Principles

Before rushing into the abstraction smells It is wise to make a
reasonable effort to know what the role of abstraction in
software engineering is and how it is modeled and
implemented.

 Abstraction is the concept of representing something at high level,
without going into too much details
 Focus on “What”
 As indicated by English meaning, abstraction indicates “only idea” – not
associated with anything concrete.
 In other words, it focuses on what and factors out how something
should be done.
 Most of the programming languages like C++, C#, Java supports two
types of abstraction namely Control Abstraction and Data Abstraction.

 Abstraction of behavior. Provides an easier, higher level API to
hide client from unnecessary execution details.
 In java, this can be achieved by using abstract keyword at
method and class level.
[codesnippet pb_margin_bottom=”yes” width=”1/1″ el_position=”first last”]
public abstract class Vehicle
{
public abstract void accelerate();
public abstract void doBreak();
public int getXPosition(){ // some implementation }
}
[/codesnippet]

 Any entity can be seen differently from different perspectives.
Car Abstraction with perspective of Vehicle Tracking System:
[codesnippet pb_margin_bottom=”yes” width=”1/1″
el_position=”first last”]
interface Trackable
{
int getXCoordinate();
int getYCoordinate();
}
[/codesnippet

Car Abstraction with perspective of Driver:
[codesnippet pb_margin_bottom=”yes” width=”1/1″ el_position=”first last”]
interface Drivable
{
void start();
void accelerate();
void reverse();
void doBreak();
String getSpeed();
void stop();
}
[/codesnippet]

 Data abstraction refers to defining the behavior of the data structure.
 Includes various data types provided by programming languages,
DBMS or language APIs.
 Data types in programming languages is the best data abstraction
example.
 DBMSs have abstractions of Table and View.
 Collection API’s Collection, List, Set and Map interfaces are
example of data abstractions.

 Incomplete abstraction:
 An important abstract implementation is to create a cohesive and complete
abstraction.
 This bad smell is caused when the abstract does not support all
complementary or related methods.
 If an abstraction does not support related methods, it may affect the cohesion
and integrity of the abstraction.

 Using a single method instead of a paired method
₋ For example, replace Enable() and Disable() with SetEnabled(bool), passing
true means enabled, and false means disabled.
 The JDK’s javax.swing.ButtonModel interface provides setGroup() method,
but does not provide the symmetric getGroup() method.

 This smell arises when clump of data or encoded strings are used instead of
creating a class or interface.

 ISBNs represented as 10-digit and 13-digit
forms consist of the elements: Prefix
Element, Registration, Group Element,
Registrant Element, Publication Element,
and Checksum.
₋ In the context of a library information
system, not encapsulating ISBN numbers as
class(es) indicates a Missing Abstraction
smell.

 This smell arises when an operation is turned into a class.
 This smell manifests as a class that has only one method defined within the
class.
 Tools to detect this smell: Designite(for C#) DesigniteJava(for Java).

 This smell arises when an abstraction has more than one responsibility
assigned to it.
 Responsibility is the work or action that each part of your system, the
methods, the classes, the packages, the modules are assigned to do.
 Too much responsibility leads to coupling.
 Components with low cohesion are doing tasks that are not related to their
responsibilities.

 we have a User Class that we keep some info in there:
 Makes sense to keep only methods that set or get the
role, name, age properties
 Those checkAge, validateEmail, slugifyName look
strange for sure.
 That would actually make the class less cohesive.

 This smell arises when an abstraction controls other abstractions in the
system.
 Also known as: “Brain class”.
 A Brain (or God) class tends to accumulate an excessive amount of
intelligence, usually in the form of several methods affected by
Brain Method.

 Brain Methods tend to centralize the functionality of a class, an entire
subsystem, or sometimes even a whole system.
 The strategy for detecting this design flaw:
₋ Method is excessively large.
₋ Method has long conditional branches.
₋ Method has deep nesting
₋ Method uses too many variables.

The Brain Method detection strategy.

This is an important decision, and
requires guidance from good software
engineering principles. Refer to third
paragraph in page 14 of:

 What is the average number of operations (methods) per class?
 Beyond which number of code lines is a method too large?
Statistical thresholds of 45 Java and 37 C++systems
 Average Number of Methods (NOM) per class
 Average Lines of Code (LOC) per method (operation)
 Average Cyclomatic Number (CYCLO) per line of code (i.e., density of
branching points)

 Lower margin: AV G − ST DEV .
 Higher margin: AV G + ST DEV .
 Very high: (AV G+ST DEV )· 1.5,
o Example. We want to know what a high WMC (Weighted
Method Count) value is for a class written in Java.

 This smell arises when an abstraction is left unused (either not directly used
or not reachable). This smell manifests in two forms:
₋ Unreferenced abstractions: Concrete classes that are not being used by
anyone.
₋ Orphan abstractions: Stand-alone interfaces/abstract classes that do not have
any subtypes.
 Also known as: “Classes with unused responsibility”

Before rushing into the encapsulation smells It is wise to make
a reasonable effort to know what the role of encapsulation in
software engineering is and how it is modeled and
implemented.

 If a chunk of code can receive parameters and return values, then it can be
observed from the outside as a unit that receives input, does some
processing, and produces the desired output.
 eg.:
public static Account[] sort(Account[] account)
 You don’t need to know which sort of algorithm was used by the
programmer who implemented the method.
 The welcome consequences of encapsulation known as information and
implementation hiding is to enable changing the internal design and
implementation decisions, without affecting anyone on the outside.
encapsulation is the basis of modularity, which can help you
construct complex systems by combining smaller components
 Encapsulate : enclose in a capsule, capture the essence of.

 Encapsulation is also known as information
hiding concept.
 The data and operations are combined into a
single unit.
 The only way to access data is through the
operations which are designed to operate on
the data.
 The data is not available to the external world.
 This concept may make the data safe and
secure from the external interventions.

 Encapsulation is a means of managing access to an object’s members:
₋ Private: visible only within the class,
₋ Protected: visible within its class and any class inherited form it.
 Encapsulation reduces maintenance cost by minimizing scope of change.
 Self-encapsulation goes a step further, indicating that all internal access
to a data field should also go through accessor methods as well.
 The fields of an object should not be exposed publicity, instead access
from outside should be via the accessor methods (getter and setter) .

 Here's an example of a reasonably encapsulated java class
class Charge {…
private int units;
private double rate;
public Charge(int units, double rate)
{ this.units = units;
this.rate = rate; }
public int getUnits() { return units; }
public Money getAmount() { return Money.usd(units * rate); }
}
 Both fields are immutable. The units field is exposed to clients of the class via
a getter, but the rate field is only used internally, so doesn't need a getter.

 Here is a version using slef-encapsulated:
class ChargeSE {…
private int units;
private double rate;
public ChargeSE(int units, double rate)
{ this.units = units;
this.rate = rate; }
public int getUnits() { return units; }
private double getRate() { return rate; }
public Money getAmount() {return Money.usd(getUnits() * getRate());}
}
 Self encapsulation means that getAmount needs to access both fields through
getters. This also means I have to add a getter for rate, which I should make private.

 The role of encapsulation and information hiding metrics in identification
of smelly and faulty classes in software code.
 Each class should present its identity (i.e., its interface) by a set of
services, which have one single responsibility and which provide a
unique behavior. Otherwise, the class smells.
https://shodhganga.inflibnet.ac.in/bitstream/10603/176830/12/12_chapter%203.pdf
 Each class should present its identity (i.e., its interface) by a set of
services, which have one single responsibility and which provide a
unique behavior. Otherwise, the class smells.

 Smell - Move field: the methods of another class seems to be
interested in a field of a class much more than the methods of the
class, containing the field.
 Smell – Data class: A class that has only properties and no methods is
a data class. Give life to data by adding methods that operate on the
data.
 Smell – Lazy method: Methods that neither aid code clarity nor
improve encapsulation. Use Inline Method refactoring to eliminate
such methods.

 Data classes unnecessarily increase coupling.
 Their encapsulation is poor because they do not provide functionality.
 Encapsulation metrics are applied to detect data class smells.

1. Weight of a Class (WOC)
o Definition:
o WOC =
𝑁𝑜.𝑛𝑜𝑛−𝑎𝑛𝑐𝑒𝑠𝑡𝑜𝑟 𝑚𝑒𝑡ℎ𝑜𝑑𝑠 𝑜𝑓 𝑎 𝑐𝑙𝑎𝑠𝑠
𝑇𝑜𝑡𝑎𝑙 𝑛𝑜.𝑚𝑒𝑚𝑏𝑒𝑟𝑠 𝑜𝑓 𝑡ℎ𝑒 𝑖𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒,𝑒𝑥𝑐𝑙𝑢𝑑𝑖𝑛𝑔 𝑖𝑛ℎ𝑒𝑟𝑖𝑡𝑒𝑑 𝑚𝑒𝑚𝑏𝑒𝑟𝑠
o Interpretation: Well designed classes tend to have a WOC value of 1.0.
o Outliers: Classes with values between 0 and 0.33.
2. Number Of Public Attributes (NOPA)
 Definition: NOPA is the no. non-inherited attributes of a class.
 Interpretation: Classes with public data members violate encapsulation.
 Outliers: The top-ten classes, but not having NOPA values less than 5.

3. Number Of Accessor Methods (NOAM)
 Definition: NOAM is the no. non-inherited accessor methods of a class.
 Interpretation: High NOAM value  part of the functionality of that class
is probably misplaced in one or more other classes..
 Outliers: The top-ten classes, but not having NOPM values less than 3.

 Design metrics measuring different aspects of an object-oriented software:
 size (e.g., number of methods of a class);
 complexity (e.g., maximum nesting level of control structures);
 cohesion (e.g., tight class cohesion);
 coupling (e.g., number of calls to other classes in the system);
 encapsulation (e.g., number of public attributes of a class);
 inheritance (e.g., depth of inheritance tree).
 Impacts of the metrics on software quality

o Measure two aspects, one is encapsulation aspect and the other
one is complexity aspect. Here it is calculated at method and
attribute level:
 EMA: (Encapsulated methods and attributes)
- Methods and attributes which are not used by any other class.
 DMA: (Direct accessible methods and attributes)
- Incorporates only those methods and attributes, used by other
classes.
 TMA: (Total numbers of methods and attributes)
- Considers all the methods and attributes in a class.
ECC = ( 𝐸𝑀𝐴 + 𝐷𝑀𝐴 ) / 𝑇𝑀𝐴

 “When a class has a relatively large number of methods or complex methods
with more than one responsibilities, it violates the decomposition principle
because of inadequate abstraction. This violation is called insufficient
modularity smell.
 Interfaces are used to decouple dependencies. Direct dependencies are
created between classes when a method of a class calls the methods of
another class, or a class extends another class or aggregates objects of
another class.
 Its better to have code duplicates than to delay testing of a component
because required changes to a superclass or library class it depends on are
pending.

• A bad smell in code
• Any symptom in the source code that possibly indicates a
deeper problem.
• The term is coined by Kent Beck.

 Problem: Name of the method or class does not succinctly
describe what the class is for, or what the method does.
 (e.g. When someone other than the developer looks at the code,
they don’t know what is going on)
 Solution: rename or rewrite it!

• Duplicated Code – identical or very similar code exists in more
than one location
• Long Method – method that has grown too large
• Large Class – class that has grown too large
• Long Parameter List – hard to understand/read
• Feature Envy – a class that uses methods of another class
excessively

• Large Class
• Large classes try to do too much, which reduces cohesion
• Long Parameter List
• hard to understand, can become inconsistent if the same parameter
chain is being passed from method to method
• Divergent Change
• symptom: one type of change requires changing one subset of
methods; another type of change requires changing another subset
• e.g., “I have to change these three methods every time I get a new
database.”
• Related to cohesion

• Shotgun Surgery
• a change requires lots of little changes in a lot of different
classes
• Feature Envy
• a method requires lots of information from some other class
• Move it closer!
• Data Clumps
• attributes that clump together (are used together) but are not
part of the same class

• Lazy Class
• A class that no longer “pays its way”
• e.g., may be a class that was downsized by a previous refactoring, or
represented planned functionality that did not pan out
• Speculative Generality
• “Oh, I think we need the ability to do this kind of thing someday”
• thus have all sorts of hooks and special cases to handle things that aren’t
required
• Temporary Field
• An attribute of an object is only set/used in certain circumstances;
• but an object should need all of its attributes

• Message Chains
• a client asks an object for another object and then asks that object
for another object etc.
• client depends on the structure of the navigation
• any change to the intermediate relationships requires a change to the client
• Middle Man
• If a class is delegating more than half its responsibilities to another
class, do you really need it? Involves trade-offs, some design patterns
encourage this (e.g., Decorator)
• Inappropriate Intimacy
• Pairs of classes that know too much about each other’s
implementation details (loss of encapsulation)

• Data Class (information holder)
• These are classes that have fields, getting and setting methods for the
fields, and nothing else; they are data holders, but objects should be
about data AND behavior
• Refused Bequest
• A subclass ignores most of the functionality provided by its superclass
• Subclass may not pass the “IS-A” test
• Comments (!)
• Comments are sometimes used to hide bad code
• “…comments are often used as a deodorant”(!)

8-bad-smells

Recommended

Recommended

More Related Content

Similar to 8-bad-smells

Similar to 8-bad-smells (20)

More from Morteza Zakeri

More from Morteza Zakeri (20)

Recently uploaded

Recently uploaded (20)

8-bad-smells

Editor's Notes