La banda di quattro ha esplorato a fondo lo "Spazio modello"?

Da quando ho appreso per la prima volta i modelli di design di Gang of Four (GoF) , almeno 10 anni fa, ho l'impressione che questi 23 modelli debbano essere solo un piccolo campione di qualcosa di molto più grande che mi piace chiamare Pattern Space . Questo ipotetico spazio modello è costituito da tutte le soluzioni raccomandabili (note o sconosciute) per problemi di progettazione software orientati agli oggetti comuni.

Quindi mi aspettavo che il numero di modelli di design noti e documentati crescesse in modo significativo.

Non è successo Più di 20 anni dopo l'uscita del libro GoF, nell'articolo di Wikipedia sono elencati solo 12 modelli aggiuntivi, molti dei quali sono molto meno popolari di quelli originali. (Non ho incluso i modelli di concorrenza qui perché coprono un argomento specifico.)

Quali sono le ragioni?

• Il set di schemi GoF è in realtà più completo di quanto penso?

• L'interesse per la ricerca di nuovi modelli è diminuito, forse perché si è scoperto che non erano così utili nella progettazione del software?

• Qualcos'altro?

Quando uscì il Libro, molte persone pensarono in quel modo, e ci furono molti sforzi per creare "librerie di modelli" o persino "comunità di modelli". Puoi ancora trovarne alcuni:

• "Pattern Community" , WikiWikiWeb
• "The Design Patterns Study Group of New York City" , Logica industriale
• "Catalogo dei modelli" , The Hillside Group

Ma allora...

L'interesse per la ricerca di nuovi modelli è diminuito, forse perché non sono così utili nella progettazione del software?

Questo, moltissimo. Lo scopo dei modelli di progettazione è migliorare la comunicazione tra gli sviluppatori, ma se si tenta di aggiungere altri motivi si arriva rapidamente al punto in cui le persone non possono ricordarli, non ricordarli, o non essere d'accordo su come dovrebbero essere esattamente e la comunicazione è in effetti non è migliorato. Ciò accade già molto con i modelli GoF.

Personalmente, andrei ancora oltre: la progettazione del software, in particolare una buona progettazione del software, è troppo varia per essere catturata in modo significativo nei modelli, in particolare nel piccolo numero di modelli che le persone possono effettivamente ricordare - e sono troppo astratti per le persone ricordo davvero più di una manciata. Quindi non stanno aiutando molto.

E troppe persone si innamorano del concetto e provano ad applicare modelli ovunque - di solito, nel codice risultante non è possibile trovare il design reale tra tutti i Singletons e le Fabbriche astratte (completamente insignificanti).

Ho l'impressione che questi 23 schemi debbano essere solo un piccolo esempio di qualcosa di molto più grande che mi piace chiamare Spazio modello.

Questo è il terribile presupposto che viene propagato ovunque dai programmatori neofiti, programmatori che pensano di poter scrivere un programma semplicemente ricucendo schemi di software. Non funziona così. Se esiste un tale "spazio modello", puoi presumere che la sua dimensione sia effettivamente infinita.

I modelli di progettazione (in senso GoF) hanno un solo scopo: compensare le carenze del linguaggio di programmazione che si sta utilizzando.

I modelli di progettazione non sono né universali né completi. Se si passa a un linguaggio di programmazione diverso, più espressivo, la maggior parte degli schemi nel libro GoF diventa sia inutile che indesiderabile.

Penso che ci siano tre fattori che entrano in gioco qui.

Mancanza di massa critica

In primo luogo, un modello è sostanzialmente poco più che dare un nome ad un codice che implementa un particolare "pezzo" di funzionalità. L'unico modo in cui quel nome fornisce molto valore reale è se puoi dipendere da chiunque sappia cosa significa il nome, quindi solo usando il nome, capiscono immediatamente molto sul codice.

I modelli non hanno mai stabilito la massa critica di cui avevano bisogno per raggiungere questo obiettivo. Piuttosto il contrario, AAMOF. In 20 (circa) anni dalla pubblicazione del libro GoF, sono abbastanza sicuro di non aver visto più di una dozzina di conversazioni in cui tutte le persone coinvolte conoscevano davvero abbastanza schemi di progettazione da utilizzare per migliorare la comunicazione.

Per dirla in modo un po 'più caratteristico: i modelli di design sono falliti proprio perché hanno fallito.

Troppi modelli

Penso che il secondo fattore principale sia che, semmai, hanno inizialmente nominato troppi schemi. In un discreto numero di casi, le differenze tra i modelli sono sufficientemente sottili che è quasi impossibile dire con certezza reale se una determinata classe si adatta a un modello o a un altro (o forse entrambi - o forse nessuno dei due).

L'intento era che avresti potuto parlare di codice a un livello superiore. Saresti in grado di etichettare una parte abbastanza grande di codice come l'implementazione di un modello particolare. Semplicemente usando quel nome predefinito, tutti gli ascoltatori di solito saprebbero tanto quanto hanno a cuore quel codice, in modo da poter passare alla cosa successiva.

La realtà tende ad essere quasi l'opposto. Diciamo che sei in riunione e di 'loro che questa particolare classe è una facciata. Metà delle persone presenti all'incontro o non hanno mai saputo o da tempo hanno dimenticato esattamente cosa significa. Uno di loro ti chiede di ricordargli le differenze esatte tra una facciata e, diciamo, un proxy. Oh, e la coppia di persone che conoscono davvero i modelli passa il resto della riunione a discutere se questa debba davvero essere considerata una facciata o "solo" un adattatore (con quel ragazzo che insiste ancora che gli sembra un proxy).

Dato che il tuo intento era proprio quello di dire: "questo codice non è molto interessante; andiamo avanti", cercando di usare il nome di un modello solo aggiunto distrazione, non valore.

Mancanza di interesse

La maggior parte dei modelli di progettazione non si occupa davvero delle parti interessanti del codice. Hanno a che fare con cose del tipo: "come faccio a creare questi oggetti?" E "come faccio a far dialogare questo oggetto con quello?" Memorizzare i nomi dei modelli per questi (così come gli argomenti di cui sopra sui dettagli e simili) sta semplicemente mettendo molta energia in cose a cui la maggior parte dei programmatori non si preoccupa molto.

Per dirla in modo leggermente diverso: i modelli affrontano le cose che sono le stesse tra molti programmi - ma ciò che rende davvero interessante un programma è come è diverso dagli altri programmi.

Sommario

I modelli di progettazione non sono riusciti perché:

1. Non sono riusciti a raggiungere la massa critica.
2. La differenziazione tra i modelli era insufficiente per garantire chiarezza.
3. Si occupavano per lo più di parti di codice, quasi a nessuno importava comunque a nessuno.

I modelli mancano di astrazioni, i modelli semplici vengono astratti, i modelli complessi non vengono riconosciuti, quindi i modelli non sono utili (tranne alcuni di alto livello).

Penso che Paul Graham l'abbia detto meglio:

Quando vedo schemi nei miei programmi, lo considero un segnale di difficoltà. La forma di un programma dovrebbe riflettere solo il problema che deve risolvere. Qualsiasi altra regolarità nel codice è un segno, almeno per me, che sto usando astrazioni che non sono abbastanza potenti - spesso che sto generando a mano le espansioni di alcune macro che devo scrivere.

Quando riconosci un modello nel tuo codice, significa che qualcosa si ripete e dovresti usare un'astrazione migliore. Se non si dispone di un'astrazione migliore, utilizzare il modello come soluzione alternativa. Poiché i linguaggi di programmazione più recenti forniscono astrazioni migliori, i modelli diventano molto meno utili.
Anche i modelli semplici sono spesso facilmente astratti e i modelli complessi raramente vengono riconosciuti.
Quando un modello viene sostituito da un'astrazione, ciò non significa che il concetto dietro il modello scompare, ma che il concetto può essere scritto esplicitamente anziché indirettamente e che non è più speciale rispetto ad altri codici e non è più riconoscibile come uno schema.

Sebbene per lo più concordi con ciò che gli altri hanno risposto qui, personalmente ritengo che una delle ragioni principali di un numero non crescente di schemi sia che gli schemi perdono il loro significato quando ce ne sono innumerevoli. La cosa bella di questi pochi schemi è che coprono molti domini problematici in modo standard. Se ti concentrassi su un dominio di pattern infinito, finiresti senza alcun pattern. È un po 'come "quanto è lunga la costa di un'isola?". Se si misura su una mappa, si arriva con un numero decente. Ma se provi a ottenere più esatte e raggiungi una risoluzione più fine, scoprirai che la lunghezza aumenta sempre di più all'infinito (o incertezza; come misureresti il ​​confine esatto con le maree e a livello atomico?).

Qualcosa che nessuna delle altre risposte menziona che è anche rilevante:

L'ascesa di linguaggi tipizzati dinamicamente.

Quando il libro è uscito per la prima volta, si è discusso seriamente che Java era troppo lento per svolgere un vero lavoro. Ora Java viene spesso utilizzato su linguaggi più espressivi a causa della sua velocità. Forse Ruby, Python, JavaScript e altri sono ancora troppo lenti per alcune importanti classi di applicazioni, ma in generale sono abbastanza veloci per la maggior parte degli scopi. E almeno JavaScript sta diventando sempre più veloce nonostante ci siano più funzionalità in ogni versione.

Il libro GoF originale aveva gli schemi sia in smalltalk che in c ++, e se la memoria serve gli schemi erano sempre più brevi in ​​smalltalk e talvolta in modo significativo. Alcune delle caratteristiche dei modelli di progettazione classici sono in realtà modi per aggiungere funzionalità dinamiche a un sistema tipizzato staticamente (come il già discusso AbstractFactory, in cui si crea un'istanza della classe corretta in base ai dati di runtime). Altri sono molto più brevi nei linguaggi dinamici che si fondono semplicemente nell'uso idiomatico del linguaggio stesso.

E ha fatto accadere. Dozzine se non centinaia di libri sono stati pubblicati in quello che sembrava un tentativo di ridurre l'intera scienza informatica per progettare modelli, mentre editori e autori hanno tentato di saltare (o creare) un altro carrozzone. Ne ho uno scaffale. Non ho mai consultato dalla prima scansione, e sì, ero un succhiatore, perché c'era poco o niente lì dentro di qualsiasi uso effettivo o che non era già ben noto (vedi ad esempio Tipo Oggetto, che non è altro che la terza forma normale espressa sopra una dozzina di pagine invece di un paragrafo), e perché ovviamente meno schemi sono, meglio è: un punto che ha eluso la maggior parte dei praticanti. In effetti, quando ho pubblicato una confutazione di Tipo oggetto, mi è stato chiesto di rifondere il mio testo come modello di progettazione.Storia vera. Il che mostra anche un'altra carenza del progetto: nessun meccanismo di revisione, esclusione o rifiuto.

È un dato di fatto che il GoF non ha effettivamente tentato di "esplorare a fondo i modelli di progettazione". Piuttosto, erano impegnati in un progetto molto più ampio: introdurre il "linguaggio modello" nel CS, con tutti i suoi bizzarri arcani notazionali di Forze, Partecipanti, ecc., Che semplicemente fallirono, perché era fondamentalmente mal concepito, oltre che inutile.

Ciò che hanno realizzato, che è stato utile, sono state due cose:

• pubblicare diversi trucchi utili come il modello Visitatore
• fornire un set standard di nomi che è rimasto in gran parte bloccato: Factory, Adapter, Iterator, ... Se guardi CORBA, che è stato progettato immediatamente prima, vedrai il valore di questo: tutti i tipi di nomi "stranieri" come Interceptor , Servo, Broker, ...

Un altro concetto utile che nacque fu l'anti-pattern, ad esempio 'log and throw'. Il progetto, come molte mode del CS, è stato deragliato dal suo stesso evangelismo e adottato erroneamente come l'ennesima religione del CS, e ha seguito la strada della maggior parte di tali religioni: utile in parte, ma certamente "nessun proiettile d'argento" ((c ) Fred Brooks, 1965). Triste che dobbiamo continuare a riscoprirlo davvero ogni pochi anni.

C'erano / ci sono diversi libri intitolati PLoP ( Pattern Languages ​​of Program Design ) che sono ciascuno un'antologia di articoli presentati in una conferenza annuale .

Leggendo i libri, ho scoperto che alcuni dei modelli erano interessanti e nuovi per me, alcuni dei quali standard (ad esempio "mezzo oggetto più protocollo").

Quindi no, la collezione del GoF non era esaustiva e ha ispirato / ispirato le persone a collezionare / descrivere / scoprire / inventarne di nuove.

I "soli 12 schemi aggiuntivi elencati nell'articolo di Wikipedia" presumibilmente non sono nemmeno una raccolta completa: cioè ce ne sono altri documentati altrove, ad esempio nei libri PLoP e forse anche altrove.

Il libro Gang of Four (GoF) contiene la maggior parte degli schemi che un programmatore esperto in un linguaggio non funzionale ha nella sua cintura degli strumenti. È come il set base di strumenti che tutti i costruttori sanno usare. Il contributo principale del libro è stato quello di dare un nome ben definito ai modelli che erano in uso comune ai programmatori più esperti all'epoca e quindi aiutare la comunicazione tra i programmatori che discutevano di opzioni di progettazione.

Ti aspetti che un elettricista abbia alcuni strumenti che un normale costruttore non ha, allo stesso modo ti aspetteresti che un programmatore WPF conosca i modelli di progettazione per "Proprietà di dipendenza" o un "Programmatore SQL" per conoscere il modello di progettazione per usare i trigger per creare dati di audit.

Tuttavia, non li consideriamo come "modelli di progettazione" perché vengono utilizzati solo con una tecnologia.

Alcuni altri libri modello di progettazione del modem sono "Refactoring, Improveing ​​the Existing Code (Martin Fowler)" e "Clean Code: A Hand of Agile Software Craftsrafts (Robert C. Martin) " Entrambi questi libri presentano i contenuti come trasformazioni che fai al tuo codice attuale, piuttosto che come "design riutilizzabile preimpostato", tuttavia sono altrettanti "modelli di design".

Ecco un'intervista a Erich Gamma in cui riflette sulla loro selezione di modelli e su cosa cambieranno oggi (bene oggi a partire da 10 anni fa, ahah).

http://www.informit.com/articles/article.aspx?p=1404056

Larry: Come rifatteresti "Design Patterns"?

Erich: abbiamo fatto questo esercizio nel 2005. Ecco alcuni appunti della nostra sessione. Abbiamo scoperto che i principi di progettazione orientati agli oggetti e la maggior parte dei modelli non sono cambiati da allora. Volevamo cambiare la categorizzazione, aggiungere alcuni nuovi membri e anche eliminare alcuni dei modelli. Gran parte della discussione riguardava il cambiamento della categorizzazione e in particolare quali schemi abbandonare.

Quando abbiamo discusso su quali schemi abbandonare, abbiamo scoperto che li amiamo ancora tutti. (Non proprio — sono favorevole a lasciare Singleton. Il suo uso è quasi sempre un odore di design.)

Quindi, ecco alcune delle modifiche:

• Interprete e Flyweight dovrebbero essere spostati in una categoria separata che abbiamo chiamato "Altro / Composto" poiché sono davvero bestie diverse rispetto agli altri schemi. Il metodo Factory sarebbe generalizzato a Factory.
• Le categorie sono: Core, Creazionale, Periferico e Altro. L'intento qui è quello di enfatizzare i modelli importanti e di separarli da quelli meno frequentemente utilizzati.
• I nuovi membri sono: Oggetto null, Oggetto tipo, Iniezione delle dipendenze e Oggetto / interfaccia di estensione (vedere "Oggetto di estensione" in Pattern Languages ​​of Program Design 3, Addison-Wesley, 1997).
• Queste erano le categorie:
  • Nucleo: composito, strategia, stato, comando, iteratore, proxy, modello di modello, facciata
  • Creazionale: fabbrica, prototipo, costruttore, iniezione di dipendenza
  • Periferica: Fabbrica astratta, Visitatore, Decoratore, Mediatore, Tipo oggetto, Oggetto nullo, Oggetto estensione
  • Altro: Flyweight, interprete

I modelli reali nel libro a volte sono davvero utili, ma in realtà sono solo esempi di uno strumento più potente che il libro ti offre: una profonda comprensione di quando e dove è meglio tagliare il codice monolitico in parti indipendenti separate e regolate da un'interfaccia .

Quando apprendi quell'abilità, ti rendi conto che non è necessario ricordare i dettagli esatti di ogni singolo modello, poiché puoi sempre tagliare la soluzione che stai implementando nel modo più adatto al suo scopo. Quindi l'idea di scrivere sempre più schemi sembra molto accademica e inutile.

Quindi mi aspettavo che il numero di modelli di design noti e documentati crescesse in modo significativo.

Non è successo Più di 20 anni dopo l'uscita del libro GoF, nell'articolo di Wikipedia sono elencati solo 12 modelli aggiuntivi, molti dei quali sono molto meno popolari di quelli originali. (Non ho incluso i modelli di concorrenza qui perché coprono un argomento specifico.)

Il libro GoF e Wikipedia non sono certo l'unica fonte di modelli di design noti. Se cerchi semplicemente "modelli di design" su Amazon.com otterrai centinaia di libri (prova questa ricerca ). Immagino che elencino solo il modello più noto nell'articolo di Wikipedia .

Quindi il problema non è che non ci sono abbastanza modelli di progettazione documentati. Piuttosto ce ne sono così tanti che nessuno può memorizzarli tutti e la maggior parte dei programmatori ne riconosce solo alcuni. La grande promessa del linguaggio comune dei pattern si interrompe a questo punto.

Probabilmente ci sono molte strutture che non sono ancora state pensate. Finché le persone sviluppano software, ci saranno sfide progettuali da superare. Alcuni di questi potrebbero essere risolti usando nuovi schemi intelligenti che altri potrebbero utilizzare.

I linguaggi di programmazione hanno sviluppato e progredito per sottrarre gli schemi più comunemente usati. Tali schemi esistono ancora nel design delle lingue. Quindi oggi possono essere ignorati, ma ciò non li rende irrilevanti.

La conoscenza di come costruire una casa è improvvisamente irrilevante quando abbiamo robot che possono farlo per noi? Direi di no, non lo è. È meno pertinente, certo - e probabilmente molto meno gratificante da studiare, poiché la domanda è diminuita drasticamente e nessun altro la sta studiando.

Quindi no, non credo che lo spazio modello come lo chiami sia stato esaurito. Come ha sottolineato un'altra risposta, è probabile che sia infinita. Ma man mano che la domanda di progettazione dei sistemi diminuisce, mentre aumentiamo l'altezza della nostra torre di astrazione e la potenza dei nostri linguaggi di programmazione - sempre meno persone che costruiscono sui livelli più alti presteranno attenzione ai dettagli di come è stata costruita la torre .

I pattern sono infiniti .. Puoi modificare ogni pattern o mescolare n match per crearne di nuovi .. Anche i pattern di integrazione aziendale sono ben definiti ... quindi sì gof ha fatto fatica a documentare i pattern usando uml e ha creato uno standard per spiegarli .. Ma per ogni modello di dominio si evolvono e cambiano anche per linguaggio espressivo come python o scala ..