Il 0% ha trovato utile questo documento (0 voti)
3 visualizzazioni49 pagine

IngSW DP 02 DesignPatternCreazionaliDiagram

Il documento descrive il pattern creazionale Singleton. Il Singleton garantisce l'esistenza di un'unica istanza di una classe e fornisce un punto di accesso globale a questa. Il documento spiega lo scopo, la motivazione e l'implementazione del pattern Singleton.

Caricato da

milanialfredo
Copyright
© © All Rights Reserved
Per noi i diritti sui contenuti sono una cosa seria. Se sospetti che questo contenuto sia tuo, rivendicalo qui.
Formati disponibili
Scarica in formato PDF, TXT o leggi online su Scribd
Il 0% ha trovato utile questo documento (0 voti)
3 visualizzazioni49 pagine

IngSW DP 02 DesignPatternCreazionaliDiagram

Il documento descrive il pattern creazionale Singleton. Il Singleton garantisce l'esistenza di un'unica istanza di una classe e fornisce un punto di accesso globale a questa. Il documento spiega lo scopo, la motivazione e l'implementazione del pattern Singleton.

Caricato da

milanialfredo
Copyright
© © All Rights Reserved
Per noi i diritti sui contenuti sono una cosa seria. Se sospetti che questo contenuto sia tuo, rivendicalo qui.
Formati disponibili
Scarica in formato PDF, TXT o leggi online su Scribd
Sei sulla pagina 1/ 49

DESIGN PATTERN

CREAZIONALI INGEGNERIA DEL


SOFTWARE
Università degli Studi di Perugia
Dipartmento di Matematia e Informatia
Corso di Laurea in Informatia

[email protected]
DESIGN PATTERN CREAZIONALI

Architetturali
Model view controller
Ingegneria del Sofware - Design Patern Alfredo Milani 2
INTRODUZIONE
 Scopo dei design patern creazionali
 Rendere un sistema indipendente
dall’implementazione concreta delle sue component
 Si nascondono i tpi concret delle classi realmente utlizzate
 Si nascondono i detagli sulla composizione e creazione

 Riduzione accoppiamento e fessiiilità

 Ampio uso dell’astrazione / interfacce

Ingegneria del Sofware - Design Patern Alfredo Milani 3


SINGLETON
 Scopo
 Assicurare l’esistenza di un’unica istanza di una classe
 … ed avere un punto di accesso gloiale a questa

 Motvazione
 Alcune enttà NON DEVONO avere più di un’istanza
 Non è possiiile utlizzare una variaiile gloiale (C++)
 La classe deve tenere traccia della sua unica istanza

Ingegneria del Sofware - Design Patern Alfredo Milani 4


SINGLETON
 Applicaiilità

 Deve esistere una e una sola istanza di una classe in


tuta l’applicazione
 L’istanza deve essere accessiiile dai client in modo noto

 L’istanza deve essere estendiiile con ereditarietà


 I client non devono modifcare il proprio codice

Ingegneria del Sofware - Design Patern Alfredo Milani 5


SINGLETON
 Strutura
/*
/*
** Implementazione
Implementazione Java
Java
** "naive"
"naive"
Defnisce getInstance che
Defnisce getInstance che permette
permette */
*/
l’accesso
l’accesso all’unica
all’unica istanza.
istanza. È
È public
public class
class Singleton
Singleton {{
responsabile della creazione dell’unica
responsabile della creazione dell’unica private static
private static
istanza
istanza
Singleton
Singleton instance;
instance;

private
private Singleton()
Singleton() {{

/*
/* Corpo
Corpo vuoto
vuoto */
*/
}}

public
public static
static Singleton
Singleton
getInstance() {
getInstance() {

if
if (instance
(instance ==
== nul)
nul) {{
instance
instance ==
new
new Singleton();
Singleton();
}}
return
return instance;
instance;
}}
}}

Ingegneria del Sofware - Design Patern Alfredo Milani 6


SINGLETON
 Conseguenze

 Controllo completo di come e quando i client


accedono all’interfaccia
 Evita il proliferare di variaiili gloiali (C++)
 Permete la ridefnizione delle operazioni defnite nel
Singleton
 Può permetere un numero massimo e preciso di
istanze attive
 Più fessiiile delle operazioni di classe
 Utlizzo del polimorfsmo

Ingegneria del Sofware - Design Patern Alfredo Milani 7


SINGLETON
 Esempio

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 Sofware - Design Patern Alfredo Milani 8


SINGLETON
 Esempio
 Printer Spooler

L’appoccio
L’appoccio non
non èè thread safe in
thread safe in
Java:
Java: nessuna
nessuna sincronizzazione
sincronizzazione
sulla
sulla creazione
creazione di
di instance
instance

Ingegneria del Sofware - Design Patern Alfredo Milani 9


SINGLETON
 Implementazione

 Assicurare un’unica istanza attiva (lazy initalizaton)


 Si rende il/i costrutore/i privato/i (non accessiiili)
 Si rende disponiiile un’operazione di classe di “recupero”

 Non è possiiile utlizzare variaiili gloiali (C++)


 Non garantsce l’unicità dell’istanza
 L’istanza è generata durante l’inizializzazione “statca”

 Tutti i singleton sareiiero costruit sempre, anche se mai

utlizzat

Ingegneria del Sofware - Design Patern Alfredo Milani 10


SINGLETON
 Implementazione
 Ereditare da una classe Singleton
 È difcile installare l’unica istanza nel memiro instance
 La soluzione migliore è utlizzare un registro di singleton

public class Singleton {


private static Singleton instance;
private static Map<String, Singleton> registry; public
public class
class MySingleton
MySingleton
extends
extends Singleton
Singleton {{
private Singleton() { /* Corpo vuoto */ }

public static register(String name, Singleton) static


static {{
{ /* ... */}
Singleton.register(“MySingleton”,
Singleton.register(“MySingleton”,
new
new MySingleton())
MySingleton())
protected static Singleton lookup(String name) }}
{ /* ... */}

/*
/* ...
... */
*/
public static Singleton }}
getInstance(String singletonName) {

/* Utilizza lookup per recuperare l’istanza */


}

}Ingegneria del Sofware - Design Patern Alfredo Milani 11


SINGLETON
Sofrono
Sofrono di
di attacco
attacco per
per
Refection sul
Refection sul costruttore
costruttore
 Implementazione
 Java  Costrutore privato (omesso per spazio)
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
Ingegneria del Sofware - Design Patern Alfredo Milani 12
SINGLETON
 Implementazione
 Java
 Versione accetata da JDK ≥ 1.5

public enum PrinterSpooler {


INSTANCE;

public void print(String file) { /* ... */ }


}
 Item 3 di Effectve aavanodilazy, Blochsafe, no subclassing, serializable
thread
Joshua
 Usa costrutti natvi del linguaggio

 Non sofre di alcun atacco

 Conciso, leggiiile e manuteniiile

Ingegneria del Sofware - Design Patern Alfredo Milani 13


SINGLETON
Cons:
Cons: meno
meno
 Implementazione controllo
controllo
 Scala sull’inizializzazione
sull’inizializzazione
object PrinterSpooler extends ... {
def print(file: String) {
// do something
}
}

 In Java il patern Sigleton è uno dei più utlizzat


 Mancanza a livello di linguaggio
 Error prone

 Scala risolve introducendo il tpo object


 Implementazione del patern Singleton nel linguaggio
 Thread-safe

 Gli Object sono inizializzat su richiesta (laziness)

Ingegneria del Sofware - Design Patern Alfredo Milani 14


SINGLETON
 Implementazione
 Javascript: si utlizza il module patern Private
Private
var mySingleton = (function () {
namespace
namespace
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 () { Public
Public
if ( !instance ) { instance = init(); }
return instance;
functions/variables
functions/variables
}
}; })();

Ingegneria del Sofware - Design Patern Alfredo Milani 15


SINGLETON
 Casi d’uso del patern:
 Accesso ad interfacce hardware: es. printer spooler
(visto prima)
 Logger: nel caso di applicazioni dove l’utlit di
logging deve produrre un unico fle di log per i
messaggi ricevut dagli utent
 Confguraton fle: per creare una singola istanza del
fle di confgurazione a cui si può accedere da
chiamate multple concorrentemente.
 Cache: usare la cache come un oggeto singleton che
può per avere un riferimento gloiale

Ingegneria del Sofware - Design Patern Alfredo Milani 16


BUILDER
 Scopo
 Separa la costruzione di un oggeto complesso dalla
sua rappresentazione
 Motvazione
 Necessità di riutlizzare un medesimo algoritmo di
costruzione per più oggetti di tpo diferente
 Processo di costruzione step-by-step

Il cassiere deve:
 Inserire il panino
 Inserire le patate
 Inserire la fruta
 ...

Ingegneria del Sofware - Design Patern Alfredo Milani 17


BUILDER
 Applicaiilità

 La procedura di creazione di un oggeto complesso


deve essere indipendente dalle part che
compongono l’oggeto

 Il processo di costruzione deve permetere diverse


rappresentazioni per l’oggeto da costruire

Ingegneria del Sofware - Design Patern Alfredo Milani 18


BUILDER
 Strutura
Costruisce
Costruisce un
un oggetto
oggetto Specifca
Specifca l’interfaccia
l’interfaccia da
da
utilizzando
utilizzando ilil builder
builder utilizzare
utilizzare perper assemblare
assemblare
(procedura)
(procedura) ilil prodotto
prodotto

Il
Il prodotto
prodotto complesso
complesso
da
da costruire
costruire

Costruisce
Costruisce ee assembla
assembla le le parti
parti del
del
prodotto.
prodotto. Tiene
Tiene traccia
traccia dell’istanza
dell’istanza
costruita.
costruita. Fornisce
Fornisce un’interfaccia
un’interfaccia per
per
recuperare
recuperare ilil prodotto
prodotto fnale
fnale
Ingegneria del Sofware - Design Patern Alfredo Milani 19
BUILDER
 Esempio

Ingegneria del Sofware - Design Patern Alfredo Milani 20


BUILDER
 Strutura

Il client conosce
Il client conosce ilil tipo
tipo
builder concreto
builder concreto

Il director notifca
Il director notifca ilil
builder delle
builder delle parti
parti che
che
devono
devono essere
essere costruite
costruite

Il client recupera
Il client recupera dal
dal
builder concreto
builder concreto ilil
prodotto
prodotto fnito
fnito

Ingegneria del Sofware - Design Patern Alfredo Milani 21


BUILDER
 Conseguenze
 Facilita le modifche alla rappresentazione interna di
un prodoto
 È sufciente costruire un nuovo builder: NO telescoping!
 Isola il codice dedicato alla costruzione di un prodoto
dalla sua rappresentazione
 Il client non conosce le component interne di un prodoto
 Encapsulaton

 L’orchestrazione dei processi di costruzione è unica

 Consente un controllo migliore del processo di


costruzione
 Costruzione step-by-step
 Accentramento logica di validazione

Ingegneria del Sofware - Design Patern Alfredo Milani 22


BUILDER
 Esempio di telescoping:
public class User {
private final String firstName; //required
private final String lastName; //required
private final int age; //optional
private final String phone; //optional
private final String address; //optional

public User(String firstName, String lastName) {


this.firstName = firstName;
this.lastName = lastName;}

public User(String firstName, String lastName, int age) {


this.firstName = firstName;
this.lastName = lastName;
this.age = age;}

public User(String firstName, String lastName, int age, String phone) {


this.firstName = firstName;
this.lastName = lastName;
/// ...}
}
Ingegneria del Sofware - Design Patern Alfredo Milani 23
BUILDER
 Telescoping:

 utlizzo di costrutori in overloading


 per ogni change request - informazioni non previste
dalla analisi iniziale del progeto - è stato aggiunto un
nuovo costrutore incrementando il costrutore più
“esteso” con dei parametri opzionali
 codice poco leggiiile!!!

Ingegneria del Sofware - Design Patern Alfredo Milani 24


BUILDER
 Soluzione:
public class User{
private final String firstName; // required Attributi
Attributi privati
privati ee
private final String lastName; // required fnal:
fnal: sono
sono
private final int age; // optional
private final String phone; // optional inizializzabili
inizializzabili solo
solo dal
dal
private final String address; // optional costruttore
costruttore
Costruttore
Costruttore
private User(UserBuilder builder) {
this.firstName = builder.firstName; privato:
privato: la
la classe
classe
this.lastName = builder.lastName; non
non può
può essere
essere
this.age = builder.age; istanziata
istanziata
this.phone = builder.phone;
this.address = builder.address;
direttamente
direttamente
}

public String getFirstName() {


return firstName;}

public String getLastName() {


return lirstName;}
// ... del Sofware - Design Patern
Ingegneria Alfredo Milani 25
BUILDER
 Soluzione:
public static lass UserBuilder {
private final String firstName; //required
private final String lastName; //required
private int age; //optional
private String phone; //optional
private String address; //optional

public UserBuilder(String firstName, String lastName) {


this.firstName = firstName;
this.lastName = lastName;}

public UserBuilder age(int age) {


this.age = age;
return this;} Si
Si può
può introdurre
introdurre la
la
validazione
validazione della
della
// ... classe
classe base
base
public User build() {
return new User(this);}
}
}Ingegneria del Sofware - Design Patern Alfredo Milani 26
BUILDER
 Esempio

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 Sofware - Design Patern Alfredo Milani 27


BUILDER

Ingegneria del Sofware - Design


sofware mod. A Patern Alfredo Milani 28
BUILDER
 Implementazione

 Il builder defsce un’interfaccia per ogni parte che il


director può richiedere di costruire
 Aiiastanza generale per la costruizione di prodotti diferent
 Appending process

 Nessuna classe astrata comune per i prodotti


 Diferiscono notevolmente fra loro
 Se simili, valutare l’utlizzo di un Abstract Factory Patern

 Fornire metodi vuot come default


 I builder concret ridefniscono solo i metodi necessari

Ingegneria del Sofware - Design Patern Alfredo Milani 29


BUILDER
 Implementazione
 Java: il builder diventa classe interna del prodoto
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 Sofware - Design Patern Alfredo Milani 30
BUILDER
 Implementazione
 Java
// 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();

} Item 2 di Effectve aava di Joshua Bloch
} // public class OrderOfScotch

Ingegneria del Sofware - Design Patern Alfredo Milani 31


BUILDER
 Implementazione
 Javascript
var Builder = function() { Approccio
Approccio classico,
classico,
var a = "defaultA"; // Valori default con
con l’utilizzo
l’utilizzo degli
degli
var b = "defaultB";
scope per
scope per la
la
return {
withA : function(anotherA) { creazione
creazione degli
degli
a = anotherA; oggetti
oggetti
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();
Ingegneria del Sofware - Design Patern Alfredo Milani 32
BUILDER
 Implementazione
 Javascript – JQuery
 Costruzione step-by-step del DOM

// 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 Sofware - Design Patern Alfredo Milani 33


BUILDER
 Implementazione
 Scala
 In Scala è possiiile utlizzare i principi dei linguaggi funzionali
 Immutaiilità del builder

 Type-safe builder

 Assicura statcamente che sono state fornite tute le

informazioni necessarie alla costruzione


 Si utlizzano feature avanzate del linguaggio

 Type constraints
 htp://ilog.rafaelferreira.net/200//0//type-safe-iuilder-pater

n-in-scala.html
 htp

://www.tiali.com/java/type-safe-iuilder-scala-using-type-con
straints
/

Ingegneria del Sofware - Design Patern Alfredo Milani 34


ABSTRACT FACTORY
 Scopo
 Fornisce un’interfaccia per creare famiglie di prodotti
senza specifcare classi concrete
 Motvazione
 Applicazione confguraiile con diverse famiglie di
component
 Toolkit grafco
 Si defnisce una classe astrata factory che defnisce le
interfacce di creazione.
 I client non costruiscono diretamente i “prodotti”
 Si defniscono le interfacce degli oggetti da creare
 Le classi che concretzzano factory vengono costruite
una volta sola
Ingegneria del Sofware - Design Patern Alfredo Milani 35
ABSTRACT FACTORY
 Applicaiilità

 Un sistema indipendente da come i component sono


creat, compost e rappresentat

 Un sistema confguraiile con più famiglie prodotti

 Le component di una famiglia DEVONO essere


utlizzate insieme

 Si vuole fornire una liireria di classi prodoto, senza


rivelarne l’implementazione.

Ingegneria del Sofware - Design Patern Alfredo Milani 36


ABSTRACT FACTORY
 Strutura
Dichiara
Dichiara l’interfaccia
l’interfaccia di
di Interfaccia
Interfaccia per
per
creazione
creazione dei
dei prodotti
prodotti un
un particolare
particolare
prodotto
prodotto

Costruiscono
Costruiscono ii
prodotti
prodotti concreti
concreti
Defnisce
Defnisce un
un prodotto
prodotto
concreto,
concreto, che
che deve
deve
essere
essere costruito
costruito
mediante
mediante factory
factory
Ingegneria del Sofware - Design Patern Alfredo Milani 37
ABSTRACT FACTORY
 Conseguenze

 Isolamento dei tpi concret


 I client manipolano unicamente interfacce, i nomi dei prodotti
sono nascost
 Semplicità maggiore nell’utlizzo di una diversa
famiglia di prodotti
 La factory concreta appare solo una volta nel programma
 Promuove la consistenza fra i prodotti
 Difcoltà nel supportare nuovi prodotti
 Modifcare l’interfaccia della factory astrata costringe il
camiiamento di tute le soto classi.

Ingegneria del Sofware - Design Patern Alfredo Milani 38


ABSTRACT FACTORY
 Esempio

Esempio

Si vuole realizzare un negozio di vendita di sistemi Hi-Fi, dove si eseguono


dimostrazioni dell’utlizzo dei prodotti.

Esistono due famiglie di prodotti, iasate su tecnologie diverse:


- supporto di tpo nastro (tape)
- supporto di tpo digitale (CD).

Ogni famiglia è composta da:


- supporto (tape o CD)
- masterizzatore (recorder)
- riprodutore (player).

Ingegneria del Sofware - Design Patern Alfredo Milani 39


ABSTRACT FACTORY
 Esempio

Ingegneria del Sofware - Design Patern Alfredo Milani 40


ABSTRACT FACTORY
 Esempio

Esempio

Si vuole realizzare un negozio di vendita di device moiile, dove si eseguono


dimostrazioni dell’utlizzo dei prodotti.

Esistono due famiglie di prodotti, iasate su sistemi operatvi diversi:


- sistemi IOS;
- sistemi android.

Ogni famiglia è composta da:


- smartphone.
- tailet.

Ingegneria del Sofware - Design Patern Alfredo Milani 41


ABSTRACT FACTORY

Ingegneria del Sofware - Design Patern Alfredo Milani 42


ABSTRACT FACTORY
 Implementazione
public interface MobileDeviceFactory {
public SmartPhone createSmartPhone();
AbstracFactory
AbstracFactory
public Tablet createTablet();
}

public class IOSDeviceFactory implements MobileDeviceFactory{


public SmartPhone createSmartPhone(){
return new IOSSmartPhone();} Factory
Factory concreta
concreta per
per
creare
creare ii prodotti
prodotti
public Tablet createTablet(){ della
della famiglia
famiglia IOS
IOS
return new IOSTablet();}
}

public class AndroidDeviceFactory implements MobileDeviceFactory{


public SmartPhone createSmartPhone(){ Factory
Factory concreta
concreta per
per
return new AndroidSmartPhone();} creare i prodotti
creare i prodotti
public Tablet createTablet(){ della
della famiglia
famiglia
return new AndroidTablet();} Android
Android
}

Ingegneria del Sofware - Design Patern Alfredo Milani 43


ABSTRACT FACTORY
 Implementazione
public interface SmartPhone {
public void call(String number); Interfacce
Interfacce per
per la
la
} creazione
creazione dei
dei due
due
public interface Tablet { prodotti
prodotti
public void read(String titolo);
}

public class IOSSmartPhone implements SmartPhone{


public void call(String number) {
System.out.println("IOS: Chiamata in corso "+number);
}
}

public class AndroidTablet implements Tablet{


public void read(String titolo) {
System.out.println("ANDROID: Read: "+titolo);
}
}

Ingegneria del Sofware - Design Patern Alfredo Milani 44


ABSTRACT FACTORY
 Implementazione
Si
Si creano
creano ii due
due prodotti
prodotti
public class Test {
della
della famiglia IOS
famiglia IOS
public static void main(String[] args){
MobileDeviceFactory iosMobileDevice = new IOSDeviceFactory();
SmartPhone iosSmartPhone = iosMobileDevice.createSmartPhone();
iosSmartPhone.call("075 585 5001");
Tablet iosTablet = iosMobileDevice.createTablet();
iosTablet.read("Manifesto Corso di Informatica");

MobileDeviceFactory androidMobileDevice = new AndroidDeviceFactory();


SmartPhone androidSmartPhone = androidMobileDevice.createSmartPhone();
androidSmartPhone.call("075 5851");
Tablet androidTablet = androidMobileDevice.createTablet();
androidTablet.read("Centralino Universita");
}
} Si
Si creano
creano ii due
due
prodotti dlle
prodotti dlle
famiglia
famiglia Android
Android

Ingegneria del Sofware - Design Patern Alfredo Milani 45


ABSTRACT FACTORY
 Esempio
 Scala: companion object (Factory Method)
trait Animal
private class Dog extends Animal
private class Cat extends Animal

object Animal {
def apply(kind: String) = Equivale
Equivale aa
kind match { Animal(...)
Animal(...)
case "dog" => new Dog()
case "cat" => new Cat()
}
}

val animal = Animal("dog")


 Apply è tradoto in un simil – costrutore
 Si utlizza per la costruzione delle factory concrete

Ingegneria del Sofware - Design Patern Alfredo Milani 46


ABSTRACT FACTORY
 Esempio
 Javascript: varie tecniche di implementazione
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
Registro solamente
solamente gli
gli
} oggetti
oggetti che
che soddisfano
soddisfano
}; un
un contratto
contratto (abstract
(abstract
})(); product)
product)
Ingegneria del Sofware - Design Patern Alfredo Milani 47
ABSTRACT FACTORY
 Implementazione

 Solitamente si necessita di una sola istanza della


factory (Singleton design patern)

 Defnizione di factory estendiiili


 Aggiungere un parametro ai metodi di creazione dei prodotti
 Il parametro specifca il tpo di prodoto

 Nei linguaggi tpizzat statcamente è possiiile solo se tutti i

prodotti condividono la stessa interfaccia


 Può oiiligare a down cast pericolosi …

Ingegneria del Sofware - Design Patern Alfredo Milani 48


RIFERIMENTI
 Design Paterns, Elements of Reusaile Oiject
Oriented Sofware, GoF, 1995, Addison-Wesley
 Design Paterns

htp://sourcemaiing.com/design_paterns
 Java DP

htp://www.javacamp.org/designPatern/
 Exploring the Decorator Patern in Javascript

htp://addyosmani.com/ilog/decorator-patern
/
 Design Paterns in Scala htp://

pavelfatn.com/design-paterns-in-scala
 Item 2: Consider a iuilder when faced with
Ingegneria del Sofware - Design Patern Alfredo Milani 49

Potrebbero piacerti anche