La Gang of Four ha esplorato a fondo "Pattern Space"?

Quando il libro è uscito, molte persone hanno pensato in questo modo e ci sono stati molti sforzi per creare "librerie di pattern" o anche "comunità di modelli". Puoi ancora trovarne alcuni:

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

Ma allora ...

Did the interest in finding new patterns drop, maybe because they are not really that useful in software design?

Questo, molto. Il punto di design pattern è il miglioramento della comunicazione tra gli sviluppatori, ma se cerchi di aggiungere altri pattern arrivi rapidamente al punto in cui le persone non riescono a ricordarli, oa ricordarli male, o non sono d'accordo su cosa esattamente loro dovrebbe assomigliare, e la comunicazione non è, infatti, migliorata. Questo succede già molto con i modelli GoF.

Personalmente, andrei anche oltre: il design del software, in particolare il buon design del software, è troppo vario per essere catturato in modo significativo nei pattern, specialmente nel piccolo numero di pattern che le persone possono effettivamente ricordare - e sono troppo astratti per le persone a ricordare davvero più di una manciata. Quindi non stanno aiutando molto.

E troppe persone si innamorano del concetto e cercano di applicare i pattern ovunque - di solito, nel codice risultante non è possibile trovare il design attuale tra tutti i Singletons e le Fabbriche astratte (completamente prive di significato).

I am having the impression that these 23 patterns should be only a small sample of something much larger which I like to call the Pattern Space.

Questa è l'ipotesi terribile che viene propagata dai programmatori neofiti ovunque, i programmatori che pensano di poter scrivere un programma semplicemente cucendo insieme modelli di software. Non funziona in questo modo. Se c'è un tale "spazio pattern", puoi presumere che la sua dimensione sia effettivamente infinita.

Gli schemi di progettazione (nel senso di GoF) hanno un solo scopo: per compensare le carenze nel linguaggio di programmazione che stai 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 del libro GoF diventano non necessari e indesiderati.

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

Mancanza di massa critica

In primo luogo, un pattern è fondamentalmente 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 tutti sapendo che cosa significa il nome, semplicemente usando il nome, capiscono immediatamente molto del codice.

I modelli non hanno mai stabilito la massa critica di cui avevano bisogno per ottenere ciò. Piuttosto il contrario, AAMOF. Nei 20 (o così) anni trascorsi dalla pubblicazione del libro GoF, sono abbastanza sicuro di non averne visto almeno una decina di conversazioni in cui tutti erano interessati a conoscere abbastanza modelli di progettazione per il loro uso per migliorare la comunicazione.

Per dirla in modo un po 'più singolare: i modelli di progettazione sono falliti in modo specifico perché non sono riusciti.

Too Many Patterns

Penso che il secondo fattore principale sia che, se mai, all'inizio chiamarono troppi modelli. In un discreto numero di casi, le differenze tra i pattern sono sufficientemente sottili da rendere quasi impossibile affermare con certezza se una particolare 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 del codice a un livello più alto. Saresti in grado di etichettare una porzione di codice abbastanza grande come l'implementazione di un particolare modello. Semplicemente usando quel nome predefinito, tutti quelli che ascoltano di solito sanno quanto si preoccupano di quel codice, quindi puoi passare alla prossima cosa.

La realtà tende ad essere quasi l'opposto. Diciamo che sei in riunione e dì loro che questa particolare classe è una facciata. Metà della gente dell'incontro non ha mai saputo o ha dimenticato da tempo cosa significhi esattamente. Uno di questi ti chiede di ricordargli le differenze esatte tra una facciata e, ad esempio, un Proxy. Oh, e il paio di persone che conoscono davvero i modelli trascorrono il resto della riunione discutendo se questa dovrebbe essere veramente considerata una Facciata o "solo" un Adattatore (con quell'unico che insiste ancora sul fatto che a lui sembra un Proxy).

Dato che il tuo intento era davvero solo per dire: "questo codice non è molto interessante, passiamo", provando a usare il nome di un modello solo aggiunto distrazione, non valore.

Mancanza di interesse

La maggior parte dei modelli di progettazione non gestisce realmente le parti interessanti del codice. Si occupano di cose come: "come posso creare questi oggetti?" E "come faccio a ottenere questo oggetto per parlare con quello?" Memorizzare i nomi dei pattern per questi (così come i suddetti argomenti sui dettagli e così via) sta semplicemente mettendo un sacco di energia in cose di cui i programmatori di solito non si preoccupano molto.

Per dirla in modo leggermente diverso: i pattern trattano le cose che sono uguali tra molti programmi - ma ciò che rende davvero interessante un programma è come diversi da altri programmi.

Sommario

Gli schemi 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 principalmente di parti di codice a cui quasi nessuno importava davvero.

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

Penso che Paul Graham lo abbia detto meglio:

When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

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

Anche se per lo più sono d'accordo con ciò che gli altri hanno risposto qui, personalmente penso che una ragione principale per un numero crescente di modelli sia che i modelli perdono il loro significato quando ce ne sono innumerevoli. La cosa bella con questi pochi schemi è che coprono molti domini problematici in un modo standard. Se ti concentri su un dominio di pattern senza fine, ti ritroverai senza schemi. È un po 'come "quanto è lunga la costa di un'isola?". Se misuri su una mappa, arrivi con un numero decente. Ma se cerchi di ottenere più esatti e ottenere una risoluzione più fine, scoprirai che la lunghezza aumenta sempre più all'infinito (o all'incertezza: come misuri il confine esatto con le maree e a livello atomico?).

Qualcosa che nessuna delle altre risposte menziona è pertinente:

L'aumento delle lingue digitate dinamicamente.

Quando il libro è uscito per la prima volta c'era una seria discussione sul fatto che Java fosse troppo lento per fare un vero lavoro. Ora Java è spesso usato su linguaggi più espressivi perché 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 JavaScript, in realtà, sta diventando sempre più veloce nonostante abbia più funzionalità incluse in ogni versione.

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

È successo . 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 gli editori e gli autori tentavano di saltare (o creare) un altro carrozzone. Ne ho uno scaffale Mai consultato sin dalla prima scansione, e sì ero un babbeo, perché c'era poco o nulla in là di qualsiasi uso effettivo o che non era già ben noto (vedi ad esempio Type Object, che non è altro che una terza forma normale espressa sopra una dozzina di pagine invece di un paragrafo), e perché ovviamente i pochi modelli sono i migliori: un punto che ha eluso la maggior parte dei praticanti. Infatti, quando ho postato una confutazione di Type Object, mi è stato chiesto di riformulare il mio testo come pattern di progettazione. True story. Che mostra anche un'altra deficienza del progetto: nessuna revisione o meccanismo di esclusione o rifiuto.

In effetti, il GoF non ha effettivamente cercato di "esplorare a fondo i modelli di design". Piuttosto, erano impegnati in un progetto molto più ampio: introdurre il "linguaggio del modello" in CS, con tutti i suoi arcani arcani notazionali di Forze, Partecipanti, ecc., Che semplicemente fallivano, perché era fondamentalmente errato, oltre che privo di senso.

Ciò che loro hanno compiuto, che era utile, erano due cose:

• pubblica diversi trucchi utili come il pattern Visitor
• fornisce un set standard di nomi che si è 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, Servant, Broker, ...

Un altro utile concetto che è emerso è stato l'anti-pattern, ad es. 'registra e getta'. Il progetto, come molte mode in CS, fu deragliato dalla sua stessa evangelizzazione e fu adottato erroneamente come un'altra religione CS, e seguì la via della maggior parte di tali religioni: utile in parti, ma certamente "nessuna pallottola d'argento" ((c ) Fred Brooks, 1965). Triste che dobbiamo continuare a riscoprire che ogni pochi anni davvero.

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

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

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

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

Il libro Gang of Four (GoF) contiene la maggior parte degli schemi che un programmatore esperto in una lingua non funzionale ha nella propria cintura degli attrezzi. È come il set di strumenti di base che tutti i costruttori sanno come usare. Il contributo principale del libro era di dare un nome ben definito agli schemi che erano in uso comune dalla maggior parte dei programmatori esperti al momento e quindi aiutare la comunicazione tra i programmatori che discutono le opzioni di progettazione.

Ci si aspetta che un elettricista abbia alcuni strumenti che un normale costruttore non possiede, allo stesso modo ci si aspetterebbe che un programmatore WPF conosca i modelli di progettazione per "Proprietà dipendenza" o un "Programmatore SQL" per conoscere il modello di progettazione per utilizzando i trigger per creare dati di controllo.

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

Altri libri di modelli di design del modem sono "Rifattorizzare, migliorare il design del codice esistente (Martin Fowler)" e "Clean Code: Un manuale di abilità software agile (Robert C. Martin) " Entrambi questi libri presentano i contenuti come trasformazioni apportate al codice corrente, piuttosto che come" design riutilizzabile pre-inscatolato ", tuttavia sono semplicemente" schemi di progettazione ".

Gli schemi effettivi nel libro sono a volte 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 impari quell'abilità, ti rendi conto che non hai bisogno di ricordare i dettagli esatti di ogni singolo modello, dato che puoi sempre tagliare la soluzione che stai implementando nel modo che meglio si adatta al suo scopo. Quindi l'idea di scrivere sempre più motivi sembra molto accademica e inutile.

So I expected the number of known and documented design patterns to grow significantly.

It did not happen. More than 20 years after the GoF book came out, only 12 additional patterns are listed in the Wikipedia article, most of which are much less popular than the original ones. (I did not include the concurrency patterns here because they cover a specific topic.)

Il libro GoF e Wikipedia non sono certo l'unica fonte di modelli di design noti. Se cerchi solo "modelli di progettazione" in Amazon.com ottieni centinaia di libri (prova questo Ricerca ). Immagino che elenchino solo il modello più noto nell' articolo di Wikipedia .

Quindi il problema non è che non ci siano abbastanza schemi di progettazione documentati. Piuttosto ce ne sono così tanti che nessuno può memorizzarli tutti e la maggior parte dei programmatori ne riconosce solo alcuni. A questo punto, la grande promessa di un linguaggio modello comune si rompe.

Ecco un'intervista con Erich Gamma in cui riflette sulla loro selezione di modelli e su cosa cambierebbero oggi (beh, oggi, a 10 anni fa, haha).

link

Larry: How would you refactor "Design Patterns"?

Erich: We did this exercise in 2005. Here are some notes from our session. We have found that the object-oriented design principles and most of the patterns haven't changed since then. We wanted to change the categorization, add some new members and also drop some of the patterns. Most of the discussion was about changing the categorization and in particular which patterns to drop.

When discussing which patterns to drop, we found that we still love them all. (Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.)

So here are some of the changes:

• Interpreter and Flyweight should be moved into a separate category that we referred to as "Other/Compound" since they really are different beasts than the other patterns. Factory Method would be generalized to Factory.
• The categories are: Core, Creational, Peripheral and Other. The intent here is to emphasize the important patterns and to separate them from the less frequently used ones.
• The new members are: Null Object, Type Object, Dependency Injection, and Extension Object/Interface (see "Extension Object" in Pattern Languages of Program Design 3, Addison- Wesley, 1997).
• These were the categories:
  • Core: Composite, Strategy, State, Command, Iterator, Proxy, Template Method, Facade
  • Creational: Factory, Prototype, Builder, Dependency Injection
  • Peripheral: Abstract Factory, Visitor, Decorator, Mediator, Type Object, Null Object, Extension Object
  • Other: Flyweight, Interpreter

Probabilmente ci sono molte strutture a cui non è ancora stato pensato. Finché le persone stanno sviluppando software, ci saranno sfide progettuali da superare. Alcuni di questi potrebbero essere risolti utilizzando nuovi modelli intelligenti che altri potrebbero utilizzare.

I linguaggi di programmazione si sono sviluppati e sono progrediti per astrarre i modelli più comunemente usati. Questi modelli esistono ancora nel design delle lingue. Quindi possono essere ignorati oggi, ma ciò non li rende poco importanti.

La conoscenza di come costruire una casa all'improvviso non è importante una volta che avremo robot in grado di farlo per noi? Direi di no, non lo è. È meno rilevante, certo - e probabilmente molto meno gratificante da studiare, poiché la domanda è diminuita drasticamente, e nessun altro lo sta studiando.

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

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