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.

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

9. Fundamental Design Principles

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,&not&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

12. Booch’s fundamental principles
Principles*
Abstrac/on*
Encapsula/on*
Modulariza/on*
Hierarchy*

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

17. Potential solution #1?
Broken
hierarchy!

18. Potential solution #2?
Algorithms not
reusable!

19. Potential solution #3?

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

39. What is abstraction?

40. 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''
}'

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

48. What is encapsulation?

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

72. What is modularization?

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

81. What is hierarchy?

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?

93. IMPACT process model

94. Useful tools during Refactoring

95. Comprehension Tools
STAN
http://stan4j.com

96. Comprehension Tools
Code City
http://www.inf.usi.ch/phd/wettel/codecity.html

97. Comprehension Tools
Imagix 4D
http://www.imagix.com

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

103. Refactoring tools
ReSharper
https://www.jetbrains.com/resharper/features/

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

108. ganesh.samarthyam@gmail.com
@GSamarthyam
tusharsharma@ieee.org
@Sharma__Tushar
girish.suryanarayana@siemens.com
@Girish_Sur
www.designsmells.com
@designsmells