Come determinare se il modello di progettazione è implementato correttamente?

Sono in grado di ridimensionare con successo tutte le mie vecchie applicazioni che non utilizzavano modelli di progettazione documentati. Qualunque sia il motivo 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 capire. Quando implementato, come determinare se l'implementazione è corretta e l'applicazione possiede un vero accoppiamento libero?

Per mantenere la risposta concisa, direi che se nel tuo codice sono visibili le seguenti caratteristiche, puoi essere sicuro che i modelli sono in atto anche se non hai fatto sforzi deliberati (che non è un problema) nei suoi confronti.

Caratteristiche desiderate:

1. La tua base di codice è testabile a livello di unità
2. Ogni volta che stai implementando richieste di modifica, stai apportando modifiche solo alle classi pertinenti che sono correlate nel dominio.
3. La tua base di codice non mostra entropia software .

Se sei ancora curioso di identificare e taggare il tuo codice con i nomi dei modelli reali, ti consiglierei di eseguire le seguenti azioni per far rotolare la palla.

1. Decodifica la tua base di codice per generare alcuni daigrammi UML.
2. Confrontare visivamente i diagrammi con qualsiasi riferimento pronto del materiale di riferimento dei motivi.

Questo dovrebbe darti un'idea giusta.

Citi sia i modelli che l'accoppiamento. Questi sono concetti separati, quindi li tratterò separatamente. L'unica vera connessione è che i modelli di progettazione tendono a promuovere l'accoppiamento libero (poiché è un aspetto importante del buon design).

Modelli di progettazione

Il concetto di Design Patterns è in realtà abbastanza semplice: sono solo una serie di modelli su come affrontare vari problemi comuni. Ci sono 2 motivi principali per cui sono popolari:

1. Sono "comprovati": sono stati utilizzati molte volte e sono generalmente noti i vantaggi / gli svantaggi di ciascuno, in particolare sono noti tutti i problemi sottili che potrebbero causare grossi problemi.
2. Forniscono un insieme comune di terminologia e consentono quindi una comunicazione più semplice. Se qualcuno dice "la classe X svolge il ruolo di osservatore nel modello di osservatore", gli sviluppatori che hanno familiarità con il modello possono immediatamente capire cosa sta succedendo.

Come fai a sapere che l'hai implementato correttamente? È difficile. Per la maggior parte dei motivi è semplice: o l'hai crogiolata o no. Alcuni modelli sono definiti in modo meno chiaro di altri, ad esempio il controller della vista modello . Modelli del genere sono meglio usati come linee guida generali. I dettagli su come implementarlo sono meno importanti della comprensione delle ragioni per cui esiste il modello e di cosa si intende realizzare.

I modelli di progettazione non sono "l'unico vero modo". Spesso dovrai adattarli per i tuoi scopi specifici, oppure a volte non ci saranno schemi che soddisfino i requisiti. Costringere un modello di design dove non si adatta è una cattiva idea; è come usare un martello davvero buono quando quello che vuoi veramente è 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 sostituire questo componente con un altro?" Il 'componente' potrebbe essere un metodo, una classe, un pacchetto, una libreria, ecc.

Esistono vari tipi di accoppiamento elencati in questo articolo di Wikipedia .

La risposta è in realtà lo scopo che si desidera scrivere motivi di progettazione dall'inizio. Perché vuoi flessibilità?

Questo è cambiamento; i requisiti cambiano. Prova a cambiare qualcosa nei tuoi requisiti che si riflette nella modifica del codice e vedi quanto è facile / difficile farlo.

L'uso dei modelli di progettazione è un'azione preventiva. Si utilizza paterns di progettazione per facilitare il lavoro quando si ridimensiona l'applicazione in un secondo momento. Certo, per facilitare il tuo lavoro in seguito devi fare un po 'più di lavoro ora. quindi la vera domanda è: quanti cambiamenti puoi aspettarti in futuro e quale cambiamento. Se non hai bisogno di scalabilità e flessibilità, puoi eliminare i modelli di progettazione.

I modelli di progettazione sono essi stessi un'implementazione dei Principi di progettazione orientati agli oggetti. Se segui questi principi, le tue applicazioni saranno flessibili e scalabili; anche se non hai un vero modello di design. Come Joachim Sauer ha commentato sopra, sono soluzioni comuni a problemi comuni.