SlideShare a Scribd company logo
DESIGN PATTERN CREAZIONALI
INGEGNERIA DEL SOFTWARE
Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica, A.A. 2014 – 2015
rcardin@math.unipd.it
Ingegneria del software mod. A
DESIGN PATTERN CREAZIONALI
2Riccardo Cardin
Architetturali
Model view controller
Ingegneria del software mod. A
INTRODUZIONE
 Scopo dei design pattern creazionali
 Rendere un sistema indipendente
dall’implementazione concreta delle sue componenti
 Si nascondono i tipi concreti delle classi realmente utilizzate
 Si nascondono i dettagli sulla composizione e creazione
 Riduzione accoppiamento e flessibilità
 Ampio uso dell’astrazione / interfacce
3Riccardo Cardin
Ingegneria del software mod. A
SINGLETON
 Scopo
 Assicurare l’esistenza di un’unica istanza di una classe
 … ed avere un punto di accesso globale a questa
 Motivazione
 Alcune entità NON DEVONO avere più di un’istanza
 Non è possibile utilizzare una variabile globale (C++)
 La classe deve tenere traccia della sua unica istanza
4Riccardo Cardin
Ingegneria del software mod. A
SINGLETON
 Applicabilità
 Deve esistere una e una sola istanza di una classe in
tutta l’applicazione
 L’istanza deve essere accessibile dai client in modo noto
 L’istanza deve essere estendibile con ereditarietà
 I client non devono modificare il proprio codice
5Riccardo Cardin
Ingegneria del software mod. A
SINGLETON
 Struttura
6Riccardo Cardin
Definisce getInstance che permette
l’accesso all’unica istanza. È responsabile
della creazione dell’unica istanza
/*
* Implementazione Java
* "naive"
*/
public class Singleton {
private static
Singleton instance;
private Singleton() {
/* Corpo vuoto */
}
public static Singleton
getInstance() {
if (instance == nul) {
instance =
new Singleton();
}
return instance;
}
}
Ingegneria del software mod. A
SINGLETON
 Conseguenze
 Controllo completo di come e quando i client
accedono all’interfaccia
 Evita il proliferare di variabili globali (C++)
 Permette la ridefinizione delle operazioni definite nel
Singleton
 Può permettere un numero massimo e preciso di
istanze attive
 Più flessibile delle operazioni di classe
 Utilizzo del polimorfismo
7Riccardo Cardin
Ingegneria del software mod. A
SINGLETON
 Esempio
8Riccardo Cardin
Esempio
Un applicativo deve istanziare un oggetto che gestisce una stampante
(printer spooler). Questo oggetto deve essere unico perché si dispone
di una sola risorsa di stampa.
Ingegneria del software mod. A
SINGLETON
 Esempio
 Printer Spooler
9Riccardo Cardin
L’appoccio non è thread safe in Java:
nessuna sincronizzazione sulla
creazione di instance
Ingegneria del software mod. A
SINGLETON
 Implementazione
 Assicurare un’unica istanza attiva (lazy initialization)
 Si rende il/i costruttore/i privato/i (non accessibili)
 Si rende disponibile un’operazione di classe di “recupero”
 Non è possibile utilizzare variabili globali (C++)
 Non garantisce l’unicità dell’istanza
 L’istanza è generata durante l’inizializzazione “statica”
 Tutti i singleton sarebbero costruiti sempre, anche se mai
utilizzati
10Riccardo Cardin
Ingegneria del software mod. A
SINGLETON
 Implementazione
 Ereditare da una classe Singleton
 È difficile installare l’unica istanza nel membro instance
 La soluzione migliore è utilizzare un registro di singleton
11Riccardo Cardin
public class Singleton {
private static Singleton instance;
private static Map<String, Singleton> registry;
private Singleton() { /* Corpo vuoto */ }
public static register(String name, Singleton)
{ /* ... */}
protected static Singleton lookup(String name)
{ /* ... */}
public static Singleton
getInstance(String singletonName) {
/* Utilizza lookup per recuperare l’istanza */
}
}
public class MySingleton
extends Singleton {
static {
Singleton.register(“MySingleton”,
new MySingleton())
}
/* ... */
}
Ingegneria del software mod. A
SINGLETON
 Implementazione
 Java  Costruttore privato (omesso per spazio)
12Riccardo Cardin
public class PrinterSpooler {
private static final PrinterSpooler INSTANCE = new PrinterSpooler();
public static PrinterSpooler getInstance() {
return INSTANCE;
}
} no lazy, thread safe, no subclassing, no serializable
public class PrinterSpooler {
private static volatile PrinterSpooler INSTANCE;
public static PrinterSpooler getInstance() {
if (INSTANCE == null) {
synchronize (PrinterSpooler.class) {
if (INSTANCE == null { INSTANCE = new PrinterSpooler(); }
}
}
return INSTANCE;
}
}
lazy, thread safe, subclassing possibile, no serializable
Soffrono di attacco per
Reflection sul costruttore
Ingegneria del software mod. A
SINGLETON
 Implementazione
 Java
 Versione accettata da JDK ≥ 1.5
 Item 3 di Effective Java di Joshua Bloch
 Usa costrutti nativi del linguaggio
 Non soffre di alcun attacco
 Conciso, leggibile e manutenibile
13Riccardo Cardin
public enum PrinterSpooler {
INSTANCE;
public void print(String file) { /* ... */ }
}
no lazy, thread safe, no subclassing, serializable
Ingegneria del software mod. A
SINGLETON
 Implementazione
 Scala
 In Java il pattern Sigleton è uno dei più utilizzati
 Mancanza a livello di linguaggio
 Error prone
 Scala risolve introducendo il tipo object
 Implementazione del pattern Singleton nel linguaggio
 Thread-safe
 Gli Object sono inizializzati su richiesta (laziness)
14Riccardo Cardin
object PrinterSpooler extends ... {
def print(file: String) {
// do something
}
}
Cons: meno
controllo
sull’inizializzazione
Ingegneria del software mod. A
SINGLETON
 Implementazione
 Javascript: si utilizza il module pattern
15Riccardo Cardin
var mySingleton = (function () {
var instance;
function init() {
// Private methods and variables
function privateMethod() { console.log( "I am private" ); };
var privateRandomNumber = Math.random();
return {
// Public methods and variables
publicMethod: function () {
console.log( "The public can see me!" );
},
getRandomNumber: function() { return privateRandomNumber; }
};
};
return {
getInstance: function () {
if ( !instance ) { instance = init(); }
return instance;
}
}; })();
Public
functions/variables
Private
namespace
Ingegneria del software mod. A
BUILDER
 Scopo
 Separa la costruzione di un oggetto complesso dalla
sua rappresentazione
 Motivazione
 Necessità di riutilizzare un medesimo algoritmo di
costruzione per più oggetti di tipo differente
 Processo di costruzione step-by-step
16Riccardo Cardin
Il cassiere deve:
1. Inserire il panino
2. Inserire le patate
3. Inserire la frutta
4. ...
Ingegneria del software mod. A
BUILDER
 Esempio
17Riccardo Cardin
Ingegneria del software mod. A
BUILDER
 Applicabilità
 La procedura di creazione di un oggetto complesso
deve essere indipendente dalle parti che
compongono l’oggetto
 Il processo di costruzione deve permettere diverse
rappresentazioni per l’oggetto da costruire
18Riccardo Cardin
Ingegneria del software mod. A
BUILDER
 Struttura
19Riccardo Cardin
Costruisce un oggetto
utilizzando il builder
(procedura)
Specifica l’interfaccia da
utilizzare per assemblare il
prodotto
Costruisce e assembla le parti del prodotto.
Tiene traccia dell’istanza costruita. Fornisce
un’interfaccia per recuperare il prodotto
finale
Il prodotto complesso
da costruire
Ingegneria del software mod. A
BUILDER
 Struttura
20Riccardo Cardin
Il client conosce il tipo
builder concreto
Il director notifica il
builder delle parti che
devono essere costruite
Il client recupera dal
builder concreto il
prodotto finito
Ingegneria del software mod. A
BUILDER
 Conseguenze
 Facilita le modifiche alla rappresentazione interna di
un prodotto
 È sufficiente costruire un nuovo builder: NO telescoping!
 Isola il codice dedicato alla costruzione di un prodotto
dalla sua rappresentazione
 Il client non conosce le componenti interne di un prodotto
 Encapsulation
 L’orchestrazione dei processi di costruzione è unica
 Consente un controllo migliore del processo di
costruzione
 Costruzione step-by-step
 Accentramento logica di validazione
21Riccardo Cardin
Ingegneria del software mod. A
BUILDER
 Esempio
22Riccardo Cardin
Si vuole ordinare un bicchiere di scotch. È necessario fornire al barman
alcune informazioni: la marca del whiskey, come deve essere preparato
(liscio, on the rocks, allungato) e se lo si desidera doppio. È inoltre
possibile scegliere il tipo di bicchiere (piccolo, lungo, a tulipano).
[se fossimo veramente intenditori, anche la marca e la temperatura
dell’acqua sarebbero fondamentali...]
Ingegneria del software mod. A
BUILDER
23Riccardo CardinIngegneria del software mod. A
Ingegneria del software mod. A
BUILDER
 Implementazione
 Il builder defisce un’interfaccia per ogni parte che il
director può richiedere di costruire
 Abbastanza generale per la costruizione di prodotti differenti
 Appending process
 Nessuna classe astratta comune per i prodotti
 Differiscono notevolmente fra loro
 Se simili, valutare l’utilizzo di un Abstract Factory Pattern
 Fornire metodi vuoti come default
 I builder concreti ridefiniscono solo i metodi necessari
24Riccardo Cardin
Ingegneria del software mod. A
BUILDER
 Implementazione
 Java: il builder diventa classe interna del prodotto
25Riccardo Cardin
public class OrderOfScotch {
private String brand;
private Praparation preparation; // Si puo’ dichiarare enum interna
// ...
private OrderOfScotch() { } // Costruttore privato per il prodotto
private OrderOfScotch(ScotchBuilder builder) {
this.brand = builder._brand;
// ...
}
public static class Builder {
private String _brand; // Inserisco '_' per diversificare
private Praparation _preparation;
// ...
public ScotchBuilder withBrand(String brand) {
this._brand = brand;
return this; // Appending behaviour
}
// CONTINUA...
Ingegneria del software mod. A
BUILDER
 Implementazione
 Java
 Item 2 di Effective Java di Joshua Bloch
26Riccardo Cardin
// CONTINUA...
public OrderOfScotch build() { return new OrderOfScotch(this); }
} // public static class Builder
public static void main(String[] args) {
// Il client non conosce il processo di costruzione e le classi
// prodotto e builder sono correttamente accoppiate tra loro.
// Non e’ possibile costruire un prodotto se non con il builder.
OrderOfScotch oos = new OrderOfScotch.Builder()
.withBrand(“Brand 1“)
.withPreparation(NEAT)
// ...
.build();
}
} // public class OrderOfScotch
Ingegneria del software mod. A
BUILDER
 Implementazione
 Javascript
27Riccardo Cardin
var Builder = function() {
var a = "defaultA"; // Valori default
var b = "defaultB";
return {
withA : function(anotherA) {
a = anotherA;
return this; // Append behaviour
},
withB : function(anotherB) {
b = anotherB;
return this;
},
build : function() {
return "A is: " + a +", B is: " + b;
}
};
};
var first = builder.withA().withB("a different value for B").build();
Approccio classico,
con l’utilizzo degli
scope per la
creazione degli
oggetti
Ingegneria del software mod. A
BUILDER
 Implementazione
 Javascript – JQuery
 Costruzione step-by-step del DOM
28Riccardo Cardin
// I metodi appendTo, attr, text permettono di costruire un oggetto
// all’interno del DOM in modo step-by-step
$( '<div class="foo">bar</div>' );
$( '<p id="test">foo <em>bar</em></p>').appendTo("body");
var newParagraph = $( "<p />" ).text( "Hello world" );
$( "<input />" )
.attr({ "type": "text", "id":"sample"})
.appendTo("#container");
Ingegneria del software mod. A
BUILDER
 Implementazione
 Scala
 In Scala è possibile utilizzare i principi dei linguaggi funzionali
 Immutabilità del builder
 Type-safe builder
 Assicura staticamente che sono state fornite tutte le
informazioni necessarie alla costruzione
 Si utilizzano feature avanzate del linguaggio
 Type constraints
 http://blog.rafaelferreira.net/2008/07/type-safe-builder-
pattern-in-scala.html
 http://www.tikalk.com/java/type-safe-builder-scala-using-
type-constraints/
29Riccardo Cardin
Ingegneria del software mod. A
ABSTRACT FACTORY
 Scopo
 Fornisce un’interfaccia per creare famiglie di prodotti
senza specificare classi concrete
 Motivazione
 Applicazione configurabile con diverse famiglie di
componenti
 Toolkit grafico
 Si definisce una classe astratta factory che definisce le
interfacce di creazione.
 I client non costruiscono direttamente i “prodotti”
 Si definiscono le interfacce degli oggetti da creare
 Le classi che concretizzano factory vengono costruite una
volta sola
30Riccardo Cardin
Ingegneria del software mod. A
ABSTRACT FACTORY
 Applicabilità
 Un sistema indipendente da come i componenti sono
creati, composti e rappresentati
 Un sistema configurabile con più famiglie prodotti
 Le componenti di una famiglia DEVONO essere
utilizzate insieme
 Si vuole fornire una libreria di classi prodotto, senza
rivelarne l’implementazione.
31Riccardo Cardin
Ingegneria del software mod. A
ABSTRACT FACTORY
 Struttura
32Riccardo Cardin
Dichiara l’interfaccia di
creazione dei prodotti
Costruiscono i
prodotti concreti
Interfaccia per
un particolare
prodotto
Definisce un prodotto
concreto, che deve
essere costruito
mediante factory
Ingegneria del software mod. A
ABSTRACT FACTORY
 Conseguenze
 Isolamento dei tipi concreti
 I client manipolano unicamente interfacce, i nomi dei
prodotti sono nascosti
 Semplicità maggiore nell’utilizzo di una diversa
famiglia di prodotti
 La factory concreta appare solo una volta nel programma
 Promuove la consistenza fra i prodotti
 Difficoltà nel supportare nuovi prodotti
 Modificare l’interfaccia della factory astratta costringe il
cambiamento di tutte le sotto classi.
33Riccardo Cardin
Ingegneria del software mod. A
ABSTRACT FACTORY
 Esempio
34Riccardo Cardin
Esempio
Si vuole realizzare un negozio di vendita di sistemi Hi-Fi, dove si
eseguono dimostrazioni dell’utilizzo dei prodotti.
Esistono due famiglie di prodotti, basate su tecnologie diverse:
- supporto di tipo nastro (tape)
- supporto di tipo digitale (CD).
Ogni famiglia è composta da:
- supporto (tape o CD)
- masterizzatore (recorder)
- riproduttore (player).
Ingegneria del software mod. A
ABSTRACT FACTORY
 Esempio
35Riccardo Cardin
Ingegneria del software mod. A
ABSTRACT FACTORY
 Esempio
 Scala: companion object (Factory Method)
 Apply è tradotto in un simil – costruttore
 Si utilizza per la costruzione delle factory concrete
36Riccardo Cardin
trait Animal
private class Dog extends Animal
private class Cat extends Animal
object Animal {
def apply(kind: String) =
kind match {
case "dog" => new Dog()
case "cat" => new Cat()
}
}
val animal = Animal("dog")
Equivale a
Animal(...)
Ingegneria del software mod. A
ABSTRACT FACTORY
 Esempio
 Javascript: varie tecniche di implementazione
37Riccardo Cardin
var AbstractVehicleFactory = (function () {
// Storage for our vehicle types
var types = {};
return {
getVehicle: function ( type, customizations ) {
var Vehicle = types[type];
return (Vehicle ? new Vehicle(customizations) : null);
},
registerVehicle: function ( type, Vehicle ) {
var proto = Vehicle.prototype;
if ( proto.drive && proto.breakDown ) {
types[type] = Vehicle;
}
return AbstractVehicleFactory;
}
};
})();
Registro solamente gli
oggetti che soddisfano
un contratto (abstract
product)
Ingegneria del software mod. A
ABSTRACT FACTORY
 Implementazione
 Solitamente si necessita di una sola istanza della
factory (Singleton design pattern)
 Definizione di factory estendibili
 Aggiungere un parametro ai metodi di creazione dei prodotti
 Il parametro specifica il tipo di prodotto
 Nei linguaggi tipizzati staticamente è possibile solo se tutti
i prodotti condividono la stessa interfaccia
 Può obbligare a down cast pericolosi …
38Riccardo Cardin
Ingegneria del software mod. A
RIFERIMENTI
 Design Patterns, Elements of Reusable Object Oriented Software, GoF,
1995, Addison-Wesley
 Design Patterns http://sourcemaking.com/design_patterns
 Java DP
http://www.javacamp.org/designPattern/
 Exploring the Decorator Pattern in Javascript
http://addyosmani.com/blog/decorator-pattern/
 Design Patterns in Scala http://pavelfatin.com/design-patterns-in-scala
 Item 2: Consider a builder when faced with many constructor parameters
http://www.informit.com/articles/article.aspx?p=1216151&seqNum=2
 Item 3: Enforce the singleton property with a private constructor or an
enum type
http://www.informit.com/articles/article.aspx?p=1216151&seqNum=3
 Type-safe Builder Pattern in Scala
http://blog.rafaelferreira.net/2008/07/type-safe-builder-pattern-in-
scala.html
39Riccardo Cardin

More Related Content

PPTX
Design Pattern Strutturali
Riccardo Cardin
 
PPTX
Design pattern architetturali Model View Controller, MVP e MVVM
Riccardo Cardin
 
PPTX
Errori comuni nei documenti di Analisi dei Requisiti
Riccardo Cardin
 
PPTX
Design Pattern Architetturali - Dependency Injection
Riccardo Cardin
 
PPTX
Diagrammi di Sequenza
Riccardo Cardin
 
PPTX
Introduzione ai Design Pattern
Riccardo Cardin
 
PPTX
Design Pattern Comportamentali
Riccardo Cardin
 
PPTX
Diagrammi Use Case
Riccardo Cardin
 
Design Pattern Strutturali
Riccardo Cardin
 
Design pattern architetturali Model View Controller, MVP e MVVM
Riccardo Cardin
 
Errori comuni nei documenti di Analisi dei Requisiti
Riccardo Cardin
 
Design Pattern Architetturali - Dependency Injection
Riccardo Cardin
 
Diagrammi di Sequenza
Riccardo Cardin
 
Introduzione ai Design Pattern
Riccardo Cardin
 
Design Pattern Comportamentali
Riccardo Cardin
 
Diagrammi Use Case
Riccardo Cardin
 

What's hot (11)

PPTX
Diagrammi delle Classi
Riccardo Cardin
 
PPTX
Diagrammi di Attività
Riccardo Cardin
 
PPTX
Introduzione a UML
Riccardo Cardin
 
PPTX
Mvc e di spring e angular js
Riccardo Cardin
 
PPTX
Il linguaggio UML - Teoria ed esempi pratici sugli use case diagram
Giuseppe Cramarossa
 
PPTX
Dependency Injection
Raffaele Fanizzi
 
ODP
Aspect Oriented Programming
Andrea Bozzoni
 
PPTX
High Level Synthesis Using Esterel
Alberto Minetti
 
PDF
Lezione 11 - Bridge
Marco Bianchi
 
PPT
Java codestyle & tipstricks
Domenico Briganti
 
PDF
Java AWT
Stefano Sanna
 
Diagrammi delle Classi
Riccardo Cardin
 
Diagrammi di Attività
Riccardo Cardin
 
Introduzione a UML
Riccardo Cardin
 
Mvc e di spring e angular js
Riccardo Cardin
 
Il linguaggio UML - Teoria ed esempi pratici sugli use case diagram
Giuseppe Cramarossa
 
Dependency Injection
Raffaele Fanizzi
 
Aspect Oriented Programming
Andrea Bozzoni
 
High Level Synthesis Using Esterel
Alberto Minetti
 
Lezione 11 - Bridge
Marco Bianchi
 
Java codestyle & tipstricks
Domenico Briganti
 
Java AWT
Stefano Sanna
 
Ad

Viewers also liked (18)

PPTX
Java- Concurrent programming - Synchronization (part 1)
Riccardo Cardin
 
PPTX
Java - Sockets
Riccardo Cardin
 
PPTX
Java - Processing input and output
Riccardo Cardin
 
PPTX
Java- Concurrent programming - Synchronization (part 2)
Riccardo Cardin
 
PPTX
Java - Concurrent programming - Thread's advanced concepts
Riccardo Cardin
 
PPTX
Java - Generic programming
Riccardo Cardin
 
PPTX
Java - Concurrent programming - Thread's basics
Riccardo Cardin
 
PPTX
Software architecture patterns
Riccardo Cardin
 
PPTX
Java Graphics Programming
Riccardo Cardin
 
PPTX
Java Exception Handling, Assertions and Logging
Riccardo Cardin
 
PPTX
Java - Remote method invocation
Riccardo Cardin
 
PPTX
SOLID - Principles of Object Oriented Design
Riccardo Cardin
 
PPTX
Java - Collections framework
Riccardo Cardin
 
PDF
5 Most Common Trade Spend Mistakes
Relational Solutions a Mindtree Company
 
PDF
Yd1105164 sprawozdanie merytoryczne 2011 eng done-1
odfoundation
 
PPTX
my favourite country
Tina Brasil
 
PDF
Doc014
odfoundation
 
PDF
25 04-2014-odf-45-dney-okkupacii-kryma-rossiey-ua
odfoundation
 
Java- Concurrent programming - Synchronization (part 1)
Riccardo Cardin
 
Java - Sockets
Riccardo Cardin
 
Java - Processing input and output
Riccardo Cardin
 
Java- Concurrent programming - Synchronization (part 2)
Riccardo Cardin
 
Java - Concurrent programming - Thread's advanced concepts
Riccardo Cardin
 
Java - Generic programming
Riccardo Cardin
 
Java - Concurrent programming - Thread's basics
Riccardo Cardin
 
Software architecture patterns
Riccardo Cardin
 
Java Graphics Programming
Riccardo Cardin
 
Java Exception Handling, Assertions and Logging
Riccardo Cardin
 
Java - Remote method invocation
Riccardo Cardin
 
SOLID - Principles of Object Oriented Design
Riccardo Cardin
 
Java - Collections framework
Riccardo Cardin
 
5 Most Common Trade Spend Mistakes
Relational Solutions a Mindtree Company
 
Yd1105164 sprawozdanie merytoryczne 2011 eng done-1
odfoundation
 
my favourite country
Tina Brasil
 
Doc014
odfoundation
 
25 04-2014-odf-45-dney-okkupacii-kryma-rossiey-ua
odfoundation
 
Ad

Similar to Design Pattern Creazionali (20)

PDF
Lezione 01 - Singleton
Marco Bianchi
 
ODP
Design Pattern
Giuseppe Dell'Abate
 
PPTX
Il web 2.0
Giacomo Veneri
 
PDF
Lezione 5: Design Pattern Creazionali
Andrea Della Corte
 
PDF
Lezione 04 - Factory method
Marco Bianchi
 
PDF
Idiomatic Domain Driven Design
Andrea Saltarello
 
PPT
Spring 2.5
Pasquale Paola
 
PPT
Programmazione a oggetti tramite la macchina del caffé (pt. 3)
Marcello Missiroli
 
PDF
Code Contracts and Generics: implementing a LINQ-enabled Repository
Andrea Saltarello
 
ODP
70k linee di codice, tangle architetturali e le sfide del refactoring
Paolo Predonzani
 
PDF
AntiPatterns: i vizi del programmatore
Manuel Scapolan
 
PDF
Waterfall Software Development Life Cycle
PierpaoloCaricato
 
PDF
Repository pattern slides v1.1
Christian Nastasi
 
PDF
Modulo 6 Spring Framework Core E Aop
jdksrl
 
PDF
Design pattern template method
Nelson Firmani
 
PDF
(E book ita) java introduzione alla programmazione orientata ad oggetti in ...
Raffaella D'angelo
 
PPT
Riuso Object Oriented
Stefano Fago
 
PPTX
Inversion of Control @ CD2008
Mauro Servienti
 
PPTX
03-Lezione PON BAITAH Dott. Suma - Software Engineering - cenni
Marco Suma
 
PDF
Approccio Pratico al Domain Driven Design
Luca Milan
 
Lezione 01 - Singleton
Marco Bianchi
 
Design Pattern
Giuseppe Dell'Abate
 
Il web 2.0
Giacomo Veneri
 
Lezione 5: Design Pattern Creazionali
Andrea Della Corte
 
Lezione 04 - Factory method
Marco Bianchi
 
Idiomatic Domain Driven Design
Andrea Saltarello
 
Spring 2.5
Pasquale Paola
 
Programmazione a oggetti tramite la macchina del caffé (pt. 3)
Marcello Missiroli
 
Code Contracts and Generics: implementing a LINQ-enabled Repository
Andrea Saltarello
 
70k linee di codice, tangle architetturali e le sfide del refactoring
Paolo Predonzani
 
AntiPatterns: i vizi del programmatore
Manuel Scapolan
 
Waterfall Software Development Life Cycle
PierpaoloCaricato
 
Repository pattern slides v1.1
Christian Nastasi
 
Modulo 6 Spring Framework Core E Aop
jdksrl
 
Design pattern template method
Nelson Firmani
 
(E book ita) java introduzione alla programmazione orientata ad oggetti in ...
Raffaella D'angelo
 
Riuso Object Oriented
Stefano Fago
 
Inversion of Control @ CD2008
Mauro Servienti
 
03-Lezione PON BAITAH Dott. Suma - Software Engineering - cenni
Marco Suma
 
Approccio Pratico al Domain Driven Design
Luca Milan
 

Design Pattern Creazionali

  • 1. DESIGN PATTERN CREAZIONALI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2014 – 2015 [email protected]
  • 2. Ingegneria del software mod. A DESIGN PATTERN CREAZIONALI 2Riccardo Cardin Architetturali Model view controller
  • 3. Ingegneria del software mod. A INTRODUZIONE  Scopo dei design pattern creazionali  Rendere un sistema indipendente dall’implementazione concreta delle sue componenti  Si nascondono i tipi concreti delle classi realmente utilizzate  Si nascondono i dettagli sulla composizione e creazione  Riduzione accoppiamento e flessibilità  Ampio uso dell’astrazione / interfacce 3Riccardo Cardin
  • 4. Ingegneria del software mod. A SINGLETON  Scopo  Assicurare l’esistenza di un’unica istanza di una classe  … ed avere un punto di accesso globale a questa  Motivazione  Alcune entità NON DEVONO avere più di un’istanza  Non è possibile utilizzare una variabile globale (C++)  La classe deve tenere traccia della sua unica istanza 4Riccardo Cardin
  • 5. Ingegneria del software mod. A SINGLETON  Applicabilità  Deve esistere una e una sola istanza di una classe in tutta l’applicazione  L’istanza deve essere accessibile dai client in modo noto  L’istanza deve essere estendibile con ereditarietà  I client non devono modificare il proprio codice 5Riccardo Cardin
  • 6. Ingegneria del software mod. A SINGLETON  Struttura 6Riccardo Cardin Definisce getInstance che permette l’accesso all’unica istanza. È responsabile della creazione dell’unica istanza /* * Implementazione Java * "naive" */ public class Singleton { private static Singleton instance; private Singleton() { /* Corpo vuoto */ } public static Singleton getInstance() { if (instance == nul) { instance = new Singleton(); } return instance; } }
  • 7. Ingegneria del software mod. A SINGLETON  Conseguenze  Controllo completo di come e quando i client accedono all’interfaccia  Evita il proliferare di variabili globali (C++)  Permette la ridefinizione delle operazioni definite nel Singleton  Può permettere un numero massimo e preciso di istanze attive  Più flessibile delle operazioni di classe  Utilizzo del polimorfismo 7Riccardo Cardin
  • 8. Ingegneria del software mod. A SINGLETON  Esempio 8Riccardo Cardin Esempio Un applicativo deve istanziare un oggetto che gestisce una stampante (printer spooler). Questo oggetto deve essere unico perché si dispone di una sola risorsa di stampa.
  • 9. Ingegneria del software mod. A SINGLETON  Esempio  Printer Spooler 9Riccardo Cardin L’appoccio non è thread safe in Java: nessuna sincronizzazione sulla creazione di instance
  • 10. Ingegneria del software mod. A SINGLETON  Implementazione  Assicurare un’unica istanza attiva (lazy initialization)  Si rende il/i costruttore/i privato/i (non accessibili)  Si rende disponibile un’operazione di classe di “recupero”  Non è possibile utilizzare variabili globali (C++)  Non garantisce l’unicità dell’istanza  L’istanza è generata durante l’inizializzazione “statica”  Tutti i singleton sarebbero costruiti sempre, anche se mai utilizzati 10Riccardo Cardin
  • 11. Ingegneria del software mod. A SINGLETON  Implementazione  Ereditare da una classe Singleton  È difficile installare l’unica istanza nel membro instance  La soluzione migliore è utilizzare un registro di singleton 11Riccardo Cardin public class Singleton { private static Singleton instance; private static Map<String, Singleton> registry; private Singleton() { /* Corpo vuoto */ } public static register(String name, Singleton) { /* ... */} protected static Singleton lookup(String name) { /* ... */} public static Singleton getInstance(String singletonName) { /* Utilizza lookup per recuperare l’istanza */ } } public class MySingleton extends Singleton { static { Singleton.register(“MySingleton”, new MySingleton()) } /* ... */ }
  • 12. Ingegneria del software mod. A SINGLETON  Implementazione  Java  Costruttore privato (omesso per spazio) 12Riccardo Cardin public class PrinterSpooler { private static final PrinterSpooler INSTANCE = new PrinterSpooler(); public static PrinterSpooler getInstance() { return INSTANCE; } } no lazy, thread safe, no subclassing, no serializable public class PrinterSpooler { private static volatile PrinterSpooler INSTANCE; public static PrinterSpooler getInstance() { if (INSTANCE == null) { synchronize (PrinterSpooler.class) { if (INSTANCE == null { INSTANCE = new PrinterSpooler(); } } } return INSTANCE; } } lazy, thread safe, subclassing possibile, no serializable Soffrono di attacco per Reflection sul costruttore
  • 13. Ingegneria del software mod. A SINGLETON  Implementazione  Java  Versione accettata da JDK ≥ 1.5  Item 3 di Effective Java di Joshua Bloch  Usa costrutti nativi del linguaggio  Non soffre di alcun attacco  Conciso, leggibile e manutenibile 13Riccardo Cardin public enum PrinterSpooler { INSTANCE; public void print(String file) { /* ... */ } } no lazy, thread safe, no subclassing, serializable
  • 14. Ingegneria del software mod. A SINGLETON  Implementazione  Scala  In Java il pattern Sigleton è uno dei più utilizzati  Mancanza a livello di linguaggio  Error prone  Scala risolve introducendo il tipo object  Implementazione del pattern Singleton nel linguaggio  Thread-safe  Gli Object sono inizializzati su richiesta (laziness) 14Riccardo Cardin object PrinterSpooler extends ... { def print(file: String) { // do something } } Cons: meno controllo sull’inizializzazione
  • 15. Ingegneria del software mod. A SINGLETON  Implementazione  Javascript: si utilizza il module pattern 15Riccardo Cardin var mySingleton = (function () { var instance; function init() { // Private methods and variables function privateMethod() { console.log( "I am private" ); }; var privateRandomNumber = Math.random(); return { // Public methods and variables publicMethod: function () { console.log( "The public can see me!" ); }, getRandomNumber: function() { return privateRandomNumber; } }; }; return { getInstance: function () { if ( !instance ) { instance = init(); } return instance; } }; })(); Public functions/variables Private namespace
  • 16. Ingegneria del software mod. A BUILDER  Scopo  Separa la costruzione di un oggetto complesso dalla sua rappresentazione  Motivazione  Necessità di riutilizzare un medesimo algoritmo di costruzione per più oggetti di tipo differente  Processo di costruzione step-by-step 16Riccardo Cardin Il cassiere deve: 1. Inserire il panino 2. Inserire le patate 3. Inserire la frutta 4. ...
  • 17. Ingegneria del software mod. A BUILDER  Esempio 17Riccardo Cardin
  • 18. Ingegneria del software mod. A BUILDER  Applicabilità  La procedura di creazione di un oggetto complesso deve essere indipendente dalle parti che compongono l’oggetto  Il processo di costruzione deve permettere diverse rappresentazioni per l’oggetto da costruire 18Riccardo Cardin
  • 19. Ingegneria del software mod. A BUILDER  Struttura 19Riccardo Cardin Costruisce un oggetto utilizzando il builder (procedura) Specifica l’interfaccia da utilizzare per assemblare il prodotto Costruisce e assembla le parti del prodotto. Tiene traccia dell’istanza costruita. Fornisce un’interfaccia per recuperare il prodotto finale Il prodotto complesso da costruire
  • 20. Ingegneria del software mod. A BUILDER  Struttura 20Riccardo Cardin Il client conosce il tipo builder concreto Il director notifica il builder delle parti che devono essere costruite Il client recupera dal builder concreto il prodotto finito
  • 21. Ingegneria del software mod. A BUILDER  Conseguenze  Facilita le modifiche alla rappresentazione interna di un prodotto  È sufficiente costruire un nuovo builder: NO telescoping!  Isola il codice dedicato alla costruzione di un prodotto dalla sua rappresentazione  Il client non conosce le componenti interne di un prodotto  Encapsulation  L’orchestrazione dei processi di costruzione è unica  Consente un controllo migliore del processo di costruzione  Costruzione step-by-step  Accentramento logica di validazione 21Riccardo Cardin
  • 22. Ingegneria del software mod. A BUILDER  Esempio 22Riccardo Cardin Si vuole ordinare un bicchiere di scotch. È necessario fornire al barman alcune informazioni: la marca del whiskey, come deve essere preparato (liscio, on the rocks, allungato) e se lo si desidera doppio. È inoltre possibile scegliere il tipo di bicchiere (piccolo, lungo, a tulipano). [se fossimo veramente intenditori, anche la marca e la temperatura dell’acqua sarebbero fondamentali...]
  • 23. Ingegneria del software mod. A BUILDER 23Riccardo CardinIngegneria del software mod. A
  • 24. Ingegneria del software mod. A BUILDER  Implementazione  Il builder defisce un’interfaccia per ogni parte che il director può richiedere di costruire  Abbastanza generale per la costruizione di prodotti differenti  Appending process  Nessuna classe astratta comune per i prodotti  Differiscono notevolmente fra loro  Se simili, valutare l’utilizzo di un Abstract Factory Pattern  Fornire metodi vuoti come default  I builder concreti ridefiniscono solo i metodi necessari 24Riccardo Cardin
  • 25. Ingegneria del software mod. A BUILDER  Implementazione  Java: il builder diventa classe interna del prodotto 25Riccardo Cardin public class OrderOfScotch { private String brand; private Praparation preparation; // Si puo’ dichiarare enum interna // ... private OrderOfScotch() { } // Costruttore privato per il prodotto private OrderOfScotch(ScotchBuilder builder) { this.brand = builder._brand; // ... } public static class Builder { private String _brand; // Inserisco '_' per diversificare private Praparation _preparation; // ... public ScotchBuilder withBrand(String brand) { this._brand = brand; return this; // Appending behaviour } // CONTINUA...
  • 26. Ingegneria del software mod. A BUILDER  Implementazione  Java  Item 2 di Effective Java di Joshua Bloch 26Riccardo Cardin // CONTINUA... public OrderOfScotch build() { return new OrderOfScotch(this); } } // public static class Builder public static void main(String[] args) { // Il client non conosce il processo di costruzione e le classi // prodotto e builder sono correttamente accoppiate tra loro. // Non e’ possibile costruire un prodotto se non con il builder. OrderOfScotch oos = new OrderOfScotch.Builder() .withBrand(“Brand 1“) .withPreparation(NEAT) // ... .build(); } } // public class OrderOfScotch
  • 27. Ingegneria del software mod. A BUILDER  Implementazione  Javascript 27Riccardo Cardin var Builder = function() { var a = "defaultA"; // Valori default var b = "defaultB"; return { withA : function(anotherA) { a = anotherA; return this; // Append behaviour }, withB : function(anotherB) { b = anotherB; return this; }, build : function() { return "A is: " + a +", B is: " + b; } }; }; var first = builder.withA().withB("a different value for B").build(); Approccio classico, con l’utilizzo degli scope per la creazione degli oggetti
  • 28. Ingegneria del software mod. A BUILDER  Implementazione  Javascript – JQuery  Costruzione step-by-step del DOM 28Riccardo Cardin // I metodi appendTo, attr, text permettono di costruire un oggetto // all’interno del DOM in modo step-by-step $( '<div class="foo">bar</div>' ); $( '<p id="test">foo <em>bar</em></p>').appendTo("body"); var newParagraph = $( "<p />" ).text( "Hello world" ); $( "<input />" ) .attr({ "type": "text", "id":"sample"}) .appendTo("#container");
  • 29. Ingegneria del software mod. A BUILDER  Implementazione  Scala  In Scala è possibile utilizzare i principi dei linguaggi funzionali  Immutabilità del builder  Type-safe builder  Assicura staticamente che sono state fornite tutte le informazioni necessarie alla costruzione  Si utilizzano feature avanzate del linguaggio  Type constraints  http://blog.rafaelferreira.net/2008/07/type-safe-builder- pattern-in-scala.html  http://www.tikalk.com/java/type-safe-builder-scala-using- type-constraints/ 29Riccardo Cardin
  • 30. Ingegneria del software mod. A ABSTRACT FACTORY  Scopo  Fornisce un’interfaccia per creare famiglie di prodotti senza specificare classi concrete  Motivazione  Applicazione configurabile con diverse famiglie di componenti  Toolkit grafico  Si definisce una classe astratta factory che definisce le interfacce di creazione.  I client non costruiscono direttamente i “prodotti”  Si definiscono le interfacce degli oggetti da creare  Le classi che concretizzano factory vengono costruite una volta sola 30Riccardo Cardin
  • 31. Ingegneria del software mod. A ABSTRACT FACTORY  Applicabilità  Un sistema indipendente da come i componenti sono creati, composti e rappresentati  Un sistema configurabile con più famiglie prodotti  Le componenti di una famiglia DEVONO essere utilizzate insieme  Si vuole fornire una libreria di classi prodotto, senza rivelarne l’implementazione. 31Riccardo Cardin
  • 32. Ingegneria del software mod. A ABSTRACT FACTORY  Struttura 32Riccardo Cardin Dichiara l’interfaccia di creazione dei prodotti Costruiscono i prodotti concreti Interfaccia per un particolare prodotto Definisce un prodotto concreto, che deve essere costruito mediante factory
  • 33. Ingegneria del software mod. A ABSTRACT FACTORY  Conseguenze  Isolamento dei tipi concreti  I client manipolano unicamente interfacce, i nomi dei prodotti sono nascosti  Semplicità maggiore nell’utilizzo di una diversa famiglia di prodotti  La factory concreta appare solo una volta nel programma  Promuove la consistenza fra i prodotti  Difficoltà nel supportare nuovi prodotti  Modificare l’interfaccia della factory astratta costringe il cambiamento di tutte le sotto classi. 33Riccardo Cardin
  • 34. Ingegneria del software mod. A ABSTRACT FACTORY  Esempio 34Riccardo Cardin Esempio Si vuole realizzare un negozio di vendita di sistemi Hi-Fi, dove si eseguono dimostrazioni dell’utilizzo dei prodotti. Esistono due famiglie di prodotti, basate su tecnologie diverse: - supporto di tipo nastro (tape) - supporto di tipo digitale (CD). Ogni famiglia è composta da: - supporto (tape o CD) - masterizzatore (recorder) - riproduttore (player).
  • 35. Ingegneria del software mod. A ABSTRACT FACTORY  Esempio 35Riccardo Cardin
  • 36. Ingegneria del software mod. A ABSTRACT FACTORY  Esempio  Scala: companion object (Factory Method)  Apply è tradotto in un simil – costruttore  Si utilizza per la costruzione delle factory concrete 36Riccardo Cardin trait Animal private class Dog extends Animal private class Cat extends Animal object Animal { def apply(kind: String) = kind match { case "dog" => new Dog() case "cat" => new Cat() } } val animal = Animal("dog") Equivale a Animal(...)
  • 37. Ingegneria del software mod. A ABSTRACT FACTORY  Esempio  Javascript: varie tecniche di implementazione 37Riccardo Cardin var AbstractVehicleFactory = (function () { // Storage for our vehicle types var types = {}; return { getVehicle: function ( type, customizations ) { var Vehicle = types[type]; return (Vehicle ? new Vehicle(customizations) : null); }, registerVehicle: function ( type, Vehicle ) { var proto = Vehicle.prototype; if ( proto.drive && proto.breakDown ) { types[type] = Vehicle; } return AbstractVehicleFactory; } }; })(); Registro solamente gli oggetti che soddisfano un contratto (abstract product)
  • 38. Ingegneria del software mod. A ABSTRACT FACTORY  Implementazione  Solitamente si necessita di una sola istanza della factory (Singleton design pattern)  Definizione di factory estendibili  Aggiungere un parametro ai metodi di creazione dei prodotti  Il parametro specifica il tipo di prodotto  Nei linguaggi tipizzati staticamente è possibile solo se tutti i prodotti condividono la stessa interfaccia  Può obbligare a down cast pericolosi … 38Riccardo Cardin
  • 39. Ingegneria del software mod. A RIFERIMENTI  Design Patterns, Elements of Reusable Object Oriented Software, GoF, 1995, Addison-Wesley  Design Patterns http://sourcemaking.com/design_patterns  Java DP http://www.javacamp.org/designPattern/  Exploring the Decorator Pattern in Javascript http://addyosmani.com/blog/decorator-pattern/  Design Patterns in Scala http://pavelfatin.com/design-patterns-in-scala  Item 2: Consider a builder when faced with many constructor parameters http://www.informit.com/articles/article.aspx?p=1216151&seqNum=2  Item 3: Enforce the singleton property with a private constructor or an enum type http://www.informit.com/articles/article.aspx?p=1216151&seqNum=3  Type-safe Builder Pattern in Scala http://blog.rafaelferreira.net/2008/07/type-safe-builder-pattern-in- scala.html 39Riccardo Cardin