I modelli di progettazione rappresentano le migliori pratiche utilizzate dagli sviluppatori di software orientati agli oggetti esperti. I modelli di progettazione sono soluzioni a problemi generali che gli sviluppatori di software hanno dovuto affrontare durante lo sviluppo del software. Queste soluzioni sono state ottenute per tentativi ed errori da numerosi sviluppatori di software per un periodo di tempo piuttosto considerevole.
Nel 1994, quattro autori Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides hanno pubblicato un libro intitolato Design Patterns - Elements of Reusable Object-Oriented Software che ha avviato il concetto di Design Pattern nello sviluppo del software. Questi autori sono noti collettivamente come Gang of Four (GOF).
I modelli di progettazione possono essere classificati in tre categorie: modelli creativi, strutturali e comportamentali.
Creational Patterns- Questi modelli di progettazione forniscono un modo per creare oggetti nascondendo la logica di creazione, piuttosto che istanziare oggetti direttamente utilizzando il nuovo opreator. Ciò offre al programma maggiore flessibilità nel decidere quali oggetti devono essere creati per un determinato caso d'uso.
Structural Patterns- Questi modelli di progettazione riguardano la composizione della classe e dell'oggetto. Il concetto di ereditarietà viene utilizzato per comporre interfacce e definire modi per comporre oggetti per ottenere nuove funzionalità.
Behavioral Patterns - Questi modelli di design riguardano specificamente la comunicazione tra gli oggetti.
Questi modelli di progettazione riguardano specificamente il livello di presentazione. Questi modelli vengono identificati da Sun Java Center.
Factory pattern è uno dei design pattern più utilizzati in Java. Questo tipo di modello di progettazione rientra nel modello di creazione poiché questo modello fornisce uno dei modi migliori per creare un oggetto.
In Factory pattern, creiamo oggetti senza esporre la logica di creazione al client e facciamo riferimento a oggetti appena creati utilizzando un'interfaccia comune.
I modelli di fabbrica astratti funzionano attorno a una super fabbrica che crea altre fabbriche. Questa fabbrica è anche chiamata fabbrica di fabbriche. Questo tipo di modello di progettazione rientra nel modello di creazione poiché questo modello fornisce uno dei modi migliori per creare un oggetto.
In Abstract Factory pattern un'interfaccia è responsabile della creazione di una factory di oggetti correlati senza specificare esplicitamente le loro classi. Ogni factory generata può fornire gli oggetti secondo il pattern Factory.
Il modello Singleton è uno dei modelli di progettazione più semplici in Java. Questo tipo di modello di progettazione rientra nel modello di creazione poiché questo modello fornisce uno dei modi migliori per creare un oggetto.
Questo modello coinvolge una singola classe che è responsabile della creazione di un oggetto assicurandosi che venga creato solo un singolo oggetto. Questa classe fornisce un modo per accedere al suo unico oggetto a cui è possibile accedere direttamente senza bisogno di istanziare l'oggetto della classe.
È un processo in due fasi. Innanzitutto, rendi privato il costruttore in modo che il nuovo operatore non possa essere utilizzato per istanziare la classe. Restituisce un oggetto dell'oggetto se non è nullo altrimenti crea l'oggetto e restituisci lo stesso tramite un metodo.
Di seguito sono riportate le differenze tra una classe statica e una classe singleton.
Una classe statica non può essere una classe di primo livello e non può implementare interfacce dove può farlo una classe singleton.
Tutti i membri di una classe statica sono statici ma per una classe Singleton non è un requisito.
Una classe statica viene inizializzata quando viene caricata in modo che non possa essere caricata pigramente dove una classe singleton può essere caricata pigramente.
Un oggetto di classe statica viene archiviato nello stack mentre un oggetto di classe singlton viene archiviato nello spazio di memoria dell'heap.
Sì.
Genera un'eccezione nel corpo del metodo clone ().
Di seguito sono riportati alcuni dei modelli di progettazione utilizzati nella libreria JDK.
Il patttern Decorator è usato dalle classi Wrapper.
Il pattern Singleton viene utilizzato da Runtime, classi Calendar.
Il modello di fabbrica viene utilizzato dalla classe Wrapper come Integer.valueOf.
Il pattern Observer viene utilizzato da framework di gestione degli eventi come swing, awt.
Il modello di fabbrica incapsula i dettagli dell'implementazione e l'implementazione sottostante può essere modificata senza alcun impatto sull'API del chiamante.
Il pattern Builder costruisce un oggetto complesso utilizzando oggetti semplici e utilizzando un approccio graduale. Questo builder è indipendente da altri oggetti.
Il modello prototipo si riferisce alla creazione di oggetti duplicati tenendo presente le prestazioni. Questo modello implica l'implementazione di un'interfaccia prototipo che dice di creare un clone dell'oggetto corrente.
Questo modello viene utilizzato quando la creazione di un oggetto direttamente è costosa. Ad esempio, un oggetto deve essere creato dopo una costosa operazione di database. Possiamo memorizzare l'oggetto nella cache, restituirne il clone alla richiesta successiva e aggiornare il database come e quando necessario riducendo così le chiamate al database.
Il modello dell'adattatore funziona come un ponte tra due interfacce incompatibili. Questo modello coinvolge una singola classe che è responsabile di unire funzionalità di interfacce indipendenti o incompatibili.
Un esempio di vita reale potrebbe essere un caso di lettore di schede che funge da adattatore tra la scheda di memoria e un laptop. Si collega la scheda di memoria al lettore di schede e il lettore di schede al laptop in modo che la scheda di memoria possa essere letta tramite il laptop.
Bridge viene utilizzato quando è necessario disaccoppiare un'astrazione dalla sua implementazione in modo che le due possano variare indipendentemente. Questo tipo di modello di progettazione rientra nel modello strutturale poiché questo modello disaccoppia la classe di implementazione e la classe astratta fornendo una struttura a ponte tra di loro.
Questo modello coinvolge un'interfaccia che funge da ponte che rende la funzionalità delle classi concrete indipendenti dalle classi implementatrici dell'interfaccia. Entrambi i tipi di classi possono essere modificati strutturalmente senza influenzarsi a vicenda.
Il modello di filtro o modello di criteri è un modello di progettazione che consente agli sviluppatori di filtrare una serie di oggetti utilizzando criteri diversi e concatenandoli in modo disaccoppiato tramite operazioni logiche. Questo tipo di modello di progettazione rientra nel modello strutturale poiché questo modello combina più criteri per ottenere criteri singoli.
Il pattern composito viene utilizzato quando è necessario trattare un gruppo di oggetti in modo simile come un singolo oggetto. Il modello composito compone gli oggetti in termini di una struttura ad albero per rappresentare una parte così come l'intera gerarchia. Questo tipo di modello di progettazione rientra nel modello strutturale poiché questo modello crea una struttura ad albero di un gruppo di oggetti.
Questo modello crea una classe che contiene un gruppo dei propri oggetti. Questa classe fornisce modi per modificare il suo gruppo di stessi oggetti.
Il motivo Decorator consente a un utente di aggiungere nuove funzionalità a un oggetto esistente senza alterarne la struttura. Questo tipo di modello di progettazione rientra nel modello strutturale poiché questo modello funge da involucro per la classe esistente.
Questo modello crea una classe decoratore che avvolge la classe originale e fornisce funzionalità aggiuntive mantenendo intatta la firma dei metodi di classe.
Il motivo della facciata nasconde le complessità del sistema e fornisce un'interfaccia al cliente tramite la quale il cliente può accedere al sistema. Questo tipo di modello di progettazione rientra nel modello strutturale poiché questo modello aggiunge un'interfaccia al sistema esistente per nascondere le sue complessità.
Questo modello coinvolge una singola classe che fornisce i metodi semplificati richiesti dal client e delega le chiamate ai metodi delle classi di sistema esistenti.
Il modello Flyweight viene utilizzato principalmente per ridurre il numero di oggetti creati e per ridurre l'ingombro della memoria e aumentare le prestazioni. Questo tipo di modello di progettazione rientra nel modello strutturale poiché questo modello fornisce modi per ridurre il numero di oggetti migliorando così la struttura degli oggetti dell'applicazione.
Il modello Flyweight cerca di riutilizzare oggetti simili già esistenti memorizzandoli e crea un nuovo oggetto quando non viene trovato alcun oggetto corrispondente.
Nel modello proxy, una classe rappresenta la funzionalità di un'altra classe. Questo tipo di modello di progettazione rientra nel modello strutturale.
Nel modello proxy, creiamo un oggetto con un oggetto originale per interfacciarne le funzionalità con il mondo esterno.
Come suggerisce il nome, il modello della catena di responsabilità crea una catena di oggetti riceventi per una richiesta. Questo modello disaccoppia mittente e destinatario di una richiesta in base al tipo di richiesta. Questo modello rientra nei modelli comportamentali.
In questo schema, normalmente ogni ricevitore contiene un riferimento a un altro ricevitore. Se un oggetto non è in grado di gestire la richiesta, passa la stessa al destinatario successivo e così via.
Il modello di comando è un modello di progettazione basato sui dati e rientra nella categoria del modello comportamentale. Una richiesta viene inserita in un oggetto come comando e passata all'oggetto invoker. L'oggetto Invoker cerca l'oggetto appropriato in grado di gestire questo comando e passa il comando all'oggetto corrispondente che esegue il comando.
Il pattern interprete fornisce un modo per valutare la grammatica o l'espressione della lingua. Questo tipo di modello rientra nel modello comportamentale. Questo modello implica l'implementazione di un'interfaccia di espressione che indica di interpretare un contesto particolare.
Questo modello viene utilizzato nell'analisi SQL, nel motore di elaborazione dei simboli ecc.
Il pattern Iterator è un design pattern molto comunemente usato negli ambienti di programmazione Java e .Net. Questo modello viene utilizzato per ottenere un modo per accedere agli elementi di un oggetto di raccolta in modo sequenziale senza alcuna necessità di conoscere la sua rappresentazione sottostante. Il modello iteratore rientra nella categoria del modello comportamentale.
Di seguito sono riportate le entità di questo tipo di design pattern.
Service- Servizio effettivo che elaborerà la richiesta. Il riferimento a tale servizio deve essere esaminato nel server JNDI.
Context / Initial Context - Il contesto JNDI contiene il riferimento al servizio utilizzato a scopo di ricerca.
Service Locator - Service Locator è un unico punto di contatto per ottenere servizi tramite ricerca JNDI memorizzando nella cache i servizi.
Cache - Cache per memorizzare i riferimenti dei servizi per riutilizzarli.
Client - Client è l'oggetto che richiama i servizi tramite ServiceLocator.
Il modello mediatore viene utilizzato per ridurre la complessità della comunicazione tra più oggetti o classi. Questo modello fornisce una classe mediatore che normalmente gestisce tutte le comunicazioni tra classi diverse e supporta una facile manutenzione del codice mediante accoppiamento libero. Il modello del mediatore rientra nella categoria del modello comportamentale.
Il motivo Memento viene utilizzato per ripristinare lo stato di un oggetto a uno stato precedente. Il pattern Memento rientra nella categoria dei pattern comportamentali.
Lo schema Memento utilizza tre classi di attori. Memento contiene lo stato di un oggetto da restaurare. Il creatore crea e memorizza gli stati negli oggetti Memento e l'oggetto Caretaker è responsabile del ripristino dello stato dell'oggetto da Memento.
Il pattern osservatore viene utilizzato quando esiste una relazione uno-a-molti tra gli oggetti, ad esempio se un oggetto viene modificato, i suoi oggetti dipendenti devono essere notificati automaticamente. Il modello dell'osservatore rientra nella categoria del modello comportamentale.
Il pattern Observer utilizza tre classi di attori. Soggetto, osservatore e cliente. Il soggetto è un oggetto dotato di metodi per collegare e scollegare gli osservatori a un oggetto client. Abbiamo creato una classe astratta Observer e una classe concreta Subject che estende la classe Observer.
Nel modello State il comportamento di una classe cambia in base al suo stato. Questo tipo di modello di progettazione rientra nel modello di comportamento. In State pattern, creiamo oggetti che rappresentano vari stati e un oggetto contesto il cui comportamento varia al variare del suo oggetto di stato.
In Null Object pattern, un oggetto null sostituisce il controllo dell'istanza dell'oggetto NULL. Invece di mettere if check per un valore nullo, Null Object riflette una relazione non fare nulla. Tale oggetto Null può essere utilizzato anche per fornire un comportamento predefinito nel caso in cui i dati non siano disponibili.
In Null Object pattern, creiamo una classe astratta che specifica varie operazioni da eseguire, classi concrete che estendono questa classe e una classe di oggetto null che non fornisce alcuna implementazione di questa classe e verrà utilizzata in modo invisibile quando è necessario controllare il valore null.
In Strategy pattern, il comportamento di una classe o il suo algoritmo possono essere modificati in fase di esecuzione. Questo tipo di modello di progettazione rientra nel modello di comportamento.
In Strategy pattern, creiamo oggetti che rappresentano varie strategie e un oggetto contesto il cui comportamento varia in base al suo oggetto strategia. L'oggetto strategia cambia l'algoritmo di esecuzione dell'oggetto contesto.
In Template pattern, una classe astratta espone modi / modelli definiti per eseguire i propri metodi. Le sue sottoclassi possono sovrascrivere l'implementazione del metodo secondo le necessità, ma l'invocazione deve essere nello stesso modo definito da una classe astratta. Questo modello rientra nella categoria del modello di comportamento.
Nel pattern Visitor, usiamo una classe Visitor che cambia l'algoritmo di esecuzione di una classe element. In questo modo, l'algoritmo di esecuzione dell'elemento può variare al variare del visitatore. Questo modello rientra nella categoria del modello di comportamento. Secondo il modello, l'oggetto elemento deve accettare l'oggetto visitatore in modo che l'oggetto visitatore gestisca l'operazione sull'oggetto elemento.
Pattern MVC è l'acronimo di Model-View-Controller Pattern. Questo modello viene utilizzato per separare le preoccupazioni dell'applicazione.
Model- Il modello rappresenta un oggetto o un POJO JAVA che trasporta dati. Può anche avere una logica per aggiornare il controller se i suoi dati cambiano.
View - Visualizza rappresenta la visualizzazione dei dati contenuti nel modello.
Controller- Il controller agisce sia sul modello che sulla vista. Controlla il flusso di dati nell'oggetto del modello e aggiorna la vista ogni volta che i dati cambiano. Mantiene vista e modello separati.
Il modello delegato aziendale viene utilizzato per separare il livello di presentazione e il livello aziendale. Fondamentalmente viene utilizzato per ridurre la comunicazione o la funzionalità di ricerca remota al codice di livello aziendale nel codice del livello di presentazione. Nel livello aziendale abbiamo le seguenti entità.
Client - Il codice del livello di presentazione può essere JSP, servlet o codice java dell'interfaccia utente.
Business Delegate - Una singola classe di punto di ingresso per le entità client per fornire l'accesso ai metodi del servizio aziendale.
LookUp Service - L'oggetto del servizio di ricerca è responsabile di ottenere l'implementazione aziendale relativa e fornire l'accesso agli oggetti di business all'oggetto delegato di business.
Business Service- Interfaccia del servizio aziendale. Le classi concrete implementano questo servizio aziendale per fornire una logica di implementazione aziendale effettiva.
Il modello di entità composita viene utilizzato nel meccanismo di persistenza EJB. Un'entità Composite è un bean di entità EJB che rappresenta un grafico di oggetti. Quando un'entità composita viene aggiornata, i bean di oggetti dipendenti internamente vengono aggiornati automaticamente come gestiti dal bean di entità EJB. Di seguito sono riportati i partecipanti a Composite Entity Bean.
Composite Entity- È il bean di entità primaria. Può essere a grana grossa o può contenere un oggetto a grana grossa da utilizzare a scopo di persistenza.
Coarse-Grained Object- Questo oggetto contiene oggetti dipendenti. Ha un proprio ciclo di vita e gestisce anche il ciclo di vita degli oggetti dipendenti.
Dependent Object - L'oggetto dipendente è un oggetto che dipende da un oggetto a grana grossa per il suo ciclo di vita di persistenza.
Strategies - Strategies rappresenta come implementare un'entità composta.
Il modello di oggetto di accesso ai dati o il modello DAO viene utilizzato per separare l'API o le operazioni di accesso ai dati di basso livello dai servizi aziendali di alto livello. Di seguito sono riportati i partecipanti a Data Access Object Pattern.
Data Access Object Interface - Questa interfaccia definisce le operazioni standard da eseguire su uno o più oggetti del modello.
Data Access Object concrete class- Questa classe implementa l'interfaccia sopra. Questa classe è responsabile per ottenere i dati da un'origine dati che può essere database / xml o qualsiasi altro meccanismo di archiviazione.
Model Object or Value Object - Questo oggetto è un semplice POJO contenente metodi get / set per memorizzare i dati recuperati utilizzando la classe DAO.
Il modello di progettazione del front controller viene utilizzato per fornire un meccanismo di gestione delle richieste centralizzato in modo che tutte le richieste vengano gestite da un unico gestore. Questo gestore può eseguire l'autenticazione / autorizzazione / registrazione o il monitoraggio della richiesta e quindi passare le richieste ai gestori corrispondenti. Di seguito sono riportate le entità di questo tipo di design pattern.
Front Controller - Unico gestore per tutti i tipi di richieste in arrivo all'applicazione (sia web che desktop).
Dispatcher - Front Controller può utilizzare un oggetto dispatcher che può inviare la richiesta al corrispondente gestore specifico.
View - Le viste sono l'oggetto per il quale vengono effettuate le richieste.
Il pattern di progettazione del filtro di intercettazione viene utilizzato quando si desidera eseguire una pre-elaborazione / post-elaborazione con richiesta o risposta dell'applicazione. I filtri vengono definiti e applicati alla richiesta prima di passare la richiesta all'effettiva applicazione di destinazione. I filtri possono eseguire l'autenticazione / autorizzazione / registrazione o il monitoraggio della richiesta e quindi passare le richieste ai gestori corrispondenti.
Di seguito sono riportate le entità di questo tipo di design pattern.
Filter - Filtro che esegue determinate attività prima o dopo l'esecuzione della richiesta da parte del gestore delle richieste.
Filter Chain - Filter Chain trasporta più filtri e aiuta a eseguirli in un ordine definito sul target.
Target - L'oggetto di destinazione è il gestore delle richieste.
Filter Manager - Filter Manager gestisce i filtri e la catena di filtri.
Client - Client è l'oggetto che invia la richiesta all'oggetto Target.
Il modello di progettazione del localizzatore di servizi viene utilizzato quando si desidera individuare vari servizi utilizzando la ricerca JNDI. Considerando l'elevato costo della ricerca di JNDI per un servizio, il pattern Service Locator utilizza la tecnica di memorizzazione nella cache. Per la prima volta che è richiesto un servizio, Service Locator cerca in JNDI e memorizza nella cache l'oggetto servizio. Un'ulteriore ricerca o lo stesso servizio tramite Service Locator viene eseguita nella sua cache, il che migliora notevolmente le prestazioni dell'applicazione.
Il pattern Transfer Object viene utilizzato quando vogliamo passare dati con più attributi in un colpo solo da client a server. L'oggetto di trasferimento è noto anche come oggetto valore. Transfer Object è una semplice classe POJO con metodi getter / setter ed è serializzabile in modo da poter essere trasferita sulla rete. Non ha alcun comportamento. La business class lato server normalmente recupera i dati dal database e riempie il POJO e lo invia al client o lo passa per valore. Per il client, l'oggetto di trasferimento è di sola lettura. Il cliente può creare il proprio oggetto di trasferimento e passarlo al server per aggiornare i valori nel database in un colpo solo. Di seguito sono riportate le entità di questo tipo di design pattern.
Business Object - Il servizio aziendale riempie l'oggetto di trasferimento con i dati.
Transfer Object - POJO semplice con metodi per impostare / ottenere solo attributi.
Client - Il cliente richiede o invia l'oggetto di trasferimento all'oggetto business.