Dovrei essere più interessato all'accoppiamento tra pacchetti o tra unità di distribuzione?

Question

Ho esaminato le metriche per accoppiamento e anche guarda DSM .

Uno degli strumenti che ho usato riguarda l'accoppiamento tra 'moduli' con un modulo che è un'unità di distribuzione (in questo caso un assieme .net).

Sento che dovrei essere più interessato a guardare l'accoppiamento tra pacchetti (o spazi dei nomi) che con unità di distribuzione.

Dovrei essere più interessato all'accoppiamento tra pacchetti / spazi dei nomi (assicurarsi che le astrazioni dipendano solo dalle astrazioni, i tipi concreti dipendono dalle astrazioni e che non ci siano cicli nelle dipendenze in modo che il refactoring e l'estensione siano facili) o dovrei preoccuparmi di se riesco a distribuire nuove versioni senza dover aggiornare unità di distribuzione invariate?

Cosa misura qualcun altro?

Per quello che vale, la mia sensazione è che se mi concentro sull'accoppiamento pacchetto / spazio dei nomi, l'unità di accoppiamento della distribuzione verrà gratis o almeno sarà più facile.

Answer 1

Innanzitutto, è facile esagerare guardando dipendenze e accoppiamento. Assicurati di non complicarti troppo.

Con questo disclaimer fuori mano, ecco cosa suggerisco.

Esistono in realtà 3 diversi punti di vista sulla gestione di dipendenza / accoppiamento: 1) struttura fisica (ovvero dipendenze di assemblaggio) 2) struttura logica (ovvero dipendenze dello spazio dei nomi) 3) struttura di implementazione (ovvero dipendenze di classe)

Per le app di grandi dimensioni, dovrai almeno esaminare tutte e 3, ma di solito puoi dare la priorità.

Per le app distribuite dal client, il numero 1 può essere molto importante (ad es. per cose come i plug-in). Per le app distribuite all'interno dell'azienda (ad es. Asp.net), l'articolo 1 di solito risulta non essere così importante (esclusi i framework riutilizzati su più app). Di solito puoi distribuire l'intera app in modo abbastanza semplice da non prendere il sovraccarico di una struttura complicata per # 1.

L'articolo n. 2 tende ad essere più un problema di manutenibilità. Conosci i tuoi limiti di livello e la loro relazione con gli spazi dei nomi (ovvero stai facendo 1 livello per spazio dei nomi o sei impacchettato in modo diverso a livello logico). A volte gli strumenti possono aiutarti a imporre i confini del tuo livello osservando la struttura di dipendenza logica.

L'articolo n. 3 riguarda davvero un buon design di classe. Ogni buon sviluppatore dovrebbe impegnarsi a fondo per assicurarsi di assumere solo le giuste dipendenze nelle sue classi. Questo è più facile a dirsi che a farsi, ed è in genere un'abilità che deve essere acquisita nel tempo.

Per avvicinarti un po 'al cuore della tua domanda, l'articolo n. 1 riguarda in realtà il modo in cui i progetti sono strutturati nella soluzione VS. Quindi questo non è un oggetto da misurare. È più di qualcosa che hai impostato all'inizio e lasciato correre. L'articolo n. 2 è qualcosa che potresti usare uno strumento per controllare durante le build per vedere se gli sviluppatori hanno infranto qualche regola. In realtà è più un controllo che una misura. L'articolo n. 3 è davvero quello che vorresti dare una buona occhiata alla misurazione. Trovare le classi nella tua base di codice che hanno un alto numero di accoppiamenti saranno punti dolenti lungo la strada, assicurando la qualità su quei ragazzi. Inoltre, la misurazione a questo livello consente di avere una visione approfondita della qualità (complessiva) della base di codice man mano che si evolve. Inoltre, può darti una bandiera rossa se qualcuno controlla del codice davvero volgare nella tua base di codice.

Quindi, se vuoi dare la priorità, dai un'occhiata a # 1 e # 2. Sapere come dovrebbero apparire. Ma per la maggior parte delle app, l'articolo 3 dovrebbe richiedere più tempo.

Questa risposta, ovviamente, esclude enormi framework (come .NET BCL). Quei bambini hanno bisogno di molta attenzione al n. 1. : -)

Altrimenti, si verificano problemi come questo: " Le attuali versioni di .NET Framework includono una varietà di librerie basate su GUI che non funzionerebbero correttamente in Server Core " http://www.winsupersite.com/showcase/win2008_ntk.asp

Dove non è possibile eseguire .NET su un'installazione senza GUI di Windows Server 2008 perché il framework accetta dipendenze dalle librerie della GUI ...

Un'ultima cosa. Assicurati di avere familiarità con i principi alla base della buona gestione di dipendenza / accoppiamento. Puoi trovare una bella lista qui:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

i cicli di accoppiamento e dipendenza tra unità di distribuzione sono più "fatali" perché può rendere davvero difficile distribuire il tuo programma - e talvolta può anche essere davvero difficile persino compilare il tuo programma.

hai quasi ragione, una buona progettazione di alto livello che divide il codice in pacchetti logici e solo dipendenze chiare e predefinite ti porterà per lo più, l'unica cosa che manca è la corretta separazione dei pacchetti in unità di distribuzione.