Your SlideShare is downloading. ×
Design patterns and Refactoring
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Design patterns and Refactoring

468
views

Published on

Application of GoF Design Patterns and Refactoring techniques to example software design scenarios

Application of GoF Design Patterns and Refactoring techniques to example software design scenarios

Published in: Technology, Design

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
468
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Design Patterns and Refactoring Course of Software Engineering II A.A. 2010/2011 Valerio Maggio, PhD Student Prof. Sergio Di Martino
  • 2. 2 Starting Scenario ► “We have a DeviceManager that have to handle objects that is able to connect to the GPS Network” ► Objectives of current lecture: ○ Improve and complicate the starting scenario ● Through refactoring and patterns ○ Interactive Improvements ● Let's do it togheter ► As usual let's do Program Comprehension first
  • 3. 3 Step 1: Extend Controllers ► Q: We want to add a new type of Controller ○ class InternalGalileoController ► Let's look at UML: ○ What do you think about extensibility? ●Please focus on InternalGpsConnector ► A: (Refactoring) ○ Extract Interface
  • 4. 4 Step 2: Client Association ► Q: Direct association between Client and Product ○ Too much coupling ► Let's look at the code: ○ Where do you think is the “coupling point”? ► A [1]: ○ Collection of Super-Type Istances ► A [2] (design pattern) : ○ Factory Method
  • 5. 5 Factory Method Pattern ► Intent: ○ Define an interface for creating an object ●Factory Method let's a class defer instantiation to subclasses. ○ Defining a “virtual” constructor. ○ The new operator considered harmful. ► Needs to standardize the architectural model for a range of products, ○ Allow for individual applications to define their own domain objects and provide for their instantiation.
  • 6. 6 Factory Method (UML)
  • 7. 7 Step 3: Improvements ► Let's think about current design ○ Brainstorming please :) ► Q: Instantiation of Factory ○ A (Pattern): Singleton ► Q: “Virtual Constructor Methods” ○ A: Multiple methods vs Single Method
  • 8. 8 Step 4: Requirement Extension ► We want to add a new family of connectors ○ Current products: Smartphone Connectors ● Gps and Galileo connections ○ New Products: Mobile Connectors ● Bluetooth and IRDA connections ► Q: How to handle creation loosely coupled with client? ► A (Pattern): ○ Abstract Factory
  • 9. 9 Abstract Factory Pattern ► Intent: ○ Provide an interface for creating families of related or dependent objects ●Without specifying their concrete classes. ○ A hierarchy that encapsulates ●Many possible “platforms” ●Construction of a suite of “products”. ► Problem: ○ An application has to be portable ●Encapsulate platform dependencies.
  • 10. 10 Abstract Factory (UML) Client ProductA2 «interface» AbstractProductA ProductA1 ProductB2ProductB1 «interface» AbstractProductB CreateProductA() CreateProductB() «interface» AbstractFactory CreateProductA() CreateProductB() ConcreteFactory2 CreateProductA() CreateProductB() ConcreteFactory1 «import» «import» «import» «instantiate» «instantiate» «instantiate» «instantiate»
  • 11. 11 Step 4.1: Example ► Q: Change Product Family associated to Device Controller ► What is the effort? ► Minimum effort, maximum effect ○ Client loosely coupled with products ●Instantiation and handling
  • 12. 12 Step 5: Improvement ► Improvement in Product instantiation ► Extension to new product family: ○Client point of view: Easy ○Product point of view: ??? ► A (Pattern): ○Prototype
  • 13. 13 Prototype Pattern ► Intent: ○ Specify the kinds of objects to create using a prototypical instance ●create new objects by copying this prototype. ○ Co-opt one instance of a class for use as a breeder of all future instances. ► Problem: ○ Application “hard wires” the class of object to create in each “new” expression.
  • 14. 14 Prototype Pattern (UML) operation() Client clone() ConcretePrototype1 clone() ConcretePrototype2 clone() «interface» Prototype return copy of self return copy of self Object p = prototype.clone(); «import»
  • 15. 15 Rules of Thumbs ► Sometimes creational patterns are competitors ► Often, designs: ○ Start out using Factory Method ●(less complicated, more customizable, subclasses proliferate) ○ Evolve toward ●Abstract Factory ●Prototype ●Builder (more flexible, more complex) ► Don't abuse on using Design Patterns!!
  • 16. 16 References ► Gamma, E., Helm, R., Johnson, R. e Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software ► http://www.artima.com/lejava/articles/designp rinciples.html