Metryki kodu — sprzęganie klas

Sprzęganie klas jest nazywane także sprzężeniem między obiektami (CBO), jak pierwotnie zdefiniowano w CK94. Zasadniczo sprzężenie klas jest miarą liczby klas używanych przez pojedynczą klasę. Duża liczba jest zła, a niska liczba jest zwykle dobra w przypadku tej metryki. Sprzężenie klas wykazano, że jest dokładnym predyktorem awarii oprogramowania, a ostatnie badania wykazały, że górna wartość limitu 9 jest najbardziej wydajną wartością S2010.

Zgodnie z dokumentacją firmy Microsoft, sprzęganie (lub korelacja) klas "mierzy sprzężenie z unikatowymi klasami za pomocą parametrów, zmiennych lokalnych, typów zwracanych, wywołań metod, instancji generycznych lub szablonowych, klas bazowych, implementacji interfejsów, pól zdefiniowanych dla typów zewnętrznych oraz zdobień atrybutów. Dobry projekt oprogramowania określa, że typy i metody powinny mieć wysoką spójność i niskie sprzężenia. Wysokie sprzęganie wskazuje na projekt, który jest trudny do ponownego użycia i utrzymania ze względu na swoje liczne współzależności z innymi typami.

Koncepcje sprzężenia i spójności są wyraźnie powiązane. Aby pozostać przy temacie tej dyskusji, nie będziemy zagłębiać się w tematykę spójności, oprócz krótkiego podania definicji z KKLS2000:

"Spójność modułu została wprowadzona przez Yourdon i Constantine jako "jak ściśle związane lub powiązane wewnętrzne elementy modułu są ze sobą" YC79. Moduł ma silną spójność, jeśli reprezentuje dokładnie jedno zadanie [...], a wszystkie jego elementy przyczyniają się do tego pojedynczego zadania. Opisują one spójność jako atrybut projektu, a nie kod, oraz atrybut, który może służyć do przewidywania możliwości ponownego użycia, konserwacji i możliwości zmiany.

Przykład sprzęgania klas

Przyjrzyjmy się sprzężeniu klas w praktyce. Najpierw utwórz nową aplikację konsolową i utwórz nową klasę o nazwie Person z niektórymi właściwościami, a następnie natychmiast oblicz metryki kodu:

Zwróć uwagę, że sprzężenie klasy wynosi 0, ponieważ ta klasa nie używa żadnych innych klas. Teraz utwórz kolejną klasę o nazwie PersonStuff z metodą, która tworzy wystąpienie klasy Person i ustawia wartości jej właściwości. Ponownie oblicz metryki kodu:

Widzisz, jak wzrasta wartość sprzężenia klas? Należy również zauważyć, że bez względu na liczbę ustawionych właściwości wartość sprzężenia klasy idzie w górę o 1, a nie przez inną wartość. Sprzęganie klas mierzy każdą klasę tylko raz dla danej metryki, bez względu na to, jak często jest używana. Ponadto widać, że DoSomething() ma wartość 1, ale konstruktor PersonStuff() ma wartość 0. Obecnie w konstruktorze nie ma kodu używającego innej klasy.

Co zrobić, jeśli umieścisz kod w konstruktorze, który używał innej klasy? Oto, co otrzymujesz:

Teraz konstruktor wyraźnie ma kod, który używa innej klasy, a metryka sprzęgania klas pokazuje ten fakt. Ponownie widać, że ogólne sprzężenie klasy dla PersonStuff() wynosi 1, a DoSomething() również 1, aby pokazać, że używana jest tylko jedna klasa zewnętrzna, niezależnie od tego, ile masz kodu wewnętrznego, który z niej korzysta.

Następnie utwórz kolejną nową klasę. Nadaj tej klasie nazwę i utwórz wewnątrz niej pewne właściwości:

Teraz użyj klasy w metodzie DoSomething() w klasie PersonStuff i ponownie oblicz metryki kodu:

Jak widać, sprzężenie klasy PersonStuff wzrasta do 2, a jeśli przyjrzysz się szczegółom klasy, zobaczysz, że sprzężenie jest największe w metodzie DoSomething(), ale konstruktor nadal korzysta tylko z jednej klasy. Korzystając z tych metryk, możesz zobaczyć ogólną maksymalną liczbę dla danej klasy i zgłębić szczegóły na podstawie poszczególnych członków.

Liczba magiczna

Podobnie jak w przypadku złożoności cyklatycznej, nie ma limitu, który pasuje do wszystkich organizacji. Jednak S2010 wskazuje, że limit 9 jest optymalny:

"W związku z tym uważamy wartości progowe [...] jako najbardziej skuteczne. Te wartości progowe (dla jednego elementu) to CBO = 9[...]". (podkreślenie dodane)

Code Analysis

Analiza kodu obejmuje kategorię reguł konserwacji. Aby uzyskać więcej informacji, zobacz Reguły konserwacji. W przypadku korzystania ze starszej analizy kodu zestaw reguł rozszerzonych wytycznych dotyczących projektowania zawiera obszar możliwości konserwacji:

W obszarze utrzymywalności znajduje się reguła sprzęgania klas:

Ta reguła wyświetla ostrzeżenie, gdy sprzężenie klasy jest nadmierne. Aby uzyskać więcej informacji, zobacz CA1506: Unikanie nadmiernego sprzężenia klas.

Cytatów

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Pakiet metryk dla projektowania obiektowego (transakcje IEEE w zakresie inżynierii oprogramowania, vol. 20, nr 6). Pobrano 14 maja 2011 r. z witryny internetowej University of Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., i Saint-Denis, G. (2000). Ponowna analiza spójności klas: Badanie empiryczne systemów przemysłowych (Proceedings of the Workshop on Quantitative Approaches in Object-Oriented Software Engineering). Pobrano 20 maja 2011 r. z witryny internetowej Uniwersytetu Montrealskiego http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Kryszna, M. S. (2003). Empiryczna analiza metryk CK pod kątem złożoności projektowania obiektowo zorientowanego: implikacje dla wad oprogramowania (IEEE Transactions on Software Engineering, vol. 29, nr 4).

S2010

Shatnawi, R. (2010). Badanie ilościowe akceptowalnych poziomów ryzyka metryk obiektowo zorientowanych w systemach otwartoźródłowych (Transakcje IEEE z zakresu inżynierii oprogramowania, vol. 36, nr 2).

YC79

Edward Yourdon i Larry L. Constantine. Projekt strukturalny. Prentice Hall, Englewood Cliffs, NJ, 1979.