Quindi, "I pattern di progettazione mancano di funzionalità linguistiche"? [chiuso]

Ho visto, qui su Programmers, la risposta a questa domanda: come cambia il modo di pensare sui modelli di progettazione e sulle pratiche OOP in linguaggi dinamici e tipicamente deboli? Lì ho trovato un collegamento a un articolo con un titolo esplicito: Le caratteristiche del linguaggio mancano nei modelli di progettazione . Ma dove ho trovato frammenti che a me sembravano molto accattivanti e che probabilmente possono essere verificati rispetto all'esperienza data c'è un incentivo per questo, come:

PaulGraham ha dichiarato "Peter Norvig ha scoperto che 16 dei 23 modelli in Design Patterns erano" invisibili o più semplici "in Lisp."

o un'altra frase che conferma ciò che ho visto di recente con le persone che cercano di simulare le lezioni in JavaScript:

Naturalmente, nessuno parla mai del modello di "funzione", del modello di "classe" o di numerose altre cose che diamo per scontate perché la maggior parte delle lingue le fornisce come funzionalità integrate. OTOH, programmatori in una lingua puramente prototipo, orientata? potrebbe essere utile simulare le classi con prototipi ...

Sto anche prendendo in considerazione che i modelli di progettazione sono uno strumento di comunicazione . Perché anche con la mia esperienza limitata nella partecipazione alla creazione di applicazioni, posso vedere ad esempio un anti-pattern ( inefficace e / o controproducente ), costringendo un piccolo team di PHP ad apprendere pattern GoF per app Intranet di piccole e medie dimensioni. Sono consapevole che la scala, l'ambito e lo scopo possono determinare ciò che è efficace e / o produttivo, ma non sono ancora riuscito a trovare una panoramica tecnica al riguardo.

Ho visto piccole applicazioni commerciali che si mescolavano funzionanti con OOP e che erano comunque mantenibili, e non so se molte persone avrebbero bisogno ad esempio in Python per scrivere un singleton, ma per me un semplice modulo fa la stessa cosa.

Quindi ci sono studi, articoli esaustivi o altre forme di esposizione che prendono in considerazione modelli di progettazione rispetto a soluzioni alternative o modi più semplici per farlo o sostituzioni con caratteristiche del linguaggio?

Non sono a conoscenza di discussioni o studi approfonditi che tengano conto di tutte queste cose.

Detto questo, a mio avviso l'intero argomento del "pattern di progettazione sta solo correggendo le funzionalità mancanti nei linguaggi OO" è un po 'sottile. Sì, alcuni modelli di progettazione sono esattamente questo, colmano un divario comune che non esiste nemmeno in qualche altra lingua X. Questi sono in genere modelli di progettazione di livello inferiore e più semplici, come alcuni / molti di quelli originali nel libro GoF.

Ma i modelli di progettazione vanno ben oltre quelli semplici e chiamarli caratteristiche linguistiche mancanti allunga l'immaginazione. Dai un'occhiata al catalogo di modelli di applicazioni enterprise di Fowler e pensa a come sarebbe se fossero tutti parte della definizione di base di una lingua. Immagino che finiresti con un linguaggio specifico del dominio ( DSL ) per le applicazioni aziendali (e molto complesso, a questo).

Quindi questa è la cosa, in realtà - i modelli di progettazione sono il modo di escogitare soluzioni riutilizzabili per problemi particolari (che sono spesso applicati in un linguaggio generico e universale). È qui che entra in gioco anche la comunicazione. Se mi dici "usiamo Active Records", ne so già parecchio sulla tua applicazione, senza spendere minuti a discutere di quali siano i vari approcci. Quindi sì, i modelli di progettazione creano buchi nella specifica del linguaggio. È tutto ciò che fanno? No, non da un colpo lungo.

Modificare:

In un certo senso, quello che sto dicendo è che i modelli consentono ai professionisti di OO di pensare a un livello superiore e quasi di costruire un tipo di DSL per il loro ambiente, rimanendo nella sintassi del loro linguaggio. E sì, ho visto cosa succede quando li applichi ovunque (vedi: AbstractSingletonProxyFactoryBean , sì, esiste), o penso che siano una specie di proiettile d'argento. Il punto è che mentre impiegano molto tempo per mettersi veramente a proprio agio, si suppone che in realtà riducano la complessità rendendo le cose prevedibili / comprensibili ad alto livello. Questo è molto diverso dall'essere un kit di patch per i fallimenti della tua lingua.

Modifica 2: aggiunto il contro-esempio AbstractSingletonProxyFactoryBean per prendere in giro gli schemi. Ad essere completamente onesti, se visti da una luce AOP, anche questo contro-esempio è difendibile.