Gli schemi di progettazione sono davvero essenziali al giorno d'oggi?

Per i miei soldi, penso che a tutti manchi il punto di design pattern. È raro che mi siedo chiedendo quale schema dovrei usare in una determinata situazione. Inoltre, stavo usando la maggior parte di questi modelli molto prima che sapessi che avevano nomi.

Il potere dei modelli di progettazione è nella comunicazione. È molto più veloce per me dire "usa una strategia per questo" piuttosto che descrivere in dettaglio ciò che sto suggerendo. È molto più facile per noi discutere i vantaggi dei modelli di dominio grassi rispetto agli script di transazione se tutti sappiamo cosa significano questi due termini. E così via.

E il più potente di tutti, se ho chiamato una classe FooBuilder, allora sai che sto usando il pattern Builder per generare il mio Foo.

Anche se non sai di cosa sto parlando quando dico che "il pattern Observer è ideale per questo", sarai in grado di andare avanti e google abbastanza facilmente.

In questo senso, il potere dei modelli di progettazione non svanirà mai.

I modelli di progettazione sono un aumento della potenza espressiva del linguaggio comune che usiamo come persone del software. Questo linguaggio comune non è essenziale, ma rende più facili e veloci da esprimere molte soluzioni comuni ai problemi. Ad esempio, è molto più facile parlare di Singletons piuttosto che parlare di "classi in cui si suppone di avere solo un'istanza ma che non possono essere rese statiche e globali".

Le soluzioni fornite dai modelli di progettazione sono utili, ma sono soluzioni che probabilmente hai già pensato se hai affrontato i problemi che risolvono. È necessario un certo livello di maturità per comprendere i modelli di progettazione: se non hai mai dovuto risolvere il problema, non vedrai il valore o l'interesse nella soluzione.

I pattern hanno due scopi principali:

• Risoluzione prevedibile delle tensioni : i pattern sono progettati per risolvere un determinato insieme di tensioni in un modo che è noto funzionare. Kent Beck, autore di Modelli Smalltalk Best Practice , descrive gli schemi come un modo per ripetere la decisione che un esperto farebbe in circostanze simili. Finché le tensioni rimangono le stesse (e spesso lo fanno), gli schemi che li risolvono rimarranno utili.

• Moltiplicatore della forza di comunicazione : i pattern ci permettono di dire molto con un po '. Fanno leva su un piccolo insieme di concetti potenti e ben compresi che sono applicabili in un'ampia varietà di spazi problematici. La risposta di @ pdr è morta sul valore comunicativo dei pattern.

Penso che l'affermazione che i modelli di design ostacolino l'innovazione sia completamente falsa. Dovresti sapere dovunque esista già, quindi non è necessario reinventare la ruota. Per essere temporanei, i pattern nel loro insieme si applicano ai sistemi OOP e non sono collegati a nessuna piattaforma o linguaggio particolare.

Ora, quello che non mi piace quando le persone parlano di schemi è che alcune persone hanno una sorta di ossessione per loro. Una volta ho avuto un client che mi chiedeva "includere almeno altri due pattern" (WTF ?!) poiché, a causa della mancanza di parole chiave nel mio codice, non sembrava abbastanza interessante.

Forse il concetto di anti-pattern è pertinente. Non penso di studiare modelli di design come il passaggio fondamentale per diventare un ingegnere del software. Il design del software è importante, spesso riservato come prerogativa dell'architetto del software su un progetto, ma realisticamente qualcosa che può essere risolto dal consenso nel proverbiale team "ben gelificato".

Ma i modelli di design e gli anti-pattern costituiscono una risorsa per quelle discussioni. Bisogna apprezzare le lezioni di cose che hanno funzionato bene (o meno) e come capitalizzare (o mitigare) le conseguenze delle scelte progettuali. Una buona squadra potrebbe trovare il proprio vocabolario per tali discussioni, ma non è davvero una cattiva cosa fare riferimento agli standard defacto elaborati dagli autori che sono stati lì, fatto.

Esistono due tipi di schemi di progettazione:

1. Motivi universali , che sono molto di più su come organizzare programmi complessi in modo che tu possa capirli del tutto. Questi non stanno andando via, anche se possono essere scoperti più esempi di essi.
2. Modelli situazionali , che sono così legati alle particolari forze indotte dai vincoli (ad es. il linguaggio di programmazione) che quando tali forze cambiano, diventano irrilevanti.

OK, probabilmente tutti gli schemi sono in qualche modo situazionali, ma con alcune forze provengono dal mondo reale e con gli altri le forze provengono dagli strumenti. Gli strumenti cambiano molto più velocemente del mondo reale.

Leggere i modelli di progettazione è come imparare la matematica invece di reinventarli. Nessuno ti impedisce di fare grandi progressi in un determinato campo una volta che hai una solida comprensione di ciò che è successo prima. Pensi che Rieman non abbia mai letto Euclide?

C'è un vantaggio nei modelli di progettazione quando riducono la quantità di tempo che i tuoi colleghi o clienti spendono pensando "Come funziona?". Anche se non ha senso applicare uno standard per la standardizzazione, se esiste un modo comune e ben compreso per fare qualcosa, ogni volta che un programmatore cerca quel modello che si aspetta di trovarlo e lo fa, hai fatto il loro e il tuo lavoro più facile.

Credo che la stessa banda di quattro classifichi modelli di design come

a common solution to a commonly occurring problem*

Quindi sì, i pattern sono rilevanti quando si verifica lo stesso tipo di problema. E questo ci porta ad un problema con il termine "Design Pattern". Un modello è qualcosa di riconoscibile che si verifica ripetutamente. Quindi in realtà non esiste un modello di design, esiste un modello di problemi.

Alcuni linguaggi di programmazione possono avere soluzioni native per alcuni di questi problemi. Il libro "Design Patterns" menziona di per sé che il pattern visitor è di poco valore se si utilizza CLOS, poiché il multi-dispatch è supportato nativamente da CLOS, lo stesso problema che il pattern Visitor sta cercando di risolvere.

Inoltre, il framework .NET ha una build nel meccanismo degli eventi per la pubblicazione di eventi su più listener, rendendo il pattern Observer meno rilevante in questo contesto.

Il passaggio dalle applicazioni desktop alle applicazioni web ** cambia anche il tipo di problemi di programmazione che dobbiamo risolvere. Molti dei modelli del libro "Design Patterns" sono rilevanti per le applicazioni desktop, ma non tanto per le applicazioni web. Ovviamente, con le app a singola pagina, questi pattern potrebbero essere di nuovo rilevanti sul lato client.

Ma i modelli di design e libri come "Design Patterns" o "Patterns of Enterprise Application Architecture" sono di enorme valore quando sei un programmatore alle prime armi e devi affrontare un nuovo tipo di problema per la prima volta; poiché ero la prima volta che mi è stato chiesto di implementare la funzionalità Annulla. Se non fosse stato per il libro "Design Patterns", probabilmente la mia implementazione sarebbe stata come immagazzinare un'istantanea dei dati dopo ogni operazione di modifica dello stato *** - un approccio molto incline agli errori e orribilmente inefficiente.

Quindi sì, alcuni dei pattern diventano meno rilevanti nel tempo, e quando diventi un programmatore esperto, pensi meno a loro. Ma per un principiante, sono preziosi, purché ricordiate che sono i mezzi per risolvere un problema - e non una ricerca per usarne il maggior numero possibile.

* il preventivo potrebbe non essere accurato al 100% poiché viene preso dalla memoria

** nella mia esperienza, sta diventando molto comune per le aziende scegliere i meccanismi di consegna web per le applicazioni line-of-business interne.

*** dopo aver appreso la programmazione funzionale e le strutture di dati funzionali, allora questo potrebbe effettivamente essere il modo in cui oggi lo risolverei.

L'aderenza servile ai modelli di progettazione può essere dannosa - i modelli sono soluzioni documentate a problemi comuni, ma non sono manuali di istruzioni. Tuttavia, solo perché sono discussi a lungo e, in alcuni casi, applicati al di fuori dei domini problematici efficaci, non significa che non abbiano alcun valore. Sono un insieme di principi - chiamiamolo un framework - da attingere quando si progetta l'architettura di un programma, consentendo all'architetto di dare un'idea di come vorrebbe vedere la soluzione funzionare. Un buon team di sviluppo li considera come una base per la funzionalità, piuttosto che una specifica funzionale.