Design pattern come lingua mancante (mancante)

Question

A volte le persone fanno riferimento a modelli di progettazione come mancanti delle funzionalità del linguaggio di programmazione. Per evitare il dibattito su cosa sia un modello di design, diciamo che consideriamo solo i pattern GoF originali. Ad esempio, il modello singleton scompare in Scala che supporta oggetti singleton usando la parola chiave object.

Ci sono poche risorse intorno a questo, in particolare Are Design Patterns Missing Language Features dal wiki C2 o Are design patterns really language weaknesses? da SO. Ma non sono riuscito a trovare una copertura non argomentata, obiettiva e completa di questa domanda.

Idealmente, vorrei una matrice con i modelli di progettazione GoF (riga) e alcuni linguaggi di programmazione mainstream (colonne), in cui ogni cella farebbe riferimento a una discussione sul modello nel linguaggio di programmazione specifico.

Per evitare il dibattito su ciò che PL da considerare, possiamo anche risolvere questo problema e scegliere: Java (come rappresentante OO tipizzato staticamente), Smalltalk (come rappresentante dinamicamente tipizzato), Haskell (come rappresentante funzionale), Scala (come rappresentante oo/funzionale ibrido), Lisp (come rappresentante di meta-programmazione), JavaScript (come rappresentante basato su prototipi). E lascia altri PL per appunti o commenti. So che possiamo discutere su questa scelta, ma sarebbe già interessante per queste lingue.

Questa sarà sempre una domanda aperta, ma mi sento come chiesta così com'è, questa è sufficientemente focalizzata per avere una risposta migliore.

Forse questa matrice esiste già da qualche parte? O qualcuno ha abbastanza conoscenze per realizzarlo? O qualcuno è abbastanza appassionato da iniziare e renderlo una risposta wiki in modo che altri possano continuare?

Answer 1

Gli schemi nei modelli di progettazione sono un sottoinsieme del sempre crescente insieme di modelli che le persone utilizzano quando programmano in lingue diverse. Gli autori sono molto chiari sul fatto che questi modelli si applicano solo ai linguaggi OOP, quindi molti di essi non avranno senso al di fuori di quel contesto.

Allo stesso tempo, ci sono molti modelli in altre lingue che non sono necessari in una lingua OOP. Considera che gli oggetti stessi sono uno schema quando implementati in C o Schema. In assembly, lo stack di chiamate è un pattern.

Answer 2

Personalmente, dopo aver trascorso alcuni anni di utilizzo di OOP, ho scoperto che il problema con i modelli di progettazione è che evidenziano i problemi con OOP e quanto sia difficile vedere i modelli nei dati così correlati al dominio in che è stato modellato. A volte è molto difficile vedere il legno per gli alberi. Alcuni artefatti in OOP sono semplicemente lì per curare i problemi che esistono quando si pensa in quel particolare paradigma o si aggira lo stato e l'accesso incapsulati.

Penso che i modelli di progettazione siano grandi e li utilizzo, tuttavia sono stati considerati come la soluzione a un problema che potrebbe esistere nell'impossibilità di OOP di essere obiettivi sulle strutture e le funzioni dei dati, in modo che la formula provata e testata può essere applicato. Un semplice esempio potrebbe essere l'oggetto Singleton. Questo scompare quando si utilizzano i linguaggi funzionali e non è un problema.

Come un signore su SO ha detto quando ho chiesto informazioni su UML e se poteva essere usato per modellare le lingue funzionali, ha detto che il linguaggio di modellazione dei linguaggi di programmazione funzionale è matematica. Penso che questa sia la chiave per comprendere il motivo per cui i pattern non sono rilevanti per i linguaggi di programmazione funzionale, poiché la teoria dietro di essi è immersa nelle strutture della matematica.

Non posso aiutarti con un foglio di greppia, ma posso essere abbastanza certo che i pattern GOF non si applicano ai linguaggi di programmazione funzionale, poiché vanno direttamente ai modelli reali della matematica come la bellezza dei linguaggi funzionali è che mappano direttamente (nella maggior parte dei casi) a molti anni di risoluzione dei problemi in matematica. Forse una sfacciata affermazione è che i modelli di progettazione dei linguaggi funzionali sono teoremi matematici con una relazione uno a uno in cui OO ha una forma di astrazione artificiale che a volte interferisce.

Penso che ci siano alcuni principi di progettazione che attraversano tutti i linguaggi come MVC, architettura multilivello, ridimensionamento e scalabilità. Ma questi dovrei considerare come non modelli di progettazione, più di buone pratiche di progettazione del software.