Come posso sapere se il software è altamente accoppiato?

Conosco il termine "altamente accoppiato" 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ò applicarsi a qualsiasi lingua.

Modificare:

Nel caso in cui qualcuno fosse interessato, questo articolo sembra utile: nel perseguimento della qualità del codice: attenzione alla coppia stretta! (IBM)

L'indicatore numero uno dei moduli mal accoppiati secondo me sono le dipendenze bilaterali. Ad esempio, Module1 chiama alcune funzioni in Module2 e Module2 chiama alcune funzioni in Module1.

La maggior parte delle interfacce dovrebbe essere unidirezionale. Se il modulo chiamato deve passare alcune informazioni al modulo chiamante che non viene restituito come parte della chiamata, dovrebbe utilizzare una sorta di meccanismo di trasmissione dei messaggi o di attivazione di eventi come una coda di messaggi. Idealmente, l'interfaccia di passaggio da handle a messaggio dovrebbe essere passata durante un processo di inizializzazione o registrazione. In questo modo l'interfaccia viene completamente estratta in modo tale che il modulo non si preoccupi effettivamente per chi è l'evento ... quindi è disaccoppiato.

Un'altra indicazione è quando un modulo chiama costantemente qualche altro modulo per un determinato set di dati. Questo dovrebbe farti mettere in dubbio chi dovrebbe effettivamente possedere il set di dati. Perché questo modulo in questione deve sempre vedere i dati che appartengono ad altri moduli?

Un terzo strumento per così dire è chiedersi: "Posso estrarre questo modulo e sostituirlo senza richiedere modifiche ad altri moduli.

Questa non è affatto una lista esaustiva, ma sono le prime tre cose che mi chiedo durante la progettazione del software.

Il vecchio proverbio del design è: "Puoi toccare i tuoi amici e puoi toccare i tuoi privati. Ma non puoi toccare i tuoi amici privati". Questo è l'accoppiamento in breve.

I segni di codice altamente accoppiato includono interfacce molto grandi che consentono alle persone di conoscere i dettagli privati ​​dell'implementazione e oggetti che sembrano "conoscersi molto l'uno dell'altro". Esistono strumenti per l'analisi automatica che contrassegneranno il codice che sembra strettamente abbinato per te. Vedi http://www.scitools.com/features/metricsintro.php per uno casuale. (Non ho idea di quanto funzioni bene. È appena arrivato abbastanza alto in una ricerca su Google.)

Prova a scrivere alcuni test unitari per le lezioni. Se non riesci facilmente a testare le classi senza la necessità di creare / deridere un sacco di classi di supporto o un db / ui, allora è un segno sicuro di cattivi accoppiamenti / dipendenze.

È anche una delle migliori cure, ma devi farlo durante la codifica (come TDD) per tenerti onesto.

Il segno ovvio per me è che tutto è pubblico.

L'altro segno è rappresentato dalle violazioni della Legge sulle Demetra - eccessive citazioni di riferimenti a SomeObj.SomeProp.SomeProp su interfacce non fluide.

Una volta ho visto quella che da allora ho soprannominato una "classe di burattinai" che ha creato al volo un modulo di immissione dei dati. Aveva diverse altre violazioni del design del software, quindi l'accoppiamento eccessivo era l'ultimo dei suoi problemi.

Quando ha recuperato i dati dai controlli che ha creato, ha fatto così:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

L' effetto a catena .

Ogni modifica ha un effetto a catena attraverso tutti i moduli strettamente accoppiati.

Il principio "Aperto-Chiuso" è stato violato in quanto non è correttamente chiuso e il cambiamento perde.

Controlla il numero di # include / imports ecc. Tra classi / pacchetti / dlls / jars / whatnots. Prova a tracciare un grafico di questo, mentalmente, manualmente o usando un qualche tipo di strumento.

• Se quel grafico è denso (cioè molte connessioni ovunque), il tuo sistema è monolitico e altamente accoppiato.
• Se è chiaramente suddiviso in livelli, senza connessioni tra i livelli / trogolo e le connessioni sono poche, hai un sistema modulare e disaccoppiato.

Se trovi impossibile implementare una funzione perché non hai idea di dove vada una responsabilità specifica, allora il tuo sistema è troppo stretto.

Per segni molto basilari potresti considerare di cercare il numero di interfacce e il loro utilizzo tra classi di pacchetti diversi (di solito il codice debolmente accoppiato contiene interfacce e ci sono limitate interazioni dirette tra le singole classi in pacchetti diversi), numero di nomi di classe che possono essere usato per raggruppare altre classi (nel codice liberamente accoppiato l'interazione effettiva tra classi che hanno lavori diversi è fatta da funzioni di interfaccia o da funzioni di classi più comuni / di raggruppamento) o numera le variabili pubbliche all'interno delle classi (più liberamente molto meno / anche nessuna variabile pubblica ).

Praticamente tutti gli odori di codice indicano in qualche modo un accoppiamento superfluo. Suppongo che l'odore che indicherebbe maggiormente l'accoppiamento potrebbe essere "Intimità inadeguata" (il mio odore preferito).

Suppongo che un altro metodo ragionevole da misurare sarebbe quello di contare le linee nel diagramma UML. Se hai N oggetti e N ^ N (o più) linee tra loro, allora il tuo codice è praticamente accoppiato al massimo. Le linee N sarebbero probabilmente il minimo possibile.