Ho studiato e implementato modelli di progettazione per alcuni anni, e mi chiedo. Quali sono alcuni dei modelli di progettazione più recenti (dal GOF)? Inoltre, quale dovrebbe essere il prossimo, simile a me stesso, a studiare [in termini di progettazione del software]?Nuovi modelli di design/strategie di progettazione
Nota: uso da tempo TDD e UML. Sono curioso dei nuovi cambiamenti di paradigma e dei nuovi schemi di progettazione.
Sono sorpreso che nessuno abbia menzionato il libro di Martin Fowler Patterns of Enterprise Application Architecture. Questo è un libro eccezionale con dozzine di pattern, molti dei quali sono usati nel moderno design ORM (repository, record attivo), insieme a una serie di pattern layer UI. Altamente raccomandato.
Un enorme cambiamento da un aspetto di manutenzione è l'uso di DVCS. Se non si sa ciò che si è o non è stato utilizzato uno, consiglio vivamente la lettura su due battitori duri:
Mercurial (Hg): https://www.mercurial-scm.org/
git: http://git-scm.com/
che hanno fatto un bel po 'per cambiare il flusso di lavoro dell'ambiente di programmazione comune. Non sono proprio un modello/disegno che spio, ma non penso che TDD o UML siano modelli/disegni tecnici a un certo livello. Forse più come pratiche comuni che riguardano la programmazione.
io sono un appassionato seguace e sostenitore della PCMEF (now PCBMER) framework
Here's una visione più semplice di esso.
Si capisce che i sistemi aziendali sono un enorme complesso e, combinando una serie di altri modelli di progettazione insieme nel framework PCMBER (Presentazione, controllo, mediatore, entità e risorsa), anche il sistema più complesso rimane facile da usnerstand e gestire.
Interessante .. Dovrò dargli un'occhiata. – monksy
C'è approssimativamente un numero infinito di schemi di progettazione. I modelli di progettazione sono proprio questo: una ricorrenza di trucchi che i programmatori usano per fare le cose. La cosa più utile dei pattern GoF è quanto sono famosi. In questo, sono diventati un linguaggio - esattamente ciò che il GoF sperava di ottenere.
Molti altri modelli che si trovano sul Web e in letteratura sono "solo" trucchi utili, non tanto un linguaggio che è possibile utilizzare quando si parla con altri programmatori. Detto questo, ci sono una serie di modelli che sono sorti negli ultimi dieci anni circa, in particolare nel campo dello sviluppo web. Vedi i modelli elencati in patterns book di Martin Fowler.
Non direi che i pattern sono "una ricorrenza di trucchi". Penso che ci sia un bel po 'di più. Creare un buon design richiede un pensiero e una comprensione avanzati su come funziona il sistema, come crescerà, dove è richiesta flessibilità e dove non lo è. Ci sono molti trucchi che i programmatori usano per semplificare la loro vita, ma i trucchi non sono necessariamente un pensiero avanzato nel progetto del sistema. Altri potrebbero non essere d'accordo, ma quando sento "trucchi", penso che "scorciatoie" e non solido, design del software. – JasCav
@ Jason cosa ha a che fare questo con i modelli di progettazione? Quando si risolve un problema di progettazione e si utilizza la stessa idea di soluzione per risolvere lo stesso problema altrove, si utilizza un modello di progettazione. Non promuove la pianificazione, è una ricorrenza di un'idea per risolvere un problema di progettazione. Ci vuole esperienza per usare efficacemente schemi di progettazione, e come scegliere una lingua se la si fa da punti di vista religiosi, fallirai miseramente. Non devi usare schemi di progettazione per fare qualcosa di giusto, e molto spesso usi schemi di progettazione senza nemmeno accorgertene. – wilhelmtell
Il motivo per cui ho detto quello che ho fatto è dovuto al modo in cui hai espresso la tua risposta. Per dire che i design pattern sono "solo trucchi" e che il GoF è utile solo perché "sono diventati famosi" sta ignorando completamente il fatto che un buon design richiede una pianificazione e una comprensione di come costruire quel design con una comprensione di PERCHE ' usando un design. Certo, posso incidentalmente imbattersi in un buon design, proprio come un architetto può incappare in una buona struttura per un edificio. Non significa che il software o l'edificio sono progettati bene. Gli schemi di progettazione sono più che semplici "trucchi". – JasCav
Uno dei più recenti che ho trovato particolarmente utile è Domain Driven Design. Non tanto un modello a sé stante, ma più di una mentalità - per concentrarsi sugli oggetti del dominio - cioè le cose che modellate e costruite il resto dell'applicazione attorno ad esso.
Ho scoperto che dava significato a principi che tutti noi conoscevamo prima, ma che erano troppo pigri per affrontare, come il principio di responsabilità unica e la separazione delle preoccupazioni. Prendo questi due particolarmente più seriamente ora.
Un altro asse di miglioramento per me era TDD e Iniezione di dipendenza. Ho scoperto che con molte interfacce e classi che li implementano sono stato in grado di lasciar andare questa paura di definire solo una volta qualcosa. Questo non vuol dire che sia in conflitto con DRY (Do not Repeat Yourself) molto. Va bene avere due classi con le stesse proprietà se i loro scopi sono diversi. Incapsulamento e SRP sono molto più importanti della sola definizione di una proprietà una volta.
Questo è un po 'quello che stavo guardando. Dalla roba risultante da OMG ... Trovo che non ci siano molti cambiamenti da GOF. – monksy
DDD non è un motivo di progettazione. È uno stile architettonico combinato con uno stile di gestione del cliente. –
Umm ... nessuna delle cose che le persone hanno menzionato sono schemi di progettazione.
GOF è stato scritto implicitamente con Java in mente. Ha esplorato lo spazio abbastanza bene.Tuttavia, una volta entrati in altre lingue, alcuni schemi non sono più necessari (l'Observer è usato raramente in un linguaggio come C# che supporta eventi) e alcuni nuovi emergono. Prenditi i libri Pro JavaScript Design Patterns o Design Patterns In Ruby e guarda cosa succede ai pattens stand-by in questi paradigmi molto diversi.
I miei preferiti ultimamente sono arrivati appoggiandosi alla deriva funzionale dei linguaggi moderni. Sono un grande fan di nested closures e dei modi funzionali di affrontare alcuni degli stessi problemi che fa GoF (di nuovo, vedere il libro Ruby per grandi esempi). Sono anche innamorato dell'idea di domain-specific languages interna che si apre a tutta una serie di modelli di design (comprese le chiusure annidate). Anche l'event-aggregation sembra essere pronta a colpire nel mondo .Net nel prossimo futuro.
Un paio di altri grandi che hanno colpito la scena, ma non sono discussi tanto in GoF - probabilmente perché sono più di alto livello di quello che quei ragazzi stavano andando - sono Inversion Of Control Containers, Message Bussing, Orientato all'aspetto -Programmazione, Model-View-Controller, Model-View-Presenter, Model-View-ViewModel e il loro ilk.
A proposito, questi non sono schemi di progettazione, ma se stai cercando di progredire al di là di TDD, inizia a guardare allo Sviluppo guidato dal comportamento e al Contesto/Specifica.
+1: i pattern GoF sono Java-esque, lingue diverse hanno idiomi diversi. –
Sono sorpreso dal tuo commento che Observer è usato raramente in C#. È incorporato nella lingua (tipo "evento") e la possibilità di aggiungere più abbonati agli eventi con l'operatore + =. Il .NET framework fornisce definizioni di interfaccia per la notifica delle modifiche di proprietà e di raccolta; questi sono cruciali per il databinding in WPF e Silverlight. Se il pattern "Observer" non viene richiamato molto, è perché è diventato un concetto fondamentale. –
@Cyclon è esattamente il mio punto. Il bisogno di osservabili è ancora lì, ma l'implementazione di GoF è usata raramente (non ho ancora guardato IObservableCollection ma potrebbe fare qualcosa di simile), è stata soppiantata da una funzionalità del linguaggio. –
Ancora una volta, voglio sottolineare che quelli non sono realmente modelli di design, sono modelli di architettura. Simile, ma molto più alto livello. –