Design patterns and Refactoring

Design patterns and Refactoring

• 1.
  Design Patterns and Refactoring Courseof Software Engineering II A.A. 2010/2011 Valerio Maggio, PhD Student Prof. Sergio Di Martino
• 2.
  2 Starting Scenario ► “Wehave 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: ExtendControllers ► 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: ClientAssociation ► 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: RequirementExtension ► 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 returncopy 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