Quindi, "I modelli di progettazione mancano le caratteristiche della lingua"? [chiuso]

Question

Quindi, "I modelli di progettazione mancano le caratteristiche della lingua"? [chiuso]

#1 da (10 voti)

12

Ho visto, qui su Programmers, la risposta a questa domanda: come cambia il modo di pensare sui modelli di progettazione e le pratiche OOP in dinamico e lingue debolmente tipizzate? Lì ho trovato un collegamento a un articolo con un titolo esplicito: Sono modelli di progettazione le caratteristiche della lingua mancante . Ma dove ho trovato frammenti che a me sembravano molto orecchiabili e che probabilmente possono essere verificati rispetto all'esperienza fornita, c'è un incentivo per questo, come:

PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp."

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

Of course, nobody ever speaks of the "function" pattern, or the "class" pattern, or numerous other things that we take for granted because most languages provide them as built-in features. OTOH, programmers in a purely PrototypeOrientedLanguage? might well find it convenient to simulate classes with prototypes...

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

Ho visto piccole applicazioni commerciali che si sono mischiate a funzioni con OOP e sono comunque mantenibili, e non so se molti avrebbero bisogno ad esempio di 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 schemi di progettazione e soluzioni alternative rispetto a modi più semplici per farlo, o sostituzioni con funzionalità linguistiche?

programming-languages design-patterns

posta Eduard Florinescu 20.09.2012 - 21:51

fonte

1 risposta

Leggi altre domande sui tag programming-languages design-patterns

Un'API RESTful dovrebbe fornire dati per un intero modulo? Quale sarà la migliore pratica per avere il codice sorgente 'revisionato' in un repository di controllo del codice sorgente?

score 10 · Accepted Answer

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

Detto questo, a mio parere l'intera argomentazione di "modelli di progettazione si limitano a rattoppare le funzionalità mancanti nei linguaggi OO" è un po 'sottile. Sì, alcuni modelli di design sono esattamente questo, riempiono un vuoto comune che non esiste nemmeno in qualche altra lingua X. Questi sono in genere i tuoi modelli di progettazione di basso livello, più semplici, come alcuni / molti di quelli originali nel libro GoF.

Ma i modelli di design vanno molto al di là di quelli semplici, e chiamarli caratteri del linguaggio mancanti estende l'immaginazione. Guarda il catalogo di modelli di applicazioni aziendali di Fowler e pensa a come sarebbe se fossero tutti parte della definizione di base di una lingua . Immagino che avresti finito con un linguaggio specifico del dominio ( DSL ) per le applicazioni aziendali (e molto complesso , a quello).

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

Modifica:

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

Modifica 2 - aggiunto il contro-esempio AbstractSingletonProxyFactoryBean per attirare l'attenzione sui pattern. Per essere completamente onesti, se visti da una luce AOP, anche questo contro-esempio è difendibile.