Perché i modelli di progettazione OOP non sono inclusi nelle librerie standard?

Voglio sfidare la tua premessa di base, ovvero che i modelli di progettazione non vengono aggiunti alla libreria standard. Ad esempio, java.util.Iterator<E> si trova nella libreria standard ed è un implementazione del Pattern di design di Iterator . java.util.Observable / java.util.Observer è un'implementazione di Pubblica / sottoscrivi modello di progettazione . java.lang.reflect.Proxy è un'implementazione di Pattern di progettazione proxy .

Guardando altre lingue, ad es. Ruby ha il delegate e forwardable librerie, entrambe le implementazioni del Proxy Design Pattern, il observer , implementazione del modello di pubblicazione / sottoscrizione e singleton libreria, un'implementazione del Singleton Design Pattern .

I modelli di progettazione sono progetti ricorrenti che non possono essere catturati in una classe o in una libreria. Di solito hanno a che fare con l'interazione di più classi. La libreria standard di una lingua può utilizzare modelli proprio come può fare un altro codice, ad es. la libreria IO Java utilizza il pattern decoratore. Ma il pattern decoratore stesso non può essere catturato in una singola classe o libreria.

Una tipica definizione di design patter (presa da Wikipedia):

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

(La mia enfasi) Quindi per definizione una libreria standard non può fornire schemi di progettazione come componenti riutilizzabili nello stesso modo in cui fornisce classi regolari come componente riutilizzabile. O per dirla in altro modo: se un pattern di design può essere catturato nel codice riusabile, smettiamo di chiamarlo pattern. List<T> è un progetto ampiamente utile, ma dal momento che questo può essere catturato in una classe riusabile, di solito non lo chiamiamo "schema" - è solo una classe.

Ma un framework incoraggia e in un certo senso impone l'uso di determinati modelli di design. Per esempio. un framework MVC più o meno costringe a scrivere codice seguendo lo schema MVC.

Ci sono diversi motivi per cui i pattern non possono essere catturati come classe riutilizzabile, a seconda del modello:

1. Il modello è troppo astratto. Per esempio. un "adattatore" è un modello in cui una classe trasforma un'interfaccia ad un'altra. Il concetto è piuttosto semplice, ma l'effettiva implementazione dipenderà completamente dalla semantica dei due interfacce in attuazione. Semplicemente non c'è codice boilerplate condiviso tra diverse applicazioni del modello Adapter, quindi non può essere incluso come componente riutilizzabile in una libreria.

2. Il pattern non è possibile implementare in una forma riutilizzabile. Alcuni modelli sono davvero soluzioni alternative per i limiti della lingua. Per esempio. il visitatore" pattern è davvero un trucco per consentire un linguaggio a singola spedizione supporta la spedizione multipla. C'è qualche codice di codice, ma il il codice boilerplate non può essere generalizzato in modo riutilizzabile. Una lingua con il supporto integrato per la spedizione multipla non sarebbe necessario il modello di visitatore in primo luogo.

   (E come sottolineato in diversi commenti, l'implementazione Singleton fornita non può essere generalizzata a una classe riutilizzabile, dal momento che le statiche non sono ereditate.)

Temo che una sottigliezza della parola "schema" si stia perdendo qui. Pensa a un vestito. Un modello definisce le caratteristiche, ad es. ci sono tasche, braccia, gambe ecc. Tuttavia, non definisce ogni singolo dettaglio (bottoni, tessuto, fodera, ecc.) - questo è lasciato all'implementatore.

Sì, per molti modelli di progettazione esiste un codice standard che molti di noi tendono ad usare, ma per altri, c'è un modo per ottenere il modello senza un metodo generalmente concordato.

Why isn't there java.util.Singleton and then we inherit it?

Perché un singleton è static e non possiamo usare l'ereditarietà su static membri. Inoltre, è considerata una pratica migliore dichiarare un Singleton usando un enum:

public enum MySingleton{
    INSTANCE;

    //class content goes below
}

Sarebbe anche difficile usare l'ereditarietà qui come enum estende java.lang.Enum e questo non può essere modificato, e non c'è modo di rimuovere la riga 1 del codice boilerplate.

Ecco perché java.util.Singleton non esiste.

Why aren't design patterns added to the languages constructs?

Molti sono già nella libreria standard di jdk - alcune classi forniscono alcune funzionalità quando si utilizzano i pattern, ad esempio: java.util.Observer viene implementato quando si utilizzano i pattern Observer e altri utilizzano schemi di progettazione, ad esempio: java.lang.StringBuilder utilizza il modello Builder.

Per quanto riguarda il motivo per cui non li vedi tutti:

• Alcuni pattern di progettazione sono difficili da astrarre con classi / interfacce / enumi / ect ( java.util.Singleton per esempio).
• Non vale la pena inserire la libreria standard.
• Non è stato ancora pensato.
• Non ce n'è bisogno.