The document discusses refactoring for software design smells. It describes the authors' successful book on refactoring which catalogs 25 design smells related to abstraction, encapsulation, modularization, and hierarchy. The book focuses on structural and design smells. The authors have received positive reviews and feedback for their work and have conducted various workshops and presentations on design smells. Their work in identifying and classifying design smells has helped developers and architects improve software design quality.

1. Refactoring for Software Design Smells
A Visual Overview

2. Link: http://amzn.com/0128013974

3. This presentation is
about our successful
book on refactoring.
Link: http://amzn.com/0128013974

5. You can view smells
as violation of
fundamental design
principles; our book
catalogs 25 design
smells

7. In this book, we
focus only on
“structural” and
“design” smells

9. You can apply the
principles of abstract,
encapsulation
modularisation and
hierarchy proactively
through these key
enabling techniques

10. Published in Journal of Object Technology (Vol. 12, No. 2, 2013)
S G Ganesh, Tushar Sharma, Girish Suryanarayana. Towards a Principle-based
Classifica4on of Structural Design Smells. In Journal of Object Technology, vol.
12, no. 2, 2013, pages 1:1–29.doi:10.5381/jot.2013.12.2.a1
URL: hLp://www.jot.fm/issues/issue_2013_06/arPcle1.pdf (open access)

11. Published in Journal of Object Technology (Vol. 12, No. 2, 2013)
S G Ganesh, Tushar Sharma, Girish Suryanarayana. Towards a Principle-based
Classifica4on of Structural Design Smells. In Journal of Object Technology, vol.
12, no. 2, 2013, pages 1:1–29.doi:10.5381/jot.2013.12.2.a1
URL: hLp://www.jot.fm/issues/issue_2013_06/arPcle1.pdf (open access)
It all started with
our initial paper on
classifying smells; we
got really positive
review comments,
which encouraged us
to work further to
write it as a book

13. Our refactoring book
is now being
translated to other
languages; here is the
Korean translation of
the book!

15. Our work is being
well-received when
we present in top
conferences

17. We have written
many related articles
on this topic (this
article was published
in July 2015 in IEEE
Software magazine -
http://t.co/SiirTVDNa2)

19. We have presented in
many tutorials/
workshops across the
world - Tushar
presented this one in
DevWeek ’15

21. We have conducted
numerous workshops
on design smells
(this certificate is
from a workshop
organised by IEEE in
June 2015)

23. It’s a joy to see
people get “aha!”
moments and get
deeper
understanding when
they solve exercises
based on the book
(this picture was
taken during an
exercise in ICSE ’14
tutorial)

25. Developers and
architects have
picked up our design
smells work; here is
a Jam packed session
(100+ on-site and
180+ online
attendees) on Design
Smells in Siemens
PLM (Pune) in May
2016

27. People give awesome
feedback for our
training programs on
refactoring & design
smells

29. Check out Designite
tool (for C#) that
detects many smells
described in our
book and classifies
them based on
principles they
violate
(http://www:designite-tools:com/)

30. “Given its practical orientation and
the variety of real-world examples
offered throughout the book, this
is a must-have for any practicing
software engineer, developer,
software architect, or anyone else
interested in software design. This
book would also provide a good
introduction to real-world
problems in the context of a
software design or architecture
course."
- Extract from the book review in “ACM
Computing Reviews”

31. “Given its practical orientation and
the variety of real-world examples
offered throughout the book, this
is a must-have for any practicing
software engineer, developer,
software architect, or anyone else
interested in software design. This
book would also provide a good
introduction to real-world
problems in the context of a
software design or architecture
course."
- Extract from the book review in “ACM
Computing Reviews”
Numerous positive
reviews have
appeared for the
book; here is an
extract from one
such review

32. "This is a good book about ‘Design
Smells’ – actually a great book –
nicely organized - clearly written
with plenty of examples and a fair
sprinkling of anecdotes."
- Will Tracz (Principal Research Scientist
& Fellow, Lockheed Martin)

33. "This is a good book about ‘Design
Smells’ – actually a great book –
nicely organized - clearly written
with plenty of examples and a fair
sprinkling of anecdotes."
- Will Tracz (Principal Research Scientist
& Fellow, Lockheed Martin)
This quote is from
the book review in
ACM SIGSOFT
Software Engineering
Notes

35. Here is Tushar’s
recent work is on
detecting
configuration smells
(in Puppet code:
https://t.co/
RuypoQiNek)

37. We are also working
on the emerging
topic of architecture
smells and
refactoring (this
image from JDK 7
shows a tangle - an
architecture smell)

38. Refactoring for Software Design Smells
Abst%action
Missing Abst%action
This smell arises when clumps of data or
encoded strings are used instead of crea5ng
a class or an interface.
Imperative Abst%action
This smell arises when an opera5on is
turned into a class.
Incomplete Abst%action
This smell arises when an abstrac5on does
not support complementary or interrelated
methods completely.
Multifaceted Abst%action
This smell arises when an abstrac5on has
more than one responsibility assigned to it.
Unnecessar9 Abst%action
This smell occurs when an abstrac5on which
is actually not needed (and thus could have
been avoided) gets introduced in a so<ware
design.
Unutilized Abst%action
This smell arises when an abstrac5on is le<
unused (either not directly used or not
reachable).
Duplicate Abst%action
This smell arises when two or more
abstrac5ons have the iden5cal name or
iden5cal implementa5on or both.
Encapsulation
Deficient Encapsulation
This smell occurs when the declared accessibility
of one or more members of an abstrac5on is
more permissive than actually required.
Leaky Encapsulation
This smell arises when an abstrac5on “exposes”
or “leaks” implementa5on details through its
public interface.
Missing Encapsulation
This smell occurs when the encapsula5on of
implementa5on varia5ons in a type or hierarchy
is missing.
UnexBloited Encapsulation
This smell arises when client code uses explicit
type checks(using chained if-else or switch
statements) instead of exploi5ng the varia5on in
types already encapsulated within a hierarchy.
Modularization
Broken Modularization
This smell arises when data and/or methods
that ideally should have been localized into a
single abstrac5on are separated and spread
across mul5ple abstrac5ons.
Insufficient Modularization
This smell arises when an abstrac5on exists that
has not been completely decomposed and a
further decomposi5on could reduce its size,
implementa5on complexity, or both.
Cyclically- dependent
Modularization
This smell arises when two or more abstrac5ons
depend on each other directly or indirectly
(crea5ng a 5ght coupling between the
abstrac5ons).
Hub-like Modularization
This smell arises when an abstrac5on has
dependencies (both incoming and outgoing)
with large number of other abstrac5ons.
Hierarchy
Missing Hierarchy
This smell arises when a code segment uses
condi5onal logic (typically in conjunc5on with
“tagged types”) to explicitly manage varia5on in
behavior where a hierarchy could have been
created and used to encapsulate those
varia5ons.
Unnecessar9 Hierarchy
This smell arises when the whole inheritance
hierarchy is unnecessary, indica5ng that
inheritance has been applied needlessly for the
par5cular design context.
Unfactored Hierarchy
This smell arises when there is unnecessary
duplica5on among types in the hierarchy.
Wide Hierarchy
This smell arises when an inheritance hierarchy
is “too” wide indica5ng that intermediate
abstrac5ons may be missing.
Speculative Hierarchy
This smell arises when one or more types in a
hierarchy are provided specula5vely (i.e. based
on imagined needs rather than real
requirements).
Deep Hierarchy
This smell arises when an inheritance hierarchy
is "excessively" deep.
Rebellious Hierarchy
This smell arises when a subtype rejects the
methods provided by its supertype(s).
Broken Hierarchy
This smell arises when a supertype and its
subtype conceptually do not share an “IS-A”
rela5onship resul5ng in broken subs5tutability.
Multipath Hierarchy
This smell arises when a subtype inherits both
directly as well as indirectly from a supertype
leading to unnecessary inheritance paths in the
hierarchy.
Cyclic Hierarchy
This smell arises when a supertype in a
hierarchy depends on any of its subtypes.
“Refactoring for SoſtNare DesigO
Smells: Managing Technical Debt”,
Girish Sur9anarayana, Ganesh
SamarUhyam, Tushar SharVa, ISBN:
978-0128013977, Morgan KaufVann/
Elsevier, 2014
http://www.amazon.in/dp/935107305X
hbB://amzn.com/0128013974

39. Refactoring for Software Design Smells
Abst%action
Missing Abst%action
This smell arises when clumps of data or
encoded strings are used instead of crea5ng
a class or an interface.
Imperative Abst%action
This smell arises when an opera5on is
turned into a class.
Incomplete Abst%action
This smell arises when an abstrac5on does
not support complementary or interrelated
methods completely.
Multifaceted Abst%action
This smell arises when an abstrac5on has
more than one responsibility assigned to it.
Unnecessar9 Abst%action
This smell occurs when an abstrac5on which
is actually not needed (and thus could have
been avoided) gets introduced in a so<ware
design.
Unutilized Abst%action
This smell arises when an abstrac5on is le<
unused (either not directly used or not
reachable).
Duplicate Abst%action
This smell arises when two or more
abstrac5ons have the iden5cal name or
iden5cal implementa5on or both.
Encapsulation
Deficient Encapsulation
This smell occurs when the declared accessibility
of one or more members of an abstrac5on is
more permissive than actually required.
Leaky Encapsulation
This smell arises when an abstrac5on “exposes”
or “leaks” implementa5on details through its
public interface.
Missing Encapsulation
This smell occurs when the encapsula5on of
implementa5on varia5ons in a type or hierarchy
is missing.
UnexBloited Encapsulation
This smell arises when client code uses explicit
type checks(using chained if-else or switch
statements) instead of exploi5ng the varia5on in
types already encapsulated within a hierarchy.
Modularization
Broken Modularization
This smell arises when data and/or methods
that ideally should have been localized into a
single abstrac5on are separated and spread
across mul5ple abstrac5ons.
Insufficient Modularization
This smell arises when an abstrac5on exists that
has not been completely decomposed and a
further decomposi5on could reduce its size,
implementa5on complexity, or both.
Cyclically- dependent
Modularization
This smell arises when two or more abstrac5ons
depend on each other directly or indirectly
(crea5ng a 5ght coupling between the
abstrac5ons).
Hub-like Modularization
This smell arises when an abstrac5on has
dependencies (both incoming and outgoing)
with large number of other abstrac5ons.
Hierarchy
Missing Hierarchy
This smell arises when a code segment uses
condi5onal logic (typically in conjunc5on with
“tagged types”) to explicitly manage varia5on in
behavior where a hierarchy could have been
created and used to encapsulate those
varia5ons.
Unnecessar9 Hierarchy
This smell arises when the whole inheritance
hierarchy is unnecessary, indica5ng that
inheritance has been applied needlessly for the
par5cular design context.
Unfactored Hierarchy
This smell arises when there is unnecessary
duplica5on among types in the hierarchy.
Wide Hierarchy
This smell arises when an inheritance hierarchy
is “too” wide indica5ng that intermediate
abstrac5ons may be missing.
Speculative Hierarchy
This smell arises when one or more types in a
hierarchy are provided specula5vely (i.e. based
on imagined needs rather than real
requirements).
Deep Hierarchy
This smell arises when an inheritance hierarchy
is "excessively" deep.
Rebellious Hierarchy
This smell arises when a subtype rejects the
methods provided by its supertype(s).
Broken Hierarchy
This smell arises when a supertype and its
subtype conceptually do not share an “IS-A”
rela5onship resul5ng in broken subs5tutability.
Multipath Hierarchy
This smell arises when a subtype inherits both
directly as well as indirectly from a supertype
leading to unnecessary inheritance paths in the
hierarchy.
Cyclic Hierarchy
This smell arises when a supertype in a
hierarchy depends on any of its subtypes.
“Refactoring for SoſtNare DesigO
Smells: Managing Technical Debt”,
Girish Sur9anarayana, Ganesh
SamarUhyam, Tushar SharVa, ISBN:
978-0128013977, Morgan KaufVann/
Elsevier, 2014
http://www.amazon.in/dp/935107305X
hbB://amzn.com/0128013974
Download free
supporting material
from our website
www.designsmells.com
(this poster is
available for
download here)

41. Best of the
developers read
high-quality books to
hone their skills;
hope you’ll enhance
your book of
technical books by
adding our book!

42. ganesh.samarthyam@gmail.com
@GSamarthyam
www.designsmells.com
@designsmells