Composite

Intento:

Comporre gli oggetti in strutture ad albero al fine di rappresentare una parte dell’intera struttura. Tale pattern permette ai Clients di trattare i singoli oggetti e la composizione degli stessi in modo uniforme.

Applicabilità:

E’ utile sfruttare il pattern Composite nel caso in cui

• si voglia rappresentare una parte dell’intera gerarchia di oggetti
• si vuole che i Clients ignorino le differenze fra la composizione degli oggetti ed i singoli oggetti. I Clients tratteranno tutti gli oggetti nella struttura composta in modo uniforme

Partecipanti:

• Component → dichiara l’interfaccia degli oggetti nella fase di composizione, implementa il comportamento di default per l’interfaccia comune delle classi se è il caso, dichiara un’interfaccia al fine di accedere e gestire i componenti figli ed infine opzionale, definisce un’interfaccia per accedere ai genitori del componente all’interno della struttura ricorsiva e la implementa, sempre se è il caso.
• Leaf → rappresenta i cosiddetti “oggetti foglia” nella composizione. Tali oggetti non hanno figli, definisce il comportamento per gli oggetti di primitive nella composizione
• Composite → definisce il comportamento per quei componenti che hanno figli, immagazzina i componenti figli, implementa le operazioni relazionate ai figli all’interno della interfaccia Component
• Client → manipola gli oggetti presenti nella composizione attraverso l’interfaccia Component

Conseguenze:

• Viene definita una classe gerarchica composta da oggetti di primitive e oggetti composti
• Il Client è più semplice
• E’ facile aggiungere nuovi tipi di componenti
• Può essere che lo schema divenga troppo generale

Bridge

Intento:

Disaccoppiare l’astrazione dalla sua implementazione in modo tale che le due parti possano variare indipendentemente.

Applicabilità:

E’ utile sfruttare il pattern Bridge quando

• si vuole evitare un legame permanente fra implementazione ed astrazione. Per esempio implementazioni che devono essere cambiate a run-time
• sia le astrazioni che le implementazioni potrebbero essere estese dalla sotto-classificazione
• si vuole che cambiamenti a livello di implementazione non abbiano effetto sui Client
• (caso del C++) si vuole nascondere l’implementazione ai Client
• c’è una proliferazione di classi, e la gerarchia indica il bisogno di spezzare l’oggetto in due parti.
• si vuole condividere una implementazione per vari oggetti, e tale implementazione potrebbe essere nascosta ai Client

Partecipanti:

• Abstraction → definisce l’interfaccia dell’astrazione e mantiene il riferimento verso un oggetto di tipo Implementor
• RefinedAbstraction → estende l’interfaccia definita da Abstraction
• Implementor → definisce l’interfaccia per le classi di implementazione. Tale interfaccia non deve corrispondere appieno alla interfaccia di Abstraction. Solitamente l’interfaccia di Implementor fornisce solo le operazioni primitive, e Abstraction definisce operazioni di alto livello che sfruttano tali primitive.
• ConcreteImplemetor → implementa l’interfaccia di Implementor e definisce la sua concreta implementazione.

Conseguenze:

• c’è il disaccoppiamento fra implementazione e interfaccia
• viene accresciuta la capacita di estensione
• vengono nascosti i dettagli dell’implementazione ai Client

Adapter

Intento:

Convertire l’interfaccia di una classe in una nuova più conforme a ciò che il Client si aspetta.

Adapter permette a classi non omogenee di lavorare in simbiosi anche se le loro interfacce sono incompatibili.

Applicabilità:

Tale pattern è da utilizzare nel caso in cui

• si vuole utilizzare una classe esistente e la sua interfaccia non coincide con ciò di cui abbiamo bisogno
• si vuole creare una classe riutilizzabile che possa cooperare con classi non relazionate o impreviste, cioè classi che non possiedono necessariamente delle interfacce compatibili
• (Adapter solo a livello di oggetto) si vuole sfruttare alcune classi esistenti, ma non è conveniente adattare le loro interfacce creando sottoclassi. Un oggetto di tipo Adapter è in grado di adattare le interfacce delle classi padre.

Partecipanti:

• Target → definisce l’interfaccia specifica per il dominio di interesse che il Client si aspetta
• Client → collabora con gli oggetti conformi alla interfaccia Target
• Adaptee → definisce una interfaccia esistente che ha bisogno di essere adattata
• Adapter → adatta l’interfaccia dell’Adaptee all’interfaccia del Target

Conseguenze:

E’ lecito in questa fase distinguere fra Adapter a livello di classe e di oggetto, dato che portano a conseguenza ben diverse.

Cominciamo dal livello di classe:

• una classe di tipo Adapter non può lavorare nel caso in cui si volesse adattare una classe e tutte le sue sottoclassi
• se lasciamo che Adapter sovrascriva alcuni comportamenti di Adaptee , allora Adapter è una sottoclasse di Adaptee

A livello di oggetto:

• è possibile che un singolo Adapter lavori con molti Adaptee
• diventa più difficile sovrascrivere il comportamento del Adapter

Altre considerazioni più generali possono essere riassunte in questi tre ultimi punti:

• Adapter può adattarsi ad un numero variabile di Target
• Si possono utilizzare degli adattatori cosiddetti Pluggable, in gradi di ospitare metodi per rendere adattabili diverse classi
• Si possono utilizzare adattatori a due vie per rendere il processo di adattamento molto più trasparente

Structural Patterns

I pattern di tipo strutturale si concentrano sul modo in cui classi ed oggetti vengono composti per generare delle strutture più grandi. I pattern strutturali a livello di classe sfruttano l’ereditarietà per comporre le interfacce o le implementazioni, mentre quelli a livello di oggetto descrivono le soluzioni per comporre oggetti al fine di realizzare nuove funzionalità.

Ecco l’elenco dei pattern che analizzeremo:

• Adapter
• Bridge

• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Apache – Virtual Host

Il termine Virtual Host si riferisce alla pratica di eseguire più di un sito su una singola macchina server. Esistono due tipi di virtualizzazioni:

1. basata su IP → ogni sito possiede un indirizzo IP differente, anche se risiede sulla medesima macchina
2. basata sui nomi → esistono più siti diversi che soggiornano sulla medesima macchian con lo stesso indirizzo IP

Apache – URL Rewriting

mod_rewrite sfrutta le proprie capacità di riscrittura, basate sulle espressioni regolari, per riscrivere URL al volo .

Il modulo in questione è in grado di lavorare sia a livello server (specificando le configurazioni nel file httpd.conf) oppure in un contesto di directory (grazie al file .htaccess) ed è in grado perfino di generare parti di query-string.

La documentazione del modulo si basa interamente sulle funzionalità e la potenza delle espressioni regolari, che di seguito illustreremo in modo semplice e veloce. Ricordo che le espressioni regolari non sono uno strumento facile da digerire, per poter sfruttare a pieno le potenzialità dello strumento è necessaria molta pratica ed esercizio.

Apache – suEXEC

La caratteristica suExec permette al servizio apache di eseguire script CGI e SSI con user e group ID differenti rispetto a quello con cui viene eseguito di norma il servizio apache2. Se non c’è installato suExec gli script CGI o SSI vengono eseguiti dall’utente con il quale viene eseguito il web server.

Usato in modo adeguato suExec rende molto più sicura e stabile la struttura del nostro webServer. Nel caso in cui venga utilizzato impropriamente crea più danni che benefici. Il consiglio quindi è quello di utilizzare questa caratteristica solo se si conoscono in maniera adeguata gli strumenti sui quali si sta lavorando, ovvero:

• Web Server
• Script CGI
• Permessi a livello di filesystem
• Gestione degli utenti

Apache SSL/TLS – Secure Sockets Layer

Il protocollo SSL è un protocollo posto fra il livello di connessione orientata affidabile (TCP/IP) e il livello applicazione (HTTP) all’interno dello stack dei protocolli TCP/IP , SSL fornisce una comunicazione sicura fra client e server permettendo una mutua autenticazione grazie all’utilizzo di firme digitali per assicurare l’integrità e la crittografia per garantire la privatezza del dato.

Il Protocollo è disegnato per supportare un vaso numero di opzioni per specifici algoritmi utilizzati per la crittografia, la firma e l’hashing. Le scelte vengono negoziate fra il client e il server quando viene stabilita la connessione.

Apache SSL/TLS – certificati

Oltre a inviare un messaggio privato verso la banca, con la propria firma al fine di assicurare l’integrità del messaggio stesso, Alice deve essere sicura di essere in comunicazione con la banca. Questo significa che Alice deve essere sicura che la chiave pubblica utilizzata per criptare il messaggio sia effettivamente fornita dalla banca e non da un malintenzionato. Allo stesso modo la banca deve poter verificare che la firma sia stata effettivamente firmata con la chiave privata di Alice.

Se ognuna delle due parti (banca e Alice) possiedono un certificato convalidato da una terza entità, che conferma le chiavi pubbliche e firmato dalla stessa agenzia, allora è assicurato che la comunicazione avvenga effettivamente fra le due parti in causa. La terza entità appena definita viene detta Certificate Authority e i certificati vengono utilizzati per autenticarsi

Apache SSL/TLS – le basi

Il modulo mod_ssl fornisce una interfaccia per le librerie OpenSSL, che forniscono un alto livello di cifratura dei dati utilizzando SSL (Secure Socket Layer)e TLS(Transport Layer Security).

In questa serie di articoli tratteremo nel dettaglio sia le librerie SSL sia il modo in cui apache stesso si interfaccia con questi strumenti che permettono un alto livello di sicurezza nelle comunicazioni.

Per capire SSL è necessario avere una idea di cosa significhi un algoritmo crittografico, una funzione di hash, una firma digitale. Di seguito introdurremo questi concetti grazie a definizioni ed esempi.