Design Patterns, vestiti nuovi dell'imperatore e Catch 22

Durante la scrittura di questo blog una delle cose che faccio prima metaforicamente mettere nero su bianco è quello di verificare quello che sto per scrivere è corretto e faccio di solito che da una verifica di un libro di testo o guardare su Internet. Ora, il mio ultimo blog ha descritto il pattern Strategy e, naturalmente ho ricontrollato che non stavo presentando il modello Ponte che ha un diagramma UML che è molto similarl alla strategia . In questo modo mi venne in mente che la Gang Of Four (GOF), modelli di progettazione sono stati in giro di pochi anni (ancora una volta I ricontrollato Design Patterns: Elements of ReusableObject-Oriented Software da parte della Gang of Four: Erich Gamma , Richard Helm, Ralph Johnson , John Vlissides stato pubblicato nel 1994) e che nel corso degli anni queste idee sono state copiate e ripubblicato in numerosi blog e su una moltitudine di siti web. E allora mi venne in mente che se questi modelli sono stati intorno per tanto tempo, allora perché non è che non sono così ben noti e più ampiamente utilizzato su base giornaliera?

I modelli sono 'famosi' e praticamente tutti quelli che si imbatte in loro pensa che sono una grande idea.Così, anche se mi piacciono i design pattern GoF ho pensato che sarebbe una buona idea per capire se ci sono problemi con il loro utilizzo. Sono buono come si pensa? Oppure è solo che gli sviluppatori pensano di essere cool: un caso di I vestiti nuovi dell'imperatore ? Per cercare di rispondere a questo ho pensato di scoprire se altre persone pensavano che ci fossero problemi con il Design Patterns.Naturalmente, ho chiesto a Google per qualche aiuto e si avvicinò con un paio di motivi abbastanza accademici / teorica sui motivi per cui design pattern sono cattivi. La prima ragione che ho trovato è stata l'idea che i modelli di progettazione nascono a causa di difetti o limitazioni all'interno di un language1 programmazione. Questo è probabilmente vero, come sottolinea Jeff Atwood nel suo blog Are Design Patterns Come evolve il linguaggio? molte caratteristiche del linguaggio che noi diamo per scontate iniziato come modelli in assembler e C. Mi chiedo se questo è davvero un problema? Le lingue possono essere migliorate e, anche se solo migliorare passo di lumaca, i modelli vengono utilizzati per colmare le lacune. Un esempio qui sarebbe l'introduzione di Java per ogni ciclo che sostituisce l'uso del modello iteratore ingombrante:

01.pubblica doppio calcTotalCost () {

02. 

03.doppia totale = 0,0 ;

04.per (articolo Articolo: articoli) {

05.totale + = item.getPrice ();

06.}

07. 

08.ritorno totale;

09.}

Un altro argomento che ho trovato contro di design pattern GoF è che alcuni modelli possono portare a codice per i quali è difficile scrivere unit test - il primo esempio citato è stato il pattern Singleton in quanto è molto difficile prendere in giro una statica singleton, il che è vero: vedere i miei blogs sull'uso PowerMock . D'altra parte alcuni modelli di effettuare test più facile. Il mio ultimo blog ha riguardato ilpattern Strategy , che permette di modificare il comportamento degli oggetti, iniettando oggetti di strategia. Se si può iniettare strategia oggetti reali, allora si può facilmente iniettare quelle finte per i test.La terza ragione che ho trovato contro l'uso di modelli di progettazione è stato perché l'idea di un design pattern è un tentativo di standardizzare quelli che sono già accettato le migliori pratiche, si provocano spesso la duplicazione inutile di codice in cui c'è quasi sempre una soluzione più efficiente utilizzando un ben fattorizzato esecuzione piuttosto che uno "appena sufficiente" design pattern.2 Questa è una cosa sono d'accordo con quanto a me suggerisce che design pattern sono un errore perché sono utilizzati impropriamente e questo mi porta su una delle mie idee sui modelli di progettazione limitazioni. io, come programmatore duro lavoro itinerante, pensa che se ci sono problemi con i design pattern, allora ' ri generalmente più pratico in natura. Bisogna ricordare che ci sono 22 modelli di GoF suddivisi in tre categorie: creativi, strutturali e comportamentali. Per utilizzare questi modelli in modo efficace bisogna essere in grado di ricordarle tutte, e non mi riferisco solo che devono ricordare i loro nomi, si hanno anche per ricordare quello che fanno. Considerate questo piccolo test: senza fare riferimento ad internet, libri , ecc dalla memoria: 1) Come molti dei 22 pattern GoF si può nominare? 2) Quanti di quelli che di nome si può disegnare il diagramma UML per l'? 3) Quanti di quelli che di nome si può implementare senza far riferimento alla documentazione? confrontino le risposte con il numero di anni di esperienza hai e pensa a quanti anni ci è voluto ad ottenere, per quanto avete fatto ... ... il punto è che non è un'impresa facile ricordare tutti i modelli e poi mantenere . freschi nella vostra memoria pronto a tirar fuori un avviso di momenti Avendo appreso un certo numero di modelli è inoltre necessario individuare quando e dove si utilizzano: c'è in quel punto la vostra giornata di codifica quando sei al al posto certo il vostro pensiero logico e dici a te stesso: "sì Ho bisogno del pattern Observer" o "ah-ha il pattern Decorator si adatta molto bene qui" ... il punto è che macchia quando è opportuno applicare un modello è probabilmente più difficile che imparare loro. Credo che la maggior parte delle persone sono d'accordo con l'idea che si dovrebbe utilizzare il metodo più semplice possibile per ottenere il lavoro fatto, ma la maggior parte dei modelli sono abbastanza complesse, e complesso al punto che non si vuole veramente modelli inutilmente a saltar fuori in il vostro codice. blog Coding Horror Jeff Atwood su O'Reilly testa First Design Patterns lo riassume bene dove dice che consente agli sviluppatori inesperti di sperimentare con i modelli è "quanto di sicuro come incoraggiarli a 'sperimentare' con uno alimentato a gas motosega" . Ed è qui che la logica loop su se stesso: si consiglia di utilizzare l'approccio più semplice possibile per risolvere il tuo problema, Design Patterns sono complesse, quindi non sarà utilizzato molto spesso. In non utilizzando Design Pattern non avrete mai la possibilità di impararle. Se non li imparare, poi quando si utilizza un modello di progettazione è l'approccio più semplice al tuo problema, non si sa come usarlo.E 'questo' Catch 22 '? Infine, stavo per sottolineare che i modelli GoF sono utilizzati in tutto il SDK Java, ma qualcuno mi ha già battuto per questa idea e quindi se siete interessati vi consiglio di consultareStack Overflow .

Corso Java - Corsi Java - Corsi programmazione Java

 Corso programmazione Android - Certificazione Android