Applying Design Principles in Practice
•
11 likes•9,090 views
The tutorial titled "Applying design principles in practice" was presented in ISEC (India Software Engg Conference) on 18th Feb 2015 in Bengaluru by Tushar Sharma, Ganesh Samarthyam, and Girish Suryanarayana.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to Applying Design Principles in Practice
Similar to Applying Design Principles in Practice (20)
More from Tushar Sharma
More from Tushar Sharma (13)
Recently uploaded
Recently uploaded (20)
Applying Design Principles in Practice
- 1. Applying Design Principles in Practice Tushar Sharma Ganesh Samarthyam Girish Suryanarayana
- 2. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 3. Why care about design quality and design principles?
- 4. Poor software quality costs more than $150 billion per year in U.S. and greater than $500 billion per year worldwide - Capers Jones
- 5. The city metaphor Source: http://indiatransportportal.com/wp-content/uploads/2012/04/Traffic-congestion1.jpg
- 6. “Applying design principles is the key to creating high-quality software!” Architectural principles: Axis, symmetry, rhythm, datum, hierarchy, transformation
- 7. What do we mean by “principles”? “Design principles are key notions considered fundamental to many different software design approaches and concepts.” - SWEBOK ‘04
- 8. "The critical design tool for software development is a mind well educated in design principles" - Craig Larman
- 10. SOLID principles • There&should&never&be&more&than&one&reason&for&a&class&to& change&& Single'Responsibility' Principle'(SRP)' • So6ware&en88es&(classes,&modules,&func8ons,&etc.)&should& be&open&for&extension,&but&closed&for&modifica8on& Open'Closed'Principle' (OCP)' • Pointers&or&references&to&base&classes&must&be&able&to&use& objects&of&derived&classes&without&knowing&it& Liskov’s'Subs<tu<on' Principle'(LSP)' • Depend&on&abstrac8ons,¬&on&concre8ons& Dependency'Inversion' Principle'(DIP)' • Many&clientGspecific&interfaces&are&beHer&than&one& generalGpurpose&interface& Interface'Segrega<on' Principle'(ISP)'
- 11. 3 principles behind patterns Program to an interface, not to an implementation Favor object composition over inheritance Encapsulate what varies
- 13. How to apply principles in practice? Abstraction Encapsulation Modularization Hierarchy Code How to bridge the gap?
- 14. Real scenario #1 Initial design
- 15. Real scenario #1 ❖ How will you refactor such that: ❖ A specific DES, AES, TDES, … can be “plugged” at runtime? ❖ Reuse these algorithms in new contexts? ❖ Easily add support for new algorithms in Encryption? Next change: smelly design
- 16. Time to refactor! Three strikes and you refactor Martin Fowler
- 18. Potential solution #2? Algorithms not reusable!
- 20. Can you identify the pattern?
- 21. You’re right: Its Strategy pattern!
- 22. Real scenario #2 Initial design
- 23. Real scenario #2 How to add support for new content types and/or algorithms?
- 24. How about this solution?
- 25. Can you identify the pattern structure?
- 26. You’re right: Its Bridge pattern structure!
- 27. Wait, what principle did we apply?
- 28. Open Closed Principle (OCP) Bertrand Meyer Software entities should be open for extension, but closed for modification
- 29. Variation Encapsulation Principle (VEP) Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides Encapsulate the concept that varies
- 30. Fundamental principle: Encapsulation The principle of encapsulation advocates separation of concerns and information hiding through techniques such as hiding implementation details of abstractions and hiding variations
- 31. Enabling techniques for encapsulation
- 32. Design principles and enabling techniques
- 33. What is refactoring? Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior
- 34. Applying principles in practice Encapsulation Violating encapsulation Adherence to encapsulation Enabling technique: Hide variations
- 35. Applying principles in practice Principle Violating principles Adherence to principles Refactoring Bad design (with smells) Good design (with patterns)
- 36. Design determines qualities Understandability Changeability Extensibility Reusability Testability Reliability DESIGN impacts impacts impacts
- 37. Smells approach to learn principles A"good"designer"is" one"who"knows"the" design"solu1ons" A"GREAT"designer"is" one"who"understands" the"impact"of"design" smells"and"knows" how"to"address"them!
- 38. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 41. Refactoring for this smell public'class'Throwable'{' //'following'method'is'available'from'Java'1.0'version.'' //'Prints'the'stack'trace'as'a'string'to'standard'output'' //'for'processing'a'stack'trace,'' //'we'need'to'write'regular'expressions'' public'void'printStackTrace();'''''' //'other'methods'elided'' }' public'class'Throwable'{' public'void'printStackTrace();'''''' ''''''''''''public'StackTraceElement[]'getStackTrace();'//'Since'1.4' '''''''''''''//'other'methods'elided'' }' public'final'class'StackTraceElement'{' public'String'getFileName();' public'int'getLineNumber();' public'String'getClassName();' public'String'getMethodName();' public'boolean'isNativeMethod();' }'
- 42. Applying abstraction principle Provide a crisp conceptual boundary and a unique identity
- 43. 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; // '#' }
- 44. class Currency { public static String DOLLAR = "u0024"; public static String EURO = "u20AC"; public static String RUPEE = "u20B9"; public static String YEN = "u00A5"; // no other members in this class }
- 45. Applying abstraction principle Assign single and meaningful responsibility
- 46. Enabling techniques for abstraction
- 47. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 51. Refactoring for that smell
- 52. Applying encapsulation principle Hide implementation details
- 53. Scenario Initial design TextView + Draw() BorderedTextView + Draw() + DrawBorder()
- 54. Real scenario Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
- 55. Supporting new requirements Revised design with new requirements TextView + Draw() BorderedTextView + Draw() + DrawBorder() ScrollableTextView ScrollableBordered TextView - borderWidth + Draw() + ScrollTo() - ScrollPosition + Draw() + ScrollTo() + DrawBorder() - ScrollPosition - borderWidth
- 56. Real scenario ❖ How will you refactor such that: ❖ You don't have to “multiply- out” sub-types? (i.e., avoid “explosion of classes”) ❖ Add or remove responsibilities (e.g., scrolling) at runtime? Next change: smelly design
- 57. How about this solution? VisualComponent + Draw() TextView + Draw() ScrollDecortor BorderDecorator + Draw() + ScrollTo() - ScrollPosition + Draw() + DrawBorder() - borderWidth Decorator + Draw() component->Draw() Decorator::Draw() DrawBorder() Decorator::Draw() ScrollTo() Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
- 58. At runtime (object diagram) Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
- 59. Can you identify the pattern? VisualComponent + Draw() TextView + Draw() ScrollDecortor BorderDecorator + Draw() + ScrollTo() - ScrollPosition + Draw() + DrawBorder() - borderWidth Decorator + Draw() component->Draw() Decorator::Draw() DrawBorder() Decorator::Draw() ScrollTo() Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
- 60. You’re right: Its Decorator pattern! Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
- 61. Decorator pattern: Discussion ❖ Want to add responsibilities to individual objects (not an entire class) ❖ One way is to use inheritance ❖ Inflexible; static choice ❖ Hard to add and remove responsibilities dynamically Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality ❖ Add responsibilities through decoration ❖ in a way transparent to the clients ❖ Decorator forwards the requests to the contained component to perform additional actions ❖ Can nest recursively ❖ Can add an unlimited number of responsibilities dynamically
- 62. Identify pattern used in this code LineNumberReader lnr = new LineNumberReader( new BufferedReader( new FileReader(“./test.c"))); String str = null; while((str = lnr.readLine()) != null) System.out.println(lnr.getLineNumber() + ": " + str);
- 63. Decorator pattern in Reader
- 64. Scenario a) How do we treat files and folders alike? b) How can we handle shortcuts? File + GetName() + GetSize() + … - name: String - size: int - type: FileType - data: char[] - … Folder + GetName() + GetFiles() + GetFolders() + … - name: String - files[]: File - folders[]: Folder
- 65. How about this solution? FileItem + GetName() + GetSize() + Add(FileItem) + Remove(FileItem) Folder + GetFiles() + … File - files: FileItem + GetType() + GetContents() + … - type: FileType - data: char[] Shortcut + GetLinkedFileItem() + … - linkToFile: FileItem
- 66. Composite pattern Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
- 67. Composite pattern: Discussion ❖ There are many situations where a group of components form larger components ❖ Simplistic approach: Make container component contain primitive ones ❖ Problem: Code has to treat container and primitive components differently Compose objects into tree structures to represent part-whole hierarchies. Composite lets client treat individual objects and compositions of objects uniformly. ❖ Perform recursive composition of components ❖ Clients don’t have to treat container and primitive components differently
- 68. Decorator vs. Composite Decorator and composite structure looks similar: Decorator is a degenerate form of Composite! Decorator Composite At max. one component Can have many components Adds responsibilities Aggregates objects Does not make sense to have methods such as Add(), Remove(), GetChid() etc. Has methods such as Add(), Remove(), GetChild(), etc.
- 69. Applying encapsulation principle Hide variations
- 70. Enabling techniques for encapsulation
- 71. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 74. Refactoring for this smell
- 75. Applying modularisation principle Localize related data and methods
- 77. Suggested refactoring for this smell
- 78. Applying modularisation principle Create acyclic dependencies
- 79. Enabling techniques for modularisation
- 80. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 82. public Insets getBorderInsets(Component c, Insets insets){ Insets margin = null; // Ideally we'd have an interface defined for classes which // support margins (to avoid this hackery), but we've // decided against it for simplicity // if (c instanceof AbstractButton) { margin = ((AbstractButton)c).getMargin(); } else if (c instanceof JToolBar) { margin = ((JToolBar)c).getMargin(); } else if (c instanceof JTextComponent) { margin = ((JTextComponent)c).getMargin(); } // rest of the code elided …
- 83. Suggested refactoring for this smell
- 84. Suggested refactoring for the code margin = c.getMargin(); if (c instanceof AbstractButton) { margin = ((AbstractButton)c).getMargin(); } else if (c instanceof JToolBar) { margin = ((JToolBar)c).getMargin(); } else if (c instanceof JTextComponent) { margin = ((JTextComponent)c).getMargin(); }
- 85. Applying hierarchy principle Apply meaningful classification
- 87. Suggested refactoring for this smell
- 88. A real-world case study
- 89. Applying hierarchy principle Ensure proper ordering
- 90. Enabling techniques for hierarchy
- 91. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 92. How to repay technical debt in practice?
- 94. Useful tools during Refactoring
- 98. Critique, code-clone detectors, and metric tools Infusion www.intooitus.com/products/infusion
- 99. Critique, code-clone detectors, and metric tools Designite www.designite-tools.com
- 100. Critique, code-clone detectors, and metric tools PMD Copy Paste Detector (CPD) http://pmd.sourceforge.net/pmd-4.3.0/cpd.html
- 101. Critique, code-clone detectors, and metric tools Understand https://scitools.com
- 102. Technical Debt quantification/visualization tools Sonarqube http://www.sonarqube.org
- 104. Agenda • Introduction • Applying abstraction • Applying encapsulation • Applying modularisation • Applying hierarchy • Practical considerations • Wrap-up
- 106. Principles and enabling techniques
- 107. “Applying design principles is the key to creating high-quality software!” Architectural principles: Axis, symmetry, rhythm, datum, hierarchy, transformation