I modelli di design sono davvero essenziali al giorno d'oggi?

Stavo leggendo "Coders at Work" e ho affrontato il fatto che alcuni dei professionisti intervistati nel libro non sono così entusiasti dei modelli di design.

Penso che ci siano 2 ragioni principali per questo:

1. I modelli di design ci costringono a pensare nei termini. In altre parole, è quasi impossibile inventare qualcosa di nuovo (forse meglio).

2. I modelli di design non durano per sempre. Le lingue e le tecnologie cambiano rapidamente; pertanto, i modelli di progettazione alla fine diventeranno irrilevanti.

Quindi forse è più importante imparare a programmare correttamente senza particolari schemi e non impararli.

Il punto era anche che di solito quando le persone affrontano un problema e non hanno molto tempo, cercano di usare uno schema. Ciò significa copiare e incollare il codice esistente nel progetto con modifiche minori per farlo funzionare. Quando è il momento di cambiare o aggiungere qualcosa, uno sviluppatore non sa da dove cominciare perché non è il suo codice e non ne ha molta familiarità.

Per i miei soldi, penso che a tutti manchi il punto di progettare modelli. È raro che mi sieda chiedendo quale modello dovrei usare in una determinata situazione. Inoltre, stavo usando la maggior parte di quei 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 quello" piuttosto che descrivere in dettaglio ciò che sto suggerendo. È molto più facile per noi discutere i vantaggi dei modelli di dominio fat e degli script di transazione se sappiamo tutti cosa significano questi due termini. E così via.

E soprattutto, se ho chiamato un FooBuilder di classe, allora sai che sto usando il modello Builder per generare il mio Foo.

Anche se non sai di cosa sto parlando quando dico "Il modello Observer è l'ideale per questo", sarai in grado di spegnerlo e cercarlo su Google abbastanza facilmente.

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

I motivi hanno due scopi principali:

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

• Moltiplicatore della forza di comunicazione : i pattern ci consentono di dire molto con un po '. Sfruttano un piccolo insieme di concetti potenti e ben compresi applicabili in un'ampia varietà di spazi problematici. La risposta di @ pdr è morta sul valore comunicativo degli schemi.

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

Ora, ciò 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 cliente che mi chiedeva "di includere almeno altri due schemi" (WTF ?!) poiché a causa della mancanza di parole d'ordine nel mio codice non sembrava abbastanza intraprendente.

Forse il concetto di anti-pattern è germano. Non penso di studiare i modelli di progettazione come il passo fondamentale per diventare un ingegnere del software. La progettazione del software è importante, spesso riservata come prerogativa dell'architetto del software a un progetto, ma realisticamente qualcosa che può essere messo in discussione dal consenso nel proverbiale team "ben congegnato".

Ma i modelli di progettazione e gli anti-schemi formano 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 inventare il proprio vocabolario per tali discussioni, ma non è poi così male fare riferimento agli standard defacto elaborati dagli autori che sono stati lì, fatto.

Esistono due tipi di modelli di progettazione:

1. Modelli universali , che riguardano molto di più l'organizzazione di programmi complessi in modo da poterli comprendere a tutti. Questi non stanno andando via, anche se possono essere scoperti altri esempi.
2. I modelli situazionali , che sono così legati alle forze particolari indotte dai vincoli (ad esempio, il linguaggio di programmazione) che quando queste forze cambiano, diventano irrilevanti.

OK, probabilmente tutti i modelli sono in qualche modo situazionali, ma con alcuni le forze provengono dal mondo reale e con altre le forze provengono dagli strumenti. Gli strumenti cambiano molto più velocemente del mondo reale.

Leggere sui 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 è accaduto prima. Pensi che Rieman non abbia mai letto Euclide?

I modelli di progettazione apportano vantaggi quando riducono il tempo impiegato dai colleghi o dai clienti a pensare "Come funziona?". Anche se non ha senso applicare uno standard per il bene della standardizzazione, se esiste un modo comune e ben compreso di fare qualcosa, ogni volta che un programmatore cerca quel modello che si aspetta di trovarlo e lo fa, tu hai fatto il loro e il tuo lavoro Più facile.

Credo che la banda di quattro stessi classifichi i modelli di design come

una soluzione comune a un problema che si verifica comunemente *

Quindi sì, i modelli 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 uno schema di disegni, c'è uno schema di problemi.

Alcuni linguaggi di programmazione possono avere soluzioni native per alcuni di questi problemi. Lo stesso libro "Design Patterns" menziona che lo schema visitatore ha scarso valore se si utilizza CLOS, poiché il servizio di invio multiplo è supportato nativamente da CLOS, il problema stesso che lo schema Visitatore sta cercando di risolvere.

Inoltre, il framework .NET ha un meccanismo di eventi incorporato per la pubblicazione di eventi su più listener, rendendo il modello 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 nel libro "Modelli di progettazione" sono rilevanti per le applicazioni desktop, ma non tanto per le applicazioni web. Naturalmente, con le app a pagina singola, questi modelli potrebbero essere nuovamente 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 per la prima volta un nuovo tipo di problema; come ero la prima volta che mi è stato chiesto di implementare la funzionalità Annulla. Se non fosse stato per il libro "Design Patterns", la mia implementazione sarebbe stata probabilmente qualcosa di simile alla memorizzazione di un'istantanea dei dati dopo ogni operazione di cambio di stato *** - un approccio molto incline all'errore e orribilmente inefficiente.

Quindi sì, alcuni degli schemi diventano meno rilevanti nel tempo e man mano che diventi un programmatore esperto, pensi meno a loro. Ma per un principiante sono preziosi, purché ricordi che sono i mezzi per risolvere un problema e non una ricerca per usarne il maggior numero possibile.

* la citazione potrebbe non essere precisa al 100% poiché è stata presa 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, questo potrebbe effettivamente essere il modo in cui lo risolverei oggi.

L'aderenza slava 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 di domini problematici efficaci non significa che non abbiano alcun valore. Sono un insieme di principi - chiamalo un framework - su cui basarsi 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 vede come una base per la funzionalità, piuttosto che una specifica funzionale.