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 ifelse 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). Hublike 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 “ISA” 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: 9780128013977, Morgan KaufVann/Elsevier, 2014 hbB://amzn.com/0128013974