Ho familiarità con il termine "altamente accoppiata", ma sono curioso di sapere se ci sono segni (odori di codice) che possono indicare che il codice è altamente accoppiato. Attualmente sto lavorando con Java EE ma questo può essere applicato a qualsiasi lingua.
Modifica
Nel caso in cui qualcuno fosse interessato, questo articolo sembra utile: Alla ricerca della qualità del codice: Attenzione la coppia stretta! (IBM)
L'indicatore numero uno di moduli malamente accoppiati a mio avviso sono le dipendenze bilaterali. Ad esempio, Module1 one chiama alcune funzioni in Module2 e Module2 chiama alcune funzioni in Module1.
La maggior parte delle interfacce dovrebbe essere unidirezionale. Se il modulo che è stato chiamato deve passare alcune informazioni al modulo chiamante che non viene restituito come parte della chiamata, allora dovrebbe utilizzare una sorta di meccanismo di trasmissione di messaggi o di attivazione di eventi come una coda di messaggi. Idealmente, l'handle per l'interfaccia di passaggio dei messaggi deve essere inoltrato durante alcuni processi di inizializzazione o registrazione. Ciò astrae completamente l'interfaccia in modo tale che il modulo non si preoccupa di chi è l'evento ... quindi è disaccoppiato.
Un'altra indicazione è quando un modulo chiama costantemente un altro modulo per alcuni set di dati specifici. Questo dovrebbe farti mettere in discussione chi dovrebbe effettivamente possedere il set di dati. Perché questo modulo in questione ha sempre bisogno di vedere i dati che appartengono ad un altro modulo?
Un terzo strumento, per così dire, è chiedersi: "Posso estrarre questo modulo e sostituirlo senza richiedere modifiche ad altri moduli.
Questo non è affatto un elenco esaustivo, ma sono le prime tre cose che mi pongo durante la progettazione del software.
Il vecchio detto di design è: "Puoi toccare i tuoi amici e puoi toccare i tuoi amici, ma non puoi toccare i tuoi amici privati". Questo è l'accoppiamento in poche parole.
I segni di codice altamente accoppiato includono interfacce molto grandi che consentono alle persone di conoscere i dettagli privati dell'implementazione e gli oggetti che sembrano "conoscere molto l'uno dell'altro". Esistono strumenti per l'analisi automatica che contrassegneranno il codice che sembra strettamente accoppiato per te. Vedi link per uno casuale. (Non ho idea di quanto funzioni bene. È appena diventato abbastanza alto in una ricerca su Google.)
Prova a scrivere alcuni test unitari per le classi. Se non è possibile testare facilmente le classi senza la necessità di creare / eseguire il mockload di classi di supporto o di un db / ui, allora si tratta di un segno sicuro di combinazioni / dipendenze errate.
È anche una delle migliori cure, ma devi farlo durante la codifica (come TDD) per mantenerti onesto.
Il segno evidente per me è che tutto è pubblico.
L'altro segno è la violazione di Law of Demeter - eccessivo questo.SomeObj.SomeProp.SomeProp riferimenti su interfacce non fluenti.
Una volta ho visto quello che da allora ho soprannominato una "classe burattinai" che ha costruito un modulo di inserimento dati al volo. Aveva diverse altre violazioni del design del software, quindi l'accoppiamento eccessivo era l'ultima delle sue preoccupazioni.
Quando recuperava i dati dai controlli creati, lo faceva in questo modo:
var control = activeDataEntryControl as CustomTextBox;
if (control != null)
result = control.NestedTextBox.Text;
/* several other controls */
Effetto a catena .
Ogni cambiamento ha un effetto a catena attraverso tutti i moduli strettamente accoppiati.
Il principio "Aperto-Chiuso" è stato violato in quanto non è chiuso correttamente e cambia le perdite.
Controlla il numero di # include / importazioni ecc tra classi / pacchetti / dll / jar / whatnot. Prova a disegnare un grafico di questo, mentalmente, manualmente o usando qualche tipo di strumento.
Se trovi impossibile implementare una funzione perché non hai idea di dove si trovi una specifica responsabilità, allora il tuo sistema è troppo strettamente accoppiato.
Per i segni molto di base si può considerare la ricerca del numero di interfacce e del loro utilizzo tra classi di pacchetti diversi (di solito il codice a connessione libera contiene interfacce e vi sono interazione diretta limitata tra le singole classi in pacchetti diversi), numero di nomi di classe che può essere usato per raggruppare altre classi (nel codice liberamente accoppiato l'interazione effettiva tra classi che hanno lavori diversi sono fatte da funzioni di interfaccia o da funzioni di classi più comuni / di raggruppamento) o numero di variabili pubbliche all'interno delle classi (più liberamente molto meno nessuna variabile pubblica).
Praticamente tutti gli odori del codice indicano un accoppiamento superfluo in qualche modo. Suppongo che l'odore che potrebbe indicare l'accoppiamento potrebbe essere "Intimità inappropriata" (il mio odore preferito).
Suppongo che un altro metodo ragionevole per misurare sarebbe contare le linee nel diagramma UML. Se hai N oggetti, e N ^ N (o più) linee tra di loro, allora il tuo codice è praticamente accoppiato al massimo. Le linee N sarebbero probabilmente le più minimali possibili.
Leggi altre domande sui tag architecture code-smell