Sono riuscito a ridimensionare tutte le mie vecchie applicazioni che non utilizzavano modelli di progettazione documentati. Qualunque modello sia, non lo so. In larga misura, ho sentito solo la necessità di utilizzare semplici concetti OOP.
Il concetto di Design Patterns è complesso e difficile da comprendere. Una volta implementato, come determinare se l'implementazione è corretta e l'applicazione possiede un accoppiamento molto libero?
Per mantenere la risposta concisa, direi se le seguenti caratteristiche sono visibili nel codice, puoi essere sicuro che i modelli sono in atto anche se non hai fatto sforzi intenzionali (che non è un problema) verso di esso.
Caratteristiche desiderate:
Se sei ancora curioso di identificare e taggare il tuo codice con i nomi dei modelli reali, ti consiglio di eseguire le seguenti azioni per ottenere il lancio della palla.
Questo dovrebbe darti un'idea giusta.
Hai menzionato entrambi i modelli di design e l'accoppiamento. Questi sono concetti separati, quindi li tratterò separatamente. L'unica vera connessione è che i modelli di design tendono a promuovere un accoppiamento lento (poiché è un aspetto importante del buon design).
Modelli di design
Il concetto di Design Pattern è in realtà piuttosto semplice: sono solo un insieme di modelli su come affrontare vari problemi comuni. Ci sono 2 motivi principali per cui sono popolari:
Come fai a sapere di averlo implementato correttamente? È difficile. Per la maggior parte dei modelli è semplice: lo hai fatto o no. Alcuni modelli sono meno definiti di altri - ad es. model-view-controller . Modelli come questo sono meglio usati come linee guida generali. Le specifiche del modo in cui lo implementate sono meno importanti della comprensione dei motivi per cui il modello esiste e di ciò che è destinato a realizzare.
I modelli di progettazione non sono "l'unico vero modo". Spesso dovrai o adattarli per i tuoi scopi specifici, o talvolta non ci saranno modelli adatti ai requisiti. Costringere un modello di progettazione in cui non si adatta è una cattiva idea; è come usare un buon martello quando quello che vuoi è un cacciavite.
Accoppiamento
Questa è un'idea davvero importante nell'informatica. Poiché i requisiti per la maggior parte dei progetti software cambiano nel tempo (a volte in modo significativo), la capacità di un progetto di far fronte alle modifiche è importante. L'accoppiamento è fondamentalmente la misura di "quanto sarebbe difficile scambiare questo componente con un altro?" Il "componente" potrebbe essere un metodo, una classe, un pacchetto, una libreria, ecc.
Esistono vari tipi di accoppiamenti elencati in questo articolo di Wikipedia .
La risposta è in realtà lo scopo per cui si desidera scrivere gli schemi di progettazione dall'inizio. Perché vuoi la flessibilità?
Questo è un cambiamento; i requisiti cambiano. Prova a modificare qualcosa nelle tue esigenze che si riflette nel cambio di codice e scopri quanto è facile / difficile farlo.
L'utilizzo di schemi di progettazione è un'azione preventiva. Si utilizzano i temi di progettazione per facilitare il lavoro quando si ridimensiona l'applicazione in un secondo momento. Ovviamente, per facilitare il tuo lavoro in seguito devi fare un po 'più di lavoro ora. quindi la vera domanda è quanta variazione puoi aspettarti in futuro e che cos'è questo cambiamento. Se non hai bisogno di scalabilità e flessibilità, puoi eliminare gli schemi di progettazione.
Gli schemi di progettazione sono essi stessi un'implementazione dei principi di progettazione orientata agli oggetti. Finché seguirai questi principi, le tue applicazioni saranno flessibili e scalabili; anche se non hai davvero un modello di progettazione reale. Come ha commentato Joachim Sauer sopra, sono soluzioni comuni a problemi comuni.
Leggi altre domande sui tag design-patterns