Applying Design Principles in Practice - ISEC 2015 Tutorial

Applying Design
Principles in Practice
Tushar Sharma
Ganesh Samarthyam
Girish Suryanarayana

Agenda
• Introduction
• Applying abstraction
• Applying encapsulation
• Applying modularisation
• Applying hierarchy
• Practical considerations
• Wrap-up

Why care about design quality and
design principles?

Poor software quality costs
more than $150 billion per year
in U.S. and greater than $500
billion per year worldwide
- Capers Jones

The city metaphor
Source: http://indiatransportportal.com/wp-content/uploads/2012/04/Trafﬁc-congestion1.jpg

“Applying design principles is the key to creating
high-quality software!”
Architectural principles:
Axis, symmetry, rhythm, datum, hierarchy, transformation

What do we mean by “principles”?
“Design principles are key notions considered
fundamental to many different software design
approaches and concepts.”
- SWEBOK ‘04

"The critical design tool for software development
is a mind well educated in design principles"
- Craig Larman

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&modiﬁca8on&
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&clientGspeciﬁc&interfaces&are&beHer&than&one&
generalGpurpose&interface&
Interface'Segrega<on'
Principle'(ISP)'

3 principles behind patterns
Program to an interface, not to an
implementation
Favor object composition over inheritance
Encapsulate what varies

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

How to apply principles in practice?
Abstraction Encapsulation Modularization Hierarchy
Code
How to bridge
the gap?

Real scenario #1
Initial design

Real scenario #1
❖ How will you refactor such
that:
❖ A speciﬁc 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

Time to refactor!
Three strikes and you
refactor
Martin Fowler

Potential solution #1?
Broken
hierarchy!

Potential solution #2?
Algorithms not
reusable!

You’re right: Its Strategy pattern!

Real scenario #2
Initial design

Real scenario #2
How to add support for new
content types and/or algorithms?

Can you identify the pattern structure?

You’re right: Its Bridge pattern structure!

Wait, what principle did we apply?

Open Closed Principle (OCP)
Bertrand Meyer
Software entities should be open for
extension, but closed for modiﬁcation

Variation Encapsulation Principle (VEP)
Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
Encapsulate the concept that varies

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

Enabling techniques for encapsulation

Design principles and enabling techniques

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

Applying principles in practice
Encapsulation
Violating
encapsulation
Adherence to
encapsulation
Enabling
technique:
Hide
variations

Applying principles in practice
Principle
Violating
principles
Adherence to
principles
Refactoring
Bad design
(with smells)
Good design
(with patterns)

Design determines qualities
Understandability Changeability Extensibility
Reusability Testability Reliability
DESIGN
impacts
impacts
impacts

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!

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

Refactoring for this smell
//'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''
//'other'methods'elided''
}'
''''''''''''public'StackTraceElement[]'getStackTrace();'//'Since'1.4'
'''''''''''''//'other'methods'elided''
}'
public'ﬁnal'class'StackTraceElement'{'
public'String'getFileName();'
public'int'getLineNumber();'
public'String'getClassName();'
public'String'getMethodName();'
public'boolean'isNativeMethod();'
}'

Applying abstraction principle
Provide a crisp conceptual
boundary and a unique identity

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;    // '#'
}

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
}

Applying abstraction principle
Assign single and meaningful
responsibility

Enabling techniques for abstraction

Applying Design Principles in Practice - ISEC 2015 Tutorial

Applying encapsulation principle
Hide implementation details

Scenario
Initial design
TextView
+ Draw()
BorderedTextView
+ Draw()
+ DrawBorder()

Real scenario
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

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

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

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()

At runtime (object diagram)

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()

You’re right: Its Decorator pattern!

Decorator pattern: Discussion
❖ Want to add responsibilities to
individual objects (not an
entire class)
❖ One way is to use inheritance
❖ Inﬂexible; static choice
❖ Hard to add and remove
responsibilities dynamically
Attach additional responsibilities to an object dynamically. Decorators
provide a ﬂexible 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

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);

Scenario
a) How do we treat ﬁles
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
- ﬁles[]: File
- folders[]: Folder

How about this solution?
FileItem
+ GetName()
+ GetSize()
+ Add(FileItem)
+ Remove(FileItem)
Folder
+ GetFiles()
+ …
File
- ﬁles: FileItem
+ GetType()
+ GetContents()
+ …
- type: FileType
- data: char[]
Shortcut
+ GetLinkedFileItem()
+ …
- linkToFile: FileItem

Composite pattern

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

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.

Applying encapsulation principle
Hide variations

Applying modularisation principle
Localize related data and
methods

Suggested refactoring for this smell

Applying modularisation principle
Create acyclic dependencies

Enabling techniques for modularisation

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 …

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();
}

Applying hierarchy principle
Apply meaningful
classiﬁcation

Applying hierarchy principle
Ensure proper ordering

Enabling techniques for hierarchy

How to repay technical debt in practice?

Useful tools during Refactoring

Comprehension Tools
STAN
http://stan4j.com

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

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

Critique, code-clone detectors, and metric tools
Infusion
www.intooitus.com/products/infusion

Designite
www.designite-tools.com

PMD Copy Paste Detector (CPD)
http://pmd.sourceforge.net/pmd-4.3.0/cpd.html

Understand
https://scitools.com

Technical Debt quantification/visualization tools
Sonarqube
http://www.sonarqube.org

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

Principles and enabling techniques

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

Applying Design Principles in Practice - ISEC 2015 Tutorial

Recommended

More Related Content

Viewers also liked (6)

Similar to Applying Design Principles in Practice - ISEC 2015 Tutorial (20)

More from Ganesh Samarthyam (20)

Recently uploaded (20)

Applying Design Principles in Practice - ISEC 2015 Tutorial