Perché i modelli di progettazione non vengono aggiunti ai costrutti delle lingue?

Recentemente ho parlato con un collega che ha affermato che la sua azienda stava lavorando per aggiungere il modello di progettazione MVC come estensione PHP.

Ha spiegato che hanno scritto il codice C per l'aggiunta Controllers, Models and Viewsai costrutti del linguaggio per aumentare le prestazioni.

Ora so che MVC è un modello di progettazione architettonica ampiamente utilizzato nelle applicazioni web, ma devo ancora imbattermi in lingue che hanno un costrutto linguistico per i controller, ad esempio.

L'IMHO che integra i modelli di progettazione in un linguaggio può enfatizzare l'importanza di una buona progettazione OO.

Quindi, perché i modelli di progettazione più utilizzati (MVC, Factory, Strategy, ecc.) Non vengono aggiunti ai costrutti del linguaggio?

Se la domanda sembra troppo ampia, puoi limitarla solo a PHP.

Modificare:

Non sto insinuando che si debba usare un modello di progettazione durante lo sviluppo di un progetto. In realtà promuovo la metodologia di mantenerlo semplice finché funziona.

I pattern di progettazione vengono aggiunti continuamente ai costrutti del linguaggio. Hai mai sentito parlare del modello di progettazione delle chiamate di subroutine ? No? Neanche io. Questo perché le chiamate di subroutine, che erano un modello di progettazione nei primi anni '50, sono state aggiunte alle lingue praticamente all'istante. Oggi sono persino presenti nei set di istruzioni del codice macchina delle CPU.

Che dire del modello For Loop Design? Il modello di design While Loop ? Il modello di progettazione degli interruttori ? Il modello di progettazione degli oggetti ? Il modello di design di classe ? Tutti questi sono stati aggiunti in alcune lingue.

Alcuni di loro sono. Ad esempio, gli iteratori sono funzionalità della lingua in molte lingue e le loro librerie standard (ciao, foreach e return return). Observer è spesso presente anche sotto forma di eventi (non in PHP - devi gestire tu stesso l'abbonamento di callback). Il comando è la funzionalità principale di WPF.

Molti degli altri non trarrebbero alcun vantaggio dal supporto linguistico (e renderebbero la lingua più ingombrante) - come semplificheresti i controller se potessi progettare funzionalità linguistiche per loro? Come classi, beneficiano di tutta l'infrastruttura già presente per supportare le classi: puoi istanziarle, passarle in giro e ad esempio unità testarle come qualsiasi altro oggetto.

L'unico componente di MVC di cui IMO potrebbe beneficiare da una sorta di supporto linguistico è View (con un motore di template ufficiale) - e in PHP già supportato - sei in grado di creare e caricare dinamicamente script PHP (che spesso sono con una sorta di pre-elaborazione usata come template).

Lo stesso vale per il metodo di fabbrica: come lo semplificherebbe, se potessi avere qualsiasi tipo di funzionalità linguistica desiderata? Una caratteristica che manca ad alcuni linguaggi (come C ++) è la capacità di costruire oggetti con questo nome di tipo, ma la maggior parte dei linguaggi di livello superiore può farlo (e non è nemmeno necessario creare utili metodi di fabbrica). Oltre a ciò, tutto ciò che serve è essere in grado di creare un metodo che crea istanze, ritorni e oggetti.

Alcuni modelli di progettazione vengono infatti aggiunti come costrutti di linguaggio - semplicemente non vengono identificati come tali perché le persone iniziano a considerarli come "sintassi" una volta incorporati. La gestione delle eccezioni in Java è un buon esempio - molte persone codificano esplicitamente qualcosa di simile come modello di progettazione se non facesse parte della sintassi principale.

Ma per concentrarti sulla domanda: ci sono molti motivi per cui non vorresti aggiungere troppi modelli di progettazione a una lingua:

• Non è necessario aggiungerli come costrutti di linguaggio: tutti i modelli di progettazione possono essere implementati in altri modi
• Ciò complicherebbe la lingua - questa è una cattiva idea in quanto rende la lingua più difficile da imparare, rende i compilatori e gli strumenti più difficili da scrivere
• Esistono approcci di implementazione alternativi per molti modelli di progettazione. Scegliere un approccio e benedirlo come parte del linguaggio principale probabilmente indurrebbe le persone a utilizzare tale approccio rispetto ad altri (il che potrebbe essere molto meglio in alcune circostanze)
• L'eccessiva dipendenza dai modelli di progettazione è probabilmente una cattiva idea - i progettisti del linguaggio probabilmente si rendono conto che non dovrebbero incoraggiarli ulteriormente.

Inoltre, se si utilizza un linguaggio sufficientemente potente con capacità di metaprogrammazione (ad esempio un Lisp), diventa relativamente semplice estendere il linguaggio da soli per implementare qualsiasi modello di progettazione. Non è necessario alcun modello nella lingua principale se è facile aggiungerne uno con una macro a 5 righe.

Perché i modelli di progettazione più utilizzati (MVC, Factory, Strategy, ecc.) Non vengono aggiunti ai costrutti del linguaggio?

La maggior parte di questi schemi può essere implementata nella maggior parte dei linguaggi di programmazione senza un supporto linguistico specifico. Prendi ad esempio MVC in Java:

• Puoi codificarlo direttamente.
• Puoi implementarlo usando un generatore di applicazioni ... e prendersi cura di un sacco di altre piastre da caldaia contemporaneamente.
• È possibile implementarlo utilizzando le classi di libreria "framework".
• È possibile implementarlo utilizzando annotazioni ed elaborazione di annotazioni statiche o di runtime.

Date tutte queste opzioni, c'è poco valore nell'estensione diretta della lingua. E ci sono un certo numero di "aspetti negativi":

• Tenderebbe a ingombrare la sintassi del linguaggio, (probabilmente) rendendo la vita più difficile per i programmatori alle prime armi.
• Tenderebbe a rendere le specifiche del linguaggio più grandi e complesse, rendendolo più difficile per gli implementatori del linguaggio. (E, naturalmente, maggiore è la specifica, maggiore è la probabilità che ci siano errori e incongruenze.)
• Ci sarà sempre la pressione di aggiungere ancora un altro modello ... portando a problemi / preoccupazioni con la stabilità del linguaggio.
• Supportando schemi specifici nella lingua, è possibile stabilire modi specifici per supportare gli schemi, che potrebbero non essere adatti ad alcune applicazioni.

Loro sono.

Le funzioni erano un modello di progettazione nel codice assembly prima di diventare un costrutto di linguaggio in C.

Le funzioni virtuali erano un modello di progettazione in C prima che diventassero un costrutto langiage in C ++.

Tuttavia, c'è un compromesso. Se il modello prevede la produzione di codice boilerplate (anche un paio di parole chiave), ciò indica che sarebbe una funzione linguistica utile. Ma se il modello è semplice e chiaro, ad es. C è "per (int i = 0; i <10; i ++)", è comunque utile per tutti scriverlo allo stesso modo, ma non è significativamente più lungo di "per i = 0 a 10" e ha il vantaggio significativo che è ovvio come modificarlo per creare un loop leggermente diverso.

Leggi il libro 'gang of four' e diventerà chiaro che:

1. I modelli di progettazione nel libro sono in realtà convenzioni di smalltalk ben note codificate in altre lingue OO.
2. Pertanto, tali schemi non possono essere inclusi nel linguaggio OO - sarebbe reimplementare smalltalk all'interno di quelle lingue - è meglio usare smalltalk direttamente
3. Il motivo per cui i modelli di progettazione sono utili è perché de-enfatizzano il ruolo del linguaggio attualmente utilizzato e si concentrano su altri problemi oltre alla sintassi. La codifica di quei modelli all'interno del linguaggio perderebbe questa caratteristica dei modelli di progettazione.
4. Il vero problema nella domanda precedente è che manca il punto che scrivere software non riguarda solo l'apprendimento della lingua. È importante prendere una distanza sufficiente da quale lingua fornisce direttamente e concentrarsi sui requisiti attuali.

Perché i modelli di progettazione sono implementati perfettamente con il codice utente. Il suo esempio è avvenuto solo perché è PHP- ma se davvero avessi bisogno di prestazioni, lavoreresti semplicemente in un'altra lingua o otterrai HipHop o qualcosa del genere.

Le funzionalità del linguaggio sono complicate, sia da specificare che da implementare, e non è giustificabile crearne una al solo scopo di "Gli idiomi attuali sono X". Risparmieresti a malapena qualsiasi codice utente significativo, e per niente.

Eh, domanda viziata ma non sono d'accordo con molte risposte a seconda di dove hai impostato "Design Patterns" sul quadrante semantico incluso quello accettato.

Nel senso del libro GoF Design Patterns, direi che dipende. MVC, ad esempio (in realtà non è un modello GoF ma si adatta a quello stampo), è totalmente inappropriato esprimerlo come costrutti linguistici per il consumo di massa (anche se potrebbe avere senso per uno specifico progetto PHP). Come modello architettonico ci sono continue variazioni sul tema e un'ampia varietà di interpretazioni perfettamente legittime su di esso per diverse circostanze (anche se molti si allontanano così tanto da MVC, probabilmente non dovrebbero più chiamarlo MVC). Ad esempio, sul web, la barriera http lo rende in qualche modo scomodo a seconda che si stia cercando di includere il lato client (senza dubbio dolorosamente) nell'equazione e ciò che si sta considerando "la vista" da un altro prospettiva opportunamente strettamente lato server.

Iteratore d'altra parte è un concetto molto generale che può essere applicato in una varietà molto ampia di modi a una vasta gamma di costrutti.

Il punto in cui si dovrebbe tracciare se qualcosa appartiene a una progettazione linguistica di base, anche in un linguaggio IMO lato server, è il punto in cui qualcosa attraversa la linea dal rendere più facile fare un numero incalcolabile di cose più facilmente rispetto a fare una cosa troppo specifica ma ampiamente implementata come un modello di architettura per te.