Perché i modelli di progettazione non sono stati aggiunti ai costrutti dei linguaggi?

I modelli di progettazione sono aggiunti in qualsiasi momento al costrutto del linguaggio. Hai mai sentito parlare del pattern di progettazione Call subroutine ? No? Neanche io. Questo perché le chiamate di subroutine, che hanno un modello di design nei primi anni '50, sono state aggiunte alle lingue praticamente all'istante. Al giorno d'oggi, sono persino presenti nei set di istruzioni del codice macchina delle CPU.

Che dire del motivo di design For Loop ? Il pattern di progettazione While Loop ? Il pattern di progettazione Switch ? Il modello di progettazione Oggetto ? Il modello di progettazione Classe ? Tutti questi sono stati aggiunti in alcune lingue.

Alcuni di loro lo sono. Ad esempio gli iteratori sono funzionalità linguistiche in molte lingue e le loro librerie standard (hi there, foreach e yield return). Anche Observer è spesso presente in forma di eventi (non in PHP - devi gestire tu stesso l'abbonamento callback). Il comando è la caratteristica principale di WPF.

Molti altri non trarrebbero alcun beneficio dal supporto linguistico (e renderebbero la lingua più ingombrante): come semplificheresti i Controller se potessi progettare funzionalità linguistiche per loro? Come classi, beneficiano di tutte le infrastrutture già presenti per supportare le classi: puoi istanziarle, passarle in giro e, ad esempio, testarle come qualsiasi altro oggetto.

L'unico componente di MVC che IMO potrebbe trarre beneficio da una sorta di supporto linguistico è View (con un motore di template ufficiale) - e in PHP è già supportato - puoi creare e caricare in modo dinamico script PHP (che sono spesso con una sorta di pre-elaborazione usata come modelli).

Lo stesso vale per il metodo factory - come lo semplificheresti, se potessi avere qualsiasi tipo di linguaggio che volevi? Una caratteristica che alcuni linguaggi (come C ++) mancano è la capacità di costruire oggetti da questo nome di tipo, ma la maggior parte dei linguaggi di livello superiore può farlo (e non è nemmeno necessario creare metodi di fabbrica utili). Oltre a questo, tutto ciò che serve è essere in grado di creare un metodo che istanzia e restituisce e oggetto.

Alcuni modelli di design vengono effettivamente aggiunti come costrutti del 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 potrebbero codificare qualcosa di simile esplicitamente come modello di progettazione se non faceva parte della sintassi principale.

Ma per concentrarti sulla domanda: ci sono molte ragioni per cui non vorrai aggiungere troppi modelli di progettazione a una lingua:

• Non è necessario aggiungerli come costrutti linguistici: tutti gli schemi di progettazione possono essere implementati in altri modi
• Complicerebbe la lingua - questa è una cattiva idea in quanto rende più difficile l'apprendimento della lingua, rendendo più difficili da scrivere i compilatori e gli strumenti
• Esistono approcci di implementazione alternativi per molti modelli di progettazione. Scegliere un approccio e benedirlo come parte del linguaggio di base potrebbe indurre le persone a utilizzare tale approccio rispetto ad altri (il che potrebbe essere molto meglio in alcune circostanze)
• L'eccessiva dipendenza dai modelli di design è probabilmente una cattiva idea in ogni caso - i designer di 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 la lingua da sé per implementare un modello di progettazione qualsiasi . Non è necessario alcun modello nel linguaggio principale se è facile aggiungerne uno con una macro a 5 righe.

Why aren't the most used design patterns (MVC, Factory, Strategy,...etc.) added to the language constructs?

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

• Puoi codificarlo direttamente.
• Puoi implementarlo utilizzando un generatore di applicazioni ... e occuparti contemporaneamente di un sacco di altri piatti standard.
• Puoi implementarlo usando le classi di libreria "framework".
• Puoi implementarlo utilizzando annotazioni ed elaborazione delle annotazioni statiche o di runtime.

Considerate tutte queste opzioni, c'è poco valore nell'estendere direttamente la lingua. E ci sono una serie di "aspetti negativi":

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

Sono.

Le funzioni erano uno schema di progettazione nel codice assembly prima che diventassero un costrutto linguistico 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 un codice boilerplate (anche un paio di parole chiave), è un'indicazione che sarebbe una caratteristica linguistica utile. Ma se il modello è semplice e chiaro, ad es. C "per (int i = 0; i < 10; i ++)", è comunque utile per tutti scriverlo nello 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 diventerai chiaro che:

1. Gli schemi di progettazione nel libro sono in realtà convenzioni smalltalk ben note codificate in altri linguaggi OO.
2. In quanto tali, questi pattern non possono essere inclusi nel linguaggio OO - sarebbe reimplementing smalltalk all'interno di quei linguaggi - è meglio usare smalltalk direttamente
3. Perché i modelli di progettazione sono utili è perché de-enfatizzano il ruolo della lingua correntemente usata e si concentra su altri problemi rispetto alla sintassi. La codifica di tali schemi all'interno della lingua perderebbe questa caratteristica dei modelli di progettazione.
4. Il vero problema nella domanda di cui sopra è che manca il punto che scrivere software non riguarda solo l'apprendimento della lingua. È importante prendere una distanza sufficiente da ciò che la lingua fornisce direttamente e concentrarsi sui requisiti attuali.

Perché i modelli di progettazione sono implementati perfettamente bene con il codice utente. Il suo esempio è successo solo perché è PHP, ma se effettivamente hai bisogno di prestazioni, dovresti semplicemente lavorare in un'altra lingua o ottenere HipHop o qualcosa del genere.

Le funzionalità linguistiche sono complicate, sia da specificare che da implementare, e non è giustificabile crearne una con il solo scopo di "Gli idiomi attuali sono X". Difficilmente riuscirai a salvare qualsiasi codice utente significativo e per niente.

Eh, domanda stantia ma non sono d'accordo con molte risposte a seconda di dove hai impostato "Motivi di progettazione" sul quadrante della semantica incluso quello accettato.

Nel senso del libro dei modelli di GoF Design, direi che dipende. MVC, ad esempio (in realtà non è un pattern GoF ma si adatta a tale modello), è totalmente inappropriato esprimere 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 circostanze diverse (anche se molti partono così lontano da MVC probabilmente non dovrebbero chiamarlo più MVC). Ad esempio, sul web, la barriera http lo rende un po 'scomodo a seconda che tu stia cercando di includere il lato client (senza dubbio penosamente) nell'equazione e cosa stai considerando "la vista" da un altro prospettiva strettamente lato server.

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

Dove deve essere tracciata la linea se qualcosa appartiene a un progetto di linguaggio di base, anche in un linguaggio specifico del server-side-web, IMO, è il punto in cui qualcosa attraversa la linea dal rendere più facile fare un incalcolabile numero di cose più facilmente rispetto a fare una cosa eccessivamente specifica ma ampiamente implementata come un modello di architettura per te.