Downloaded 264 times
Uploaded byTushar Sharma
Refactoring for Design Smells - ICSE 2014 Tutorial
This document discusses design smells in software and their impact on quality. It begins with an introduction to design quality, technical debt, and design smells. It then provides a catalog of various design smells organized by principles of abstraction, encapsulation, modularization, and hierarchy. For each smell, it provides examples from code and discusses corresponding refactoring techniques. It also discusses how smells are interrelated and how understanding their ecosystem is important for improving design quality in practice. The key takeaways are repaying technical debt through refactoring design smells to improve changeability, understandability and other quality attributes.
More Related Content
Similar to Refactoring for Design Smells - ICSE 2014 Tutorial
Refactoring for Design Smells - ICSE 2014 Tutorial
- 1. Girish Suryanarayana, GaneshSamarthyam, Tushar Sharma
- 2. 2 Outline Introduction – DesignQuality, Technical Debt, and Design Smells Design Smells Catalog – Examples and corresponding Refactoring The Smell Ecosystem and Repaying Technical Debt in Practice
- 3. 3 Outline Introduction – DesignQuality, Technical Debt, and Design Smells Design Smells Catalog – Examples and corresponding Refactoring The Smell Ecosystem and Repaying Technical Debt in Practice
- 4. Capers Jones ondesign errors in industrial software * http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf 0 20 40 60 80 100 120 IBM Corportation (MVS) SPR Corporation (Client Studies) TRW Corporation MITRE Corporation Nippon Electric Corp PercentageContribution Industry Data on Defect Origins Adminstrative Errors Documentation Errors Bad Fixes Coding Errors Design Errors Requirements Errors Up to 64% of software defects can be traced back to errors in software design in enterprise software!
- 5. Why care aboutdesign quality? Poor software quality costs more than $150 billion per year in U.S. and greater than $500 billion per year worldwide The debt that accrues when you knowingly or unknowingly make wrong or non-optimal design decisions Software Quality Technical Debt Design Quality Design Quality means changeability, extensibility, understandability, reusability, ...
- 6. 6 Why care abouttechnical debt? Global 'IT Debt‘ is $500 billion for the year 2010,with potential to grow to $1 trillion by 2015
- 7. 7 What constitutes technicaldebt? … Code debt Static analysis tool violations Inconsistent coding style Design debt Design smells Violations of design rules Test debt Lack of tests Inadequate test coverage Documentation debt No documentation for important concerns Outdated documentation
- 8. “Design smells” aka… “Smellsare certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring.” What is a smell?
- 9. 9 Why care aboutsmells? Impacted Quality § Reusability § Changeability § Understandability § Extensibility § … Product Quality Design Quality Design Smells Impacted Quality § Maintainability: Affected by changeability & extensibility § Reliability: Impacted by poor understandability § … Indicators § Rigidity & Fragility § Immobility & Opacity § Needless complexity § Needless repetition § …
- 10. 10 What causes designsmells?
- 11. 11 Why we focuson smells? A good designer is one who knows the design solutions A GREAT designer is one who understands the impact of design smells and knows how to address them
- 12. 12 Design Smells asviolations of fundamental principles What do smells indicate? Violations of fundamental design principles We use Booch’s fundamental principles for classification and naming of smells This helps identify cause of the smell and potential refactoring as well
- 13. 13 Principles used toclassify design smells
- 14. 14 Quality attributes impactedby smells
- 15. 15 A principle-based approachto design smells classification Related Publications S G Ganesh, Tushar Sharma, Girish Suryanarayana. Towards a Principle-based Classification 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: http://www.jot.fm/issues/issue_2013_06/article1.pdf (open access)
- 16. 16 Summary till now DesignQuality Technical Debt Design Smells Why care about smells
- 17. 17 Outline Introduction – DesignQuality, Technical Debt, and Design Smells Design Smells Catalog – Examples and corresponding Refactoring The Smell Ecosystem and Repaying Technical Debt in Practice
- 18.
- 19. 19 A note onexamples in this presentation We cover only a few examples of each smell category in this presentation Lack of time Most examples are from OpenJDK 7.0 (open source) All illustrations are mostly as UML diagrams so no need to know Java (though you’ll appreciate more if you know Java) Almost all examples are UML-like diagrams – so agnostic of OO language Some code examples are in Java, but they are very few
- 20.
- 21. 21 The principle ofabstraction
- 22. 22 Enabling techniques forabstraction
- 23.
- 24. 24 Incomplete abstraction This smellarises when a type does not support a responsibility completely Specifically, the public interface of the type is incomplete in that it does not support all behavior needed by objects of its type
- 25. 25 Incomplete abstraction –Example In this case, the MutableTreeNode supports only setUserObject but no corresponding getUserObject (which is provided in its derived class!) Hence, MutableTreeNode has Incomplete Abstraction smell How to fix it? Provide all the necessary and relevant methods required for satisfying a responsibility completely in the class itself In case of public APIs (as in this case), it is often “too late” to fix it!
- 26.
- 27.
- 28. 28 How to refactor& in future avoid this smell? For each abstraction (especially in public interface) look out for symmetrical methods or methods that go together For example, methods for comparing equality of objects and getting hash code (in Java/C#) Look out for missing matching methods in symmetrical methods (see table) min/max open/close create/destroy get/set read/write print/scan first/last begin/end start/stop lock/unlock show/hide up/down source/target insert/delete first/last push/pull enable/disable acquire/release left/right on/off
- 29.
- 30. 30 Duplicate abstraction This smellarises when two or more abstractions have identical names or identical implementation or both.
- 31.
- 32. 32 Kinds of clones •exactly identical except for variations in whitespace, layout, and comments Type 1 • syntactically identical except for variation in symbol names, whitespace, layout, and comments Type 2 • identical except some statements changed, added, or removed Type 3 • when the fragments are semantically identical but implemented by syntactic variants Type 4
- 33. 33 public class FormattableFlags{ // Explicit instantiation of this class is prohibited. private FormattableFlags() {} /** Left-justifies the output. */ public static final int LEFT_JUSTIFY = 1<<0; // '-' /** Converts the output to upper case */ public static final int UPPERCASE = 1<<1; // 'S' /**Requires the output to use an alternate form. */ public static final int ALTERNATE = 1<<2; // '#' }
- 34. 34 public class Dollar{ public static final String symbol = “$”; }
- 35. 35 Unnecessary abstraction The smelloccurs when an abstraction gets introduced in a software design which is actually not needed and thus could have been avoided.
- 36.
- 37. 37 The principle ofencapsulation
- 38. 38 Enabling techniques forencapsulation
- 39.
- 40.
- 41. 41 Leaky encapsulation This smellarises when an abstraction “exposes” or “leaks” implementation details through its public interface.
- 42.
- 43.
- 44.
- 45. 45 Missing encapsulation This smelloccurs when the encapsulation of implementation variations in a type or hierarchy is missing.
- 46.
- 47.
- 48.
- 49. 49 The principle ofmodularization
- 50. 50 Enabling techniques formodularization
- 51.
- 52.
- 53. 53 Insufficient modularization This smellarises when an existing abstraction could be further decomposed thereby reducing its interface size, implementation complexity or both. Two variants: a) When an abstraction has a large number of members in its interface, its implementation, or both b) When an abstraction has one or more methods with excessive complexity
- 54. 54 Insufficient modularization –Example The abstract class java.awt.Component is an example of insufficient modularization It is a massive class with 332 methods (of which 259 are public!) 11 nested/inner classes 107 fields (including constants) source file spans 10,102 lines of code! The Component serves as a base class and the hierarchy is deep Derived classes inherit the members => life is quite difficult!
- 55.
- 56.
- 57.
- 58. 58 Cyclically-dependent modularization This smellarises when two or more class-level abstractions depend on each other directly or indirectly (creating a tight coupling among the abstractions). (This smell is commonly known as “cyclic dependencies”)
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66. 66 The principle ofhierarchy
- 67. 67 Enabling techniques forhierarchy
- 68.
- 69.
- 70. 70 Unfactored hierarchy This smellarises when the types in a hierarchy share unnecessary duplication in the hierarchy. Two forms of this smell: • Duplication in sibling types • Duplication in super and subtypes
- 71. 71 A refactoring formissing intermediate types
- 72. 72 Refactoring for unfactoredhierarchy
- 73. 73 Refactoring for unfactoredhierarchy
- 74.
- 75.
- 76.
- 77. 77 Broken hierarchy This smellarises when the base abstraction and its derived abstraction(s) conceptually do not share “IS-A” relationship (resulting in broken substitutability). This design smell arises when inheritance is used wrongly instead of using composition.
- 78. 78 LSP It should bepossible to replace objects of supertype with objects of subtypes without altering the desired behavior of the program
- 79.
- 80.
- 81.
- 82.
- 83. 83 Unnecessary hierarchy This smellarises when an inheritance hierarchy has one or more unnecessary abstractions. Includes the following cases: • all the subtypes are unnecessary (i.e., inappropriate use of inheritance) • supertype has only one subtype (i.e., speculative generalization) • intermediate types are unnecessary
- 84.
- 85.
- 86.
- 87. 87 Summary till now AbstractionSmells Incomplete Abstraction Duplicate Abstraction Unnecessary Abstraction Encapsulation Smells Leaky Encapsulation Missing Encapsulation Modularization Smells Insufficient Modularization Cyclically-dependent Modularization Hierarchy Smells Unfactored Hierarchy Broken Hierarchy Unnecessary Hierarchy
- 88. 88 Outline Introduction – DesignQuality, Technical Debt, and Design Smells Design Smells Catalog – Examples and corresponding Refactoring The Smell Ecosystem and Repaying Technical Debt in Practice
- 89.
- 90. 90 Role of contextin smells and refactoring Could it be Duplicate Abstraction, Unfactored Hierarchy, or Unnecessary Abstraction smell?
- 91. 91 Interplay of Smells:Co-occurring smells
- 92. 92 Interplay of Smells:Amplification Insufficient Modularization smell due to Component class amplify the impact of deep hierarchy negatively.
- 93. 93 Interplay of Smells:Deeper problems
- 94. 94 How to improvedesign quality in practice?
- 95.
- 96. 96 What were yourkey takeaways?
- 97. 97 Our upcoming bookon this topic!
- 98.
- 99.
- 100. 100 Ganesh Samarthyam sgganesh@gmail.com Twitter@GSamarthyam Girish Suryanarayana girish.suryanarayana@gmail.com Twitter@girish_sur TusharSharma tusharsharma@ieee.org Twitter@Sharma__Tushar