design patterns through refactoring
TRANSCRIPT
![Page 2: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/2.jpg)
“Applying design principles is the key to creating high-quality software!”
Architectural principles: Axis, symmetry, rhythm, datum, hierarchy, transformation
![Page 3: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/3.jpg)
Technology changes fast => FOMO
![Page 4: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/4.jpg)
For architects: design is the key!
![Page 5: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/5.jpg)
Agenda• Introduction
• Design patterns though exercises
• Patterns through a case-study
• Wrap-up & key-takeaways
![Page 6: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/6.jpg)
What are design patterns?
recurrent solutions to common design problems
Pattern Name Problem Solution Consequences
![Page 7: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/7.jpg)
Why care about patterns?❖ Patterns capture expert
knowledge in the form of proven reusable solutions ❖ Better to reuse proven
solutions than to “re-invent” the wheel
❖ When used correctly, patterns positively influence software quality ❖ Creates maintainable,
extensible, and reusable code
![Page 8: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/8.jpg)
Design pattern catalog
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 9: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/9.jpg)
Design pattern catalog
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
Creational Deals with controlled object creation
Factory method, for example
StructuralDeals with
composition of classes or objects
Composite, for example
Behavioral
Deals with interaction between objects/
classes and distribution of responsibility
Strategy, for example
![Page 10: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/10.jpg)
5 minutes intro to notation
![Page 11: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/11.jpg)
An example
Source: “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014
![Page 12: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/12.jpg)
3 principles behind patterns
Program to an interface, not to an implementation
Favor object composition over inheritance
Encapsulate what varies
![Page 13: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/13.jpg)
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
![Page 14: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/14.jpg)
Cover key patterns through examples
It is not about the number of patterns you know, but how well you understand “why, when, where, and how” to
apply them effectively
![Page 15: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/15.jpg)
Smells approach to learn patterns
![Page 16: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/16.jpg)
Agenda• Introduction
• Design patterns though exercises
• Patterns through a case-study
• Wrap-up & key-takeaways
![Page 17: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/17.jpg)
Scenario
enum ColorScheme { RGB, HSB, HLS, CMYK } class Color {
private float red, green, blue; // for supporting RGB scheme private float hue1, saturation1, brightness1; // for supporting HSB scheme private float hue2, lightness2, saturation2; // for supporting HLS schemepublic Color(float arg1, float arg2, float arg3, ColorScheme cs) {
switch (cs) {// initialize arg1, arg2, and arg3 based on ColorScheme value
}}
}
• Assume that you need to support different Color schemes in your software• RGB (Red, Green, Blue), HSB (Hue, Saturation, Brightness), and HLS (Hue,
Lightness, and Saturation) schemes• Overloading constructors and differentiating them using enums can become
confusing • What could be a better design?
![Page 18: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/18.jpg)
A solution using factory method pattern
Color
+ GetRGBColor()+ GetHSBColor()+ GetHLSColor()
RGBColor
- red : float- green : float - blue : float
HSBColor
- hue : float- saturation : float - brightness : float
HLSColor
- hue : float- lightness : float - saturation : float
![Page 19: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/19.jpg)
A solution using factory method pattern
Color
+ GetColor(ColorType)+ …
RGBColor
- red : float- green : float - blue : float
HSBColor
- hue : float- saturation : float - brightness : float
HLSColor
- hue : float- lightness : float - saturation : float
![Page 20: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/20.jpg)
Factory method pattern: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 21: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/21.jpg)
Factory method pattern: Discussion
❖ A class cannot anticipate the class of objects it must create
❖ A class wants its subclasses to specify the objects it creates
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.
❖ Delegate the responsibility to one of the several helper subclasses
❖ Also, localize the knowledge of which subclass is the delegate
![Page 22: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/22.jpg)
Factory method: Java library example
Logger logger = Logger.getLogger(TestFileLogger.class.getName());
![Page 23: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/23.jpg)
Factory method: Java library example
class SimpleThreadFactory implements ThreadFactory { public Thread newThread(Runnable r) { return new Thread(r); }}
![Page 24: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/24.jpg)
Scenario
public Locale (String language, // e.g. “en" for English String script, // e.g., “Arab” for Arabic
String country, // e.g., “us” for United States String variant, // e.g., “TH” for Thai LocaleExtensions extensions) // e.g., “ca-buddhist” for Thai Buddhist Calendar
• Assume that you have a Locale class constructor that takes many “optional constructors”
• Constraint: Only certain variants are allowed - you need to “disallow” inappropriate combinations(e.g., invalid combination of country and variant) by throwing IllformedLocaleException.
• Overloading constructors will result in “too many constructors” • How will you design a solution for this?
![Page 25: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/25.jpg)
Recommended solution
Locale aLocale = new Locale.Builder().setLanguage(“sr").setScript(“Latn").setRegion("RS").build();
• Create a Locale Builder that “builds” and returns an object step-by-step• Validation will be performed by the individual set methods • The build() method will return the “built” object
![Page 26: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/26.jpg)
Builder pattern: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 27: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/27.jpg)
Builder pattern: Discussion
❖ Creating or assembling a complex object can be tedious
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
❖ Make the algorithm for creating a complex object independent of parts that make up the object and how they are assembled
❖ The construction process allows different representations for the object that is constructed
![Page 28: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/28.jpg)
Builders common for complex classes
Calendar.Builder b = new Calendar.Builder(); Calendar calendar = b
.set(YEAR, 2003)
.set(MONTH, APRIL)
.set(DATE, 6)
.set(HOUR, 15)
.set(MINUTE, 45)
.set(SECOND, 22)
.setTimeZone(TimeZone.getDefault())
.build();System.out.println(calendar);
![Page 29: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/29.jpg)
Scenario
❖ Consider a Route class in an application like Google Maps
❖ For finding shortest path from source to destination, many algorithms can be used
❖ The problem is that these algorithms get embedded into Route class and cannot be reused easily (smell!)
Route
+ SetRoute(Location, Location)+ FindShortestPathJohnson() + FindShortestDijkstra()+ FindShortestBellmanFord()+ …
How will you refactor such thata) Support for shortest path algorithm can be added easily? b) Separate path finding logic from dealing with location information.
![Page 30: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/30.jpg)
How about this solution?
ShortestPathAlgos
+ FindPath()
JohnsonsAlgo DijkstrasAlgo
Route
+ SetRoute(Location, Location)
+ ShortestPath()+ …
![Page 31: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/31.jpg)
You’re right: Its Strategy pattern!
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 32: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/32.jpg)
Strategy pattern: Discussion
❖ Useful when there is a set of related algorithms and a client object needs to be able to dynamically pick and choose an algorithm that suits its current need
Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary
independently from clients that use it
❖ The implementation of each of the algorithms is kept in a separate class referred to as a strategy.
❖ An object that uses a Strategy object is referred to as a context object.
❖ Changing the behavior of a Context object is a matter of changing its Strategy object to the one that implements the required algorithm
![Page 33: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/33.jpg)
Wait, what principle did we apply?
![Page 34: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/34.jpg)
Open Closed Principle (OCP)
Bertrand Meyer
Software entities should be open for extension, but closed for modification
![Page 35: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/35.jpg)
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)'
![Page 36: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/36.jpg)
Variation Encapsulation Principle (VEP)
Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
Encapsulate the concept that varies
![Page 37: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/37.jpg)
Fundamental principle: Encapsulation
The principle of encapsulation advocates separation of concerns andinformation hiding through techniques such as hiding implementation
details of abstractions and hiding variations
![Page 38: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/38.jpg)
What do you mean by “principle”?
“Design principles are key notions considered fundamental to many different software design approaches and concepts. They are also called
enabling techniques.” - SWEBOK ‘04
![Page 39: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/39.jpg)
Design determines qualities
Understandability Changeability Extensibility
Reusability Testability Reliability
DESIGNimpacts
impactsimpacts
![Page 40: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/40.jpg)
Scenario
Report
+ Open()+ Populate()+ Print()+ Save()
SummaryHTMLReport SummaryRichReport DetailedHTMLReport DetailedRichReport
![Page 41: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/41.jpg)
How about this solution?
FileFormat
+ Save()
HTMLReport RichReport
Report
+ Open()+ Save(ReportType)+ …
SummaryReport DetailedReport
![Page 42: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/42.jpg)
You’re right: Its Bridge pattern!
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 43: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/43.jpg)
An example of Bridge pattern
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 44: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/44.jpg)
Bridge pattern: Discussion
❖ An abstraction can be designed as an interface with one or more concrete implementers.
❖ When subclassing the hierarchy, it could lead to an exponential number of subclasses.
❖ And since both the interface and its implementation are closely tied together, they cannot be independently varied without affecting each other
Decouples an abstraction from its implementation so that the two can vary independently
❖ Put both the interfaces and the implementations into separate class hierarchies.
❖ The Abstraction maintains an object reference of the Implementer type.
❖ A client application can choose a desired abstraction type from the Abstraction class hierarchy.
❖ The abstraction object can then be configured with an instance of an appropriate implementer from the Implementer class hierarchy
![Page 45: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/45.jpg)
ScenarioInitial design
TextView
+ Draw()
BorderedTextView
+ Draw()+ DrawBorder()
![Page 46: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/46.jpg)
Scenario
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 47: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/47.jpg)
Supporting new requirementsRevised design with new requirements
TextView
+ Draw()
BorderedTextView
+ Draw()+ DrawBorder()
ScrollableTextView ScrollableBorderedTextView
- borderWidth
+ Draw()+ ScrollTo()
- ScrollPosition
+ Draw()+ ScrollTo()+ DrawBorder()
- ScrollPosition- borderWidth
![Page 48: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/48.jpg)
Scenario
❖ How will you refactor such that:
❖ You don't have to “multiply-out” sub-types? (i.e., avoid “explosion of classes”)
❖ You can add or remove responsibilities (e.g., scrolling)?
Next change: smelly design
![Page 49: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/49.jpg)
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
![Page 50: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/50.jpg)
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
![Page 51: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/51.jpg)
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
![Page 52: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/52.jpg)
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
![Page 53: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/53.jpg)
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
![Page 54: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/54.jpg)
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);
![Page 55: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/55.jpg)
Decorator pattern in Reader
![Page 56: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/56.jpg)
Decorator pattern extensively used in library designs
![Page 57: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/57.jpg)
Scenarioa) 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
![Page 58: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/58.jpg)
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
![Page 59: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/59.jpg)
Composite pattern
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 60: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/60.jpg)
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
![Page 61: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/61.jpg)
Decorator vs. CompositeDecorator 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.
![Page 62: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/62.jpg)
Composite pattern extensively used in library designs
![Page 63: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/63.jpg)
ScenarioHow to separate:a) code generation logic
from node types?b) how to support different
target types?
class Plus extends Expr { private Expr left, right; public Plus(Expr arg1, Expr arg2) { left = arg1; right = arg2; } public void genCode() { left.genCode(); right.genCode(); if(t == Target.JVM) { System.out.println("iadd"); } else { // DOTNET System.out.println("add"); } }}
![Page 64: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/64.jpg)
Group exercise - Understanding visitor pattern
![Page 65: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/65.jpg)
A solution using Visitor patternclass Plus extends Expr { private Expr left, right; public Plus(Expr arg1, Expr arg2) { left = arg1; right = arg2; } public Expr getLeft() { return left; } public Expr getRight() { return right; } public void accept(Visitor v) { v.visit(this); }}
class DOTNETVisitor extends Visitor { public void visit(Constant arg) { System.out.println("ldarg " + arg.getVal()); } public void visit(Plus plus) { genCode(plus.getLeft()); genCode(plus.getRight()); System.out.println("add"); } public void visit(Sub sub) { genCode(sub.getLeft()); genCode(sub.getRight()); System.out.println("sub"); } public void genCode(Expr expr) { expr.accept(this); }}
![Page 66: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/66.jpg)
Visitor pattern: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 67: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/67.jpg)
Visitor pattern: Call sequence
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 68: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/68.jpg)
Visitor pattern: Discussion
❖ Many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid “polluting” their classes with these operations
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the
elements on which it operations
❖ Create two class hierarchies:
❖ One for the elements being operated on
❖ One for the visitors that define operations on the elements
![Page 69: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/69.jpg)
Many other patterns other than GoF
Source: “Refactoring to Patterns”, Joshua Kerievsky, Addison Wesley, 2004
![Page 70: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/70.jpg)
Null Object pattern
Source: “Refactoring to Patterns”, Joshua Kerievsky, Addison Wesley, 2004
![Page 71: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/71.jpg)
EmptySet from Java libraryprivate static class EmptySet<E> extends AbstractSet<E> implements Serializable { private static final long serialVersionUID = 1582296315990362920L;
public Iterator<E> iterator() { return emptyIterator(); }
public int size() {return 0;} public boolean isEmpty() {return true;}
public boolean contains(Object obj) {return false;} public boolean containsAll(Collection<?> c) { return c.isEmpty(); }
public Object[] toArray() { return new Object[0]; }
public <T> T[] toArray(T[] a) { if (a.length > 0) a[0] = null; return a; }
// Preserves singleton property private Object readResolve() { return EMPTY_SET; } }
![Page 72: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/72.jpg)
Agenda• Introduction
• Design patterns though exercises
• Patterns through a case-study
• Tools for refactoring
• Wrap-up & key-takeaways
![Page 73: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/73.jpg)
Designing a document editor• How to maintain a document structure?
• How to support formatting?
• How to support embellishments (highlighting, marking, etc) with ease?
• Support multiple look-and-feel standards
• Support multiple windowing systems (mac, windows, motif, etc)
• How to support user operations and handle user events?
• How to support spellchecking and hyphenation?
• ….
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 74: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/74.jpg)
“Recursive composition”
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 75: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/75.jpg)
Solution using Composite pattern
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 76: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/76.jpg)
More “recursive composition”
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 77: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/77.jpg)
“Recursive composition” - class design
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 78: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/78.jpg)
Supporting bordering, scrolling, …
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 79: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/79.jpg)
Supporting multiple look-and-feel
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 80: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/80.jpg)
Abstract factory: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 81: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/81.jpg)
Supporting multiple look-and-feel
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 82: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/82.jpg)
Separating implementation dependencies
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 83: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/83.jpg)
Supporting user operations
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 84: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/84.jpg)
Supporting user operations
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 85: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/85.jpg)
Command pattern: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 86: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/86.jpg)
Supporting undo/redo: Command history
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 87: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/87.jpg)
Traversing document (e.g., spell check)
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 88: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/88.jpg)
Iterator pattern: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 89: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/89.jpg)
Iterator pattern: Another example
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994
![Page 90: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/90.jpg)
Patterns discussed in this case-study
✓ Composite pattern
✓ Decorator pattern
✓ Abstract factory pattern
✓ Bridge pattern
✓ Command pattern
✓ Iterator pattern
![Page 91: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/91.jpg)
Agenda• Introduction
• Design patterns though exercises
• Patterns through a case-study
• Wrap-up & key-takeaways
![Page 92: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/92.jpg)
Exercise: Create a suitable designNote:&Responsibility&of&
rendering&the&line&in&chosen&style&is&with&underlying&OS&/&
pla;orm&
Source: “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014
![Page 93: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/93.jpg)
How about this solution?
Source: “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014
![Page 94: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/94.jpg)
Suggested refactoring for this smell
Source: “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014
![Page 95: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/95.jpg)
Beware of “patterns mania”!
![Page 96: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/96.jpg)
What are your takeaways?
![Page 97: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/97.jpg)
Books to read
![Page 98: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/98.jpg)
![Page 99: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/99.jpg)
![Page 100: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/100.jpg)
![Page 101: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/101.jpg)
![Page 102: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/102.jpg)
![Page 103: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/103.jpg)
“Applying design principles is the key to creating high-quality software!”
Architectural principles: Axis, symmetry, rhythm, datum, hierarchy, transformation
![Page 104: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/104.jpg)
Image/video credits❖ http://en.wikipedia.org/wiki/Fear_of_missing_out❖ http://lesliejanemoran.blogspot.in/2010_05_01_archive.html❖ http://javra.eu/wp-content/uploads/2013/07/angry_laptop2.jpg❖ https://www.youtube.com/watch?v=5R8XHrfJkeg❖ http://womenworld.org/image/052013/31/113745161.jpg❖ http://www.fantom-xp.com/wallpapers/33/I'm_not_sure.jpg❖ https://www.flickr.com/photos/31457017@N00/453784086 ❖ https://www.gradtouch.com/uploads/images/question3.jpg❖ http://gurujohn.files.wordpress.com/2008/06/bookcover0001.jpg ❖ http://upload.wikimedia.org/wikipedia/commons/d/d5/Martin_Fowler_-_Swipe_Conference_2012.jpg❖ http://www.codeproject.com/KB/architecture/csdespat_2/dpcs_br.gif ❖ http://upload.wikimedia.org/wikipedia/commons/thumb/2/28/Bertrand_Meyer_IMG_2481.jpg/440px-
Bertrand_Meyer_IMG_2481.jpg ❖ http://takeji-soft.up.n.seesaa.net/takeji-soft/image/GOF-OOPLSA-94-Color-75.jpg?d=a0 ❖ https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/OOP_ObjC/Art/watchcalls_35.gif❖ http://www.pluspack.com/files/billeder/Newsletter/25/takeaway_bag.png ❖ http://cdn1.tnwcdn.com/wp-content/blogs.dir/1/files/2013/03/design.jpg
![Page 105: Design patterns through refactoring](https://reader036.vdocuments.site/reader036/viewer/2022062320/55aaaf2c1a28ab557a8b4872/html5/thumbnails/105.jpg)