Jak sprawdzić, czy oprogramowanie jest silnie sprzężone?

Znam termin „wysoce sprzężony”, ale jestem ciekawy, czy istnieją znaki (zapach kodu), które mogą wskazywać, że kod jest silnie sprzężony. Obecnie pracuję z Javą EE, ale może to dotyczyć dowolnego języka.

Edytować:

Jeśli ktoś jest zainteresowany, ten artykuł wydaje się pomocny: w pogoni za jakością kodu: strzeż się ścisłej pary! (IBM)

Moim zdaniem numerem jeden źle połączonych modułów są zależności dwustronne. Na przykład, moduł 1 wywołuje jakąś funkcję w module 2, a moduł 2 wywołuje jakąś funkcję w module 1.

Większość interfejsów powinna być jednokierunkowa. Jeśli wywoływany moduł musi przekazać pewne informacje do modułu wywołującego, który nie jest zwracany jako część wywołania, powinien użyć mechanizmu przekazywania wiadomości lub mechanizmu wyzwalającego zdarzenie, takiego jak kolejka komunikatów. Idealnie, interfejs do przekazywania komunikatów powinien być przekazywany podczas procesu inicjalizacji lub rejestracji. To całkowicie abstrahuje interfejs w taki sposób, że moduł tak naprawdę nie dba o to, dla kogo jest to zdarzenie ... dlatego jest oddzielony.

Innym wskazaniem jest to, że jeden moduł stale wywołuje inny moduł dla określonego zestawu danych. Powinno to zadać ci pytanie, kto powinien być właścicielem zestawu danych. Dlaczego ten moduł zawsze musi widzieć dane należące do innego modułu?

Trzecim narzędziem, które można powiedzieć, jest zadać sobie pytanie: „Czy mogę wyciągnąć ten moduł i wymienić go bez konieczności zmiany innych modułów?

To nie jest wyczerpująca lista, ale są to trzy najważniejsze rzeczy, o które pytam siebie przy projektowaniu oprogramowania.

Stare powiedzonko brzmi: „Możesz dotykać znajomych i dotykać swoich szeregowych. Ale nie możesz dotykać prywatnych szeregowych”. To połączenie w skrócie.

Oznaki wysoce sprzężonego kodu obejmują bardzo duże interfejsy, które informują ludzi o prywatnych szczegółach implementacji oraz obiekty, które wydają się „dużo o sobie wiedzieć”. Istnieją narzędzia do automatycznej analizy, które oznaczą kod, który wygląda ściśle dla Ciebie. Zobacz http://www.scitools.com/features/metricsintro.php dla losowego. (Nie mam pojęcia, jak to działa. Po prostu okazało się dość wysokie w wyszukiwarce Google).

Spróbuj napisać kilka testów jednostkowych dla klas. Jeśli nie możesz łatwo przetestować klas bez potrzeby tworzenia / drwiącego obciążenia klas wsparcia lub db / ui, cokolwiek to jest pewny znak złego sprzężenia / zależności.

Jest to również jedno z najlepszych lekarstw, ale musisz to zrobić podczas kodowania (jak TDD), aby zachować uczciwość.

Oczywistym znakiem dla mnie jest to, że wszystko jest publiczne.

Drugim znakiem są naruszenia prawa Demetera - nadmierne to odniesienia do SomeObj.SomeProp.SomeProp na niefachowych interfejsach.

Kiedyś widziałem to, co nazwałem „klasą marionetek”, która zbudowała formularz wprowadzania danych w locie. Miał kilka innych naruszeń przy projektowaniu oprogramowania, więc nadmierne sprzężenie było najmniejszym problemem.

Podczas pobierania danych z utworzonych przez siebie formantów wyglądało to tak:

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

/* several other controls */

Ripple Effect .

Każda zmiana ma efekt falowania przez wszystkie ściśle ze sobą połączone moduły.

Naruszono zasadę „otwarte-zamknięte”, ponieważ nie jest ona odpowiednio zamknięta i zmiana wycieka.

Sprawdź liczbę # include / import itp. Między klasami / pakietami / dlls / jar / whatnots. Spróbuj narysować wykres tego, mentalnie, ręcznie lub za pomocą jakiegoś narzędzia.

• Jeśli ten wykres jest gęsty (tzn. Wiele połączeń w każdym miejscu), to twój system jest monolityczny i silnie sprzężony.
• Jeśli jest wyraźnie podzielony na warstwy, bez połączeń między warstwami / przejściami, a połączeń jest niewiele, masz system modułowy i oddzielony.

Jeśli nie możesz wdrożyć funkcji, ponieważ nie masz pojęcia, dokąd idzie konkretna odpowiedzialność, oznacza to, że twój system jest zbyt ściśle powiązany.

W przypadku bardzo podstawowych znaków można rozważyć sprawdzenie liczby interfejsów i ich użycia między klasami różnych pakietów (zwykle luźno powiązany kod zawiera interfejsy i istnieje ograniczona bezpośrednia interakcja między poszczególnymi klasami w różnych pakietach), liczba nazw klas, które mogą być używane do grupowania innych klas (w luźno sprzężonym kodzie rzeczywista interakcja między klasami, które mają różne zadania, jest realizowana przez funkcje interfejsu lub funkcje bardziej powszechnych / grupujących klas) lub numeruje zmienne publiczne w klasach (luźniej znacznie mniej / nawet żadnych zmiennych publicznych ).

Prawie wszystkie zapachy kodu wskazują w pewien sposób na zbędne sprzężenie. Przypuszczam, że zapach, który najbardziej wskazywałby na sprzężenie, może być „Niewłaściwa intymność” (mój ulubiony zapach).

Podejrzewam, że inną rozsądną metodą pomiaru byłoby policzenie linii na diagramie UML. Jeśli masz N obiektów i N ^ N (lub więcej) linii między nimi, twój kod jest prawie maksymalnie sprzężony. N wierszy prawdopodobnie byłyby tak minimalne, jak to tylko możliwe.