Author Archives: admin

Programmazione – Builder Design Pattern

14 Oct, 2017
admin
No Comments

Il Builder, ovvero il “costruttore” (da non confondersi con il metodo), è uno dei principali design pattern formalizzati dalla gang of four e si occupa di separare la costruzione di un oggetto dalla sua rappresentazione, in modo che il processo di costruzione degli oggetti sia in grado di creare molteplici rappresentazioni dello stesso.

Lo scopo dell’applicazione del design pattern Builder, è principalmente quello di separare il processo di creazione di un oggetto complesso dal flusso applicativo del client. Seguendo questa logica, si realizza una doppia astrazione: da una parte si rende indipendente il flusso di creazione e controllo di un oggetto dal client, dall’altra, l’algoritmo per la creazione di un oggetto è indipendente dalle varie parti che lo costituiscono e da come esse vengono assemblate.

Il design pattern Builder si rende applicabile quando
è necessario costruire un oggetto step by step
è auspicabile isolare il processo di creazione e rappresentazione di un oggetto
è necessario monitorare le fasi del processo di creazione
Queste sono le principali conseguenze dell’applicazioni del pattern:

Isolamento delle classi che costituiscono le parti (step): come già detto in precedenza, seguendo questo pattern, si isolano e si rendono indipendenti dall’algoritmo di creazione dell’oggetto, le classi deputate all’implementazione delle parti che lo costituiranno.
Separazione della logica di creazione degli oggetti dall’applicazione: è lo scopo principale del pattern.

Passando attraverso il Director, verrà richiamato il Builder, l’interfaccia deputata ad assemblare le varie parti dell’oggetto da creare la quale, a sua volta, delegherà al ConcreteBuilder il lavoro vero e proprio, definendolo nei suoi aspetti e tenendone traccia. Il Product, l’oggetto finale che verrà costruito, conterrà al suo interno le classi che costituiscono le parti che lo compongono.

Come Collegare Pc al Proiettore

14 Aug, 2017
admin
No Comments

Quanti di voi necessitano di presentare il proprio lavoro, presentazioni, documenti e filmati ad una videoconferenza o semplicemente ad una lezione formativa? Bene in questa guida spiegheremo come collegare facilmente il nostro Notebook o Personal Computer ad un videoproiettore senza l’aiuto di un assistente tecnico.

La prima cosa da fare è posizionare il telo per la proiezione su una parete, o semplicemente scegliere una parete bianca dove posizionerai frontalmente il tuo proiettore. Bisogna posizionare il proiettore su una superficie piana regolando i bene i supporti posti inferiormente, in modo che sia in equilibrio e l’immagine non venga proiettata storta. Calcola bene le distanze tra la posizione del proiettore, Notebook e la parete.

Infatti il più delle volte ci si insorge in una situazione in cui l’immagine del nostro proiettore è troppo grande e non rientrerà nel telo, o il cavetto per collegarlo al Notebook è troppo corto per raggiungerlo nella sua postazione.Generalmente i proiettori utilizzano cavi VGA e DVI, basterà semplicemente controllare il nostro Pc se possiede una di queste due porte e collegarlo al proiettore mediante il cavo in dotazione. Ovviamente i proiettori possono offrire anche altri tipi di connettività. Per dettagli è possibile vedere questa guida sul proiettore su Sceltatech.com.

Una volta fatto questo, accendere il video proiettore e iniziare a regolare l’immagine, se necessario (fuoco,dimensione,colori,luminosità). Successivamente, bisogna impostare dal nostro PC il segnale video da proiettare. Per gli utenti windows, bisognerà aprire il pannello di controllo e scrivere nella barra di ricerca “Proiettore”, scegliere quindi “Connetti ad un proiettore”. Vedrete tante finestrelle, “Duplica”, “Estendi”, “Solo proiettore”, “Solo Computer”. Scegli l’opzione “Solo proiettore”, fatto ciò l’immagine presente nel vostro PC sarà proiettata dal videoproiettore.

Programmazione – Lazy Initialization Design Pattern

14 Jun, 2017
admin
No Comments

La Lazy initialization, ovvero inizializzazione pigra, è una tattica che prevede l’istanziazione un oggetto, inizializzazione di una variabile, lo svolgimento di un calcolo piuttosto che l’esecuzione di un processo esclusivamente nel momento in cui tale operazione è richiesta.

Lo scopo di questo pattern, è legato al miglioramento delle performance di un applicativo.

Come si può dedurre quindi, la Lazy initialization si rende applicabile nei seguenti casi:

ritardare un’operazione costosa fino a quando è assolutamente necessario svolgerla
memorizzare il risultato di operazioni complesse in modo da non doverle svolgerle nuovamente
Le immediate conseguenze dell’applicazione di questo pattern, sono quindi espresse dalla logica alla base del pattern stesso. Ottimizzare le operazioni costose, rendendole pigre e tenendo memorizzati i risultati dell’elaborazione ove fossero presenti.

Come ovvio il miglioramento delle performance che si ottiene applicando questo pattern (ove ce ne fosse), è strettamente legato alle caratteristiche del problema e a volte può non essere significativo. Come per ogni ottimizzazione, questa tecnica dovrebbe essere utilizzata solo se c’è un beneficio evidente.

Di solito, il pattern viene implementato memorizzando in un flag l’avvenimento di un determinato processo. Ogni volta che avviene un certo evento, si esamina il flag. Se il flag è settato a false, si continua, altrimenti si inizializza una certa variabile o si istanzia un certo oggetto.

Programmazione – Prototype Design Pattern

14 Apr, 2017
admin
No Comments

L’utilizzo di questo pattern permette la creazione di nuovi oggetti a partire da un oggetto iniziale, detto appunto prototipo. A differenza di altri pattern permette di specificare nuovi oggetti a run time, utilizzando un gestore di prototipi per salvare e reperire dinamicamente le istanze degli oggetti desiderati.

Come per gli altri pattern creazionali, lo scopo dell’applicazione del design pattern Prototype, è principalmente quello di separare il processo di creazione di un oggetto complesso dal flusso applicativo del client.

Il pattern Prototype risulta molto utile nei seguenti casi:

gli oggetti da creare sono noti soltanto a run-time per cui un codice statico non sarebbe utile.
quando desideriamo che le istanze di una classe abbiano un set limitato di stati per cui rimane più conveniente effettuare una clonazione di un prototipo corrispondente piuttosto che costruire manualmente l’oggetto ogni volta.
Le conseguenze dell’applicazione del pattern Prototype sono le seguenti:

Indipendenza dal metodo di creazione: il client utilizza soltanto l’interfaccia fornita dal pattern, disinteressandosi di cosa viene invocato e di come si realizza il processo di creazione.
Modularità a run-time: questa caratteristica consente ai client la possibilità di aggiungere un prodotto a run-time, rendendolo disponibile per la clonazione da parte di altri client. L’utilizzo di questa feature è delegata al prototype manager il quale è in grado di registrare e gestire un nuovo prodotto.

Definizione di nuovi oggetti tramite nuove rappresentazioni: quando si devono definire numerosi oggetti, che si distinguono esclusivamente per i valori che assumono le loro variabili interne, è molto più comodo effettuare una clonazione e impostare la configurazione desiderata piuttosto che costruire gli oggetti manualmente.
Definizione di nuovi oggetti modificandone la struttura: l’utilizzo di prototipi, nelle applicazioni che necessitano di oggetti composti da più parti ne facilitano la creazione e la gestione.
Non proliferazione delle sottoclassi: a differenza di altri pattern, nei quali è necessario creare un factory method e una gerarchia di classi corrispondenti a prodotti diversi, in questo caso occorre soltanto comporre struttura e valori.

L’implementazione di questo pattern prevede tre tipi di problematiche
l’implementazione di un gestore di prototipi, che sia in grado tramite una struttura associativa, di gestire la clonazione dei prototipi esistenti e di permettere l’aggiunta e la memorizzazione di nuovi prototipi.
l’implementazione di una copia profonda degli oggetti, che si occupi di clonare anche gli eventuali oggetti interni.
la predisposizione di un operazione di inizializzazione all’interno dei prototipi, che consenta di inizializzare in modo differente oggetti creati attraverso la clonazione.

Molto interessante.

Programmazione – Abstract Factory Design Pattern

14 Feb, 2017
admin
No Comments

L’Abstract Factory, ovvero fabbrica astratta, è uno dei fondamentali design pattern. Questo pattern si occupa di fornire al programmatore un interfaccia per la creazione di oggetti connessi tra loro, senza che lo stesso debba interessarsi della logica implementativa riguardante la creazione degli stessi.

Lo scopo principale di questo pattern quindi, è quello di realizzare una certa indipendenza dei client dagli oggetti che utilizzano, nella misura in cui possono creare e utilizzare diverse famiglie di oggetti senza conoscerne i dettagli.

Il pattern Abstract Factory risulta molto utile nei seguenti casi

si vuole mantenere una stretta indipendenza dei client dalle modalità con le quali gli oggetti vengono gestiti
è necessario poter configurare il sistema scegliendo tra diverse famiglie di oggetti
occorre fornire una libreria di classi nascondendone però l’implementazione
si vuole vincolare determinate famiglie di oggetti a utilizzare oggetti della medesima famiglia
Queste sono le principali conseguenze dell’applicazione del pattern:

Isolamento delle classi concrete: la factory viene utilizzata dai client esclusivamente tramite la sua interfaccia, realizzando di fatto la massima indipendenza dalle implementazioni dei prodotti. I client per poter utilizzare i prodotti che la fabbrica restituisce, avranno a disposizione le interfacce AbstractProduct.
Facilità di modifica della famiglia dei prodotti: visto che la ConcreteFactory viene istanziata una sola volta, basta predisporre un meccanismo di modifica a run-time della ConcreteFactory e saremo in grado di lavorare con un altra famiglia di prodotti.
Corenza nell’utilizzo dei prodotti: consente a dei prodotti appositamente progettati per lavorare assieme, di rispettare questo vincolo.
Come si può osservare dallo schema sottostante, l’AbstractFactory dichiara l’interfaccia per le operazioni che creano i prodotti astratti e le ConcreteFactory implementano le operazioni necessarie alla costruzione degli oggetti.

Da notare come nello schema, sono presenti anche le classi AbstractProduct e le classi ConcreteProduct. Le prime rappresentano l’interfacce generiche e astratte del prodotto, mentre le seconde saranno le classi delegate all’implementazione dei prodotti e alla loro costruzione.

In generale, per applicare questo pattern correttamente, occorre creare una sola istanza di ConcreteFactory (mediante il pattern Singleton), la quale si occuperà a sua volta di gestire il processo di creazione di una sola famiglia di oggetti, sebbene seguendo delle implementazioni specifiche.

La creazione dei prodotti viene delegata alla ConcreteFactory tramite un metodo apposito denominato Factory Method il quale, richiamato dall’interfaccia, sarà però necessariamente implementato nelle ConcreteFactory.

Se volessimo, perciò, creare oggetti di un’altra famiglia bisognerebbe creare ed istanziare un’altra factory.