Attualmente sto facendo qualche ricerca sui pattern software e sui pattern architetturali per i framework in particolare.
Google non si sta davvero mostrando per questo argomento, quindi sono curioso di sapere quali pattern consideri particolarmente importanti per l'architettura dei framework? Mi sto concentrando su framework per software web, mobile e desktop, come Rails, UIKit, ecc.
Ho difficoltà a pensare a un modello di progettazione GoF che sia inappropriato per l'uso in un framework o più appropriato per l'uso in un framework. I modelli e le strutture sono problemi ortogonali - se un modello è utile, può essere utile in un quadro. Viceversa, se un pattern è utile in un framework, non c'è motivo per cui non possa essere utilizzato anche al di fuori di un framework. I framework sono solo un modo per impacchettare il tuo codice.
I pattern e i framework sono entrambi pensati per essere riutilizzabili, quindi c'è un obiettivo comune nelle due idee e nei framework che spesso fanno un uso pesante dei pattern. In effetti, gran parte del vantaggio di comprendere i modelli di progettazione è che rende molto più facile comprendere i nuovi framework man mano che li si incontra. Detto questo, non conosco schemi di progettazione che siano specificamente concepiti per i framework.
La mia prima domanda sarebbe "perché stai costruendo un quadro?"
Sicuramente ci deve essere qualcosa di sub-ottimale, mancante, rotto o altrimenti difettoso nei framework esistenti, anche se quel qualcosa è solo che non guardano il mondo nel modo in cui lo fai (e non c'è niente di sbagliato costruire un framework per risolvere un dominio problematico "a modo tuo" - che può portare a molta illuminazione su come affrontare i problemi sia per gli autori che per gli utenti del framework).
Supponendo che ci sia una risposta a questa domanda (se non c'è, non c'è alcun motivo per costruire il framework), allora la risposta dovrebbe guidare le tue decisioni sull'architettura. C'è un sacco di malinteso in termini di come vengono visualizzati i modelli di progettazione. Non sono una panacea. Non risolvono i problemi. Sono un modo per gli ingegneri del software di discutere delle strategie di implementazione comuni, ma la strategia di implementazione deriva da ciò che viene implementato.
Forse un buon modo per rendere questo più chiaro sarebbe quello di abbattere alcuni schemi di progettazione comuni.
Per un framework MVC, il punto di riferimento è che si desidera una chiara divisione del codice, una buona separazione delle preoccupazioni. Manutenibilità e riparabilità. Per un ORM ActiveRecord, l'idea sarebbe quella di sottrarre il maggior numero possibile di operazioni al database, consentendo agli utenti di pensare in termini puramente orientati agli oggetti. E così via.
Leggi altre domande sui tag architecture design-patterns frameworks patterns-and-practices architectural-patterns