Metriky kódu – párování tříd
Spojka třídy také přechází podle názvu Párování mezi objekty (CBO), jak je původně definováno CK94. V podstatě je párování tříd mírou, kolik tříd používá jedna třída. Vysoké číslo je špatné a nízké číslo je obvykle dobré s touto metrikou. U párování tříd se ukázalo, že přesný prediktor selhání softwaru a nedávné studie ukázaly, že nejvyšší limitní hodnota 9 je nejúčinnější S2010.
Podle dokumentace Microsoftu měří párování tříd na jedinečné třídy prostřednictvím parametrů, místních proměnných, návratových typů, volání metod, obecných instancí nebo vytváření instancí šablon, základních tříd, implementací rozhraní, polí definovaných na externích typech a dekoraci atributů. Dobrý návrh softwaru určuje, že typy a metody by měly mít vysokou soudržnost a nízkou spojku. Vysoká spojka značí návrh, který je obtížné opakovaně používat a udržovat kvůli mnoha vzájemným závislostem na jiných typech."
Koncepty propojení a soudržnosti jsou jasně spojeny. Abychom si tuto diskuzi o tématu udrželi, nebudeme se zabývat podrobnostmi o soudržnosti, než abychom poskytli stručnou definici z KKLS2000:
"Soudržnost modulů zavedla Vašedon a Constantine jako "jak úzce vázané nebo související vnitřní prvky modulu jsou navzájem" YC79. Modul má silnou soudržnost, pokud představuje přesně jeden úkol [...], a všechny jeho prvky přispívají k tomuto jedinému úkolu. Popisují soudržnost jako atribut návrhu, nikoli kód, a atribut, který lze použít k předpovídání opakované použitelnosti, udržovatelnosti a měnitelnosti."
Příklad párování tříd
Pojďme se podívat na párování tříd v akci. Nejprve vytvořte novou konzolovou aplikaci a vytvořte novou třídu s názvem Person s některými vlastnostmi a pak okamžitě vypočítejte metriky kódu:
Všimněte si, že párování tříd je 0, protože tato třída nepoužívá žádné jiné třídy. Nyní vytvořte další třídu s názvem PersonStuff s metodou, která vytvoří instanci Person a nastaví hodnoty vlastnosti. Znovu vypočítejte metriky kódu:
Vidíte, jak se hodnota párování tříd zhoršuje? Všimněte si také, že bez ohledu na to, kolik vlastností nastavíte, hodnota párování třídy se pouze zpojí o 1, a ne o jinou hodnotu. Párování tříd měří každou třídu pouze jednou pro tuto metriku bez ohledu na to, kolik se používá. Kromě toho můžete vidět, že DoSomething()
má 1, ale konstruktor, PersonStuff()
má hodnotu 0 pro jeho hodnotu? V současné době není v konstruktoru žádný kód, který používá jinou třídu.
Co když vložíte kód do konstruktoru, který používal jinou třídu? Tady je to, co získáte:
Konstruktor teď jasně obsahuje kód, který používá jinou třídu a metrika párování tříd ukazuje tento fakt. Opět si můžete prohlédnout celkovou vazbu tříd pro PersonStuff()
1 a DoSomething()
také 1, abyste ukázali, že se používá pouze jedna externí třída bez ohledu na to, kolik interního kódu ho používáte.
Dále vytvořte další novou třídu. Pojmenujte tuto třídu a vytvořte v ní některé vlastnosti:
Teď spotřebujte třídu v naší metodě v rámci DoSomething()
PersonStuff
třídy a znovu vypočítejte metriky kódu:
Jak vidíte, spojka tříd pro třídu PersonStuff je až 2, a pokud přejdete do třídy, uvidíte, že DoSomething()
metoda má v něm nejvíce párování, ale konstruktor stále spotřebovává pouze 1 třídu. Pomocí těchto metrik můžete zobrazit celkové maximální číslo pro danou třídu a přejít k podrobnostem o jednotlivých členech.
Kouzelné číslo
Stejně jako u cyklomatické složitosti neexistuje žádné omezení, které by vyhovovalo všem organizacím. S2010 ale znamená, že limit 9 je optimální:
"Proto považujeme prahové hodnoty [...] jako nejúčinnější. Tyto prahové hodnoty (pro jeden člen) jsou CBO = 9[...]." (zvýraznění přidáno)
analýza kódu
Analýza kódu zahrnuje kategorii pravidel udržovatelnosti. Další informace naleznete v tématu Pravidla udržovatelnosti. Pokud používáte starší verzi analýzy kódu, sada pravidel Extended Design Guideline obsahuje oblast udržovatelnosti:
Uvnitř oblasti udržovatelnosti je pravidlo pro párování tříd:
Toto pravidlo vydá upozornění při nadměrném párování tříd. Další informace najdete v tématu CA1506: Vyhněte se nadměrnému párování tříd.
Citace
CK94
Chidamber, S. R. & Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, No. 6). Citováno z 14. května 2011 z webu University of Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf
KKLS2000
Kabaili, H., Keller, R., Lustman, F., a Saint-Denis, G. (2000). Třída soudržnosti se revisited: Empirická studie o průmyslových systémech (Sborník workshopu o kvantitativních přístupech v objektově orientovaném softwarovém inženýrství). Citováno z 20. května 2011, z Université de Montréal webové stránky http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf
SK2003
Subramanyam, R. & Krishnan, M. S. (2003). Empirická analýza metrik CK pro složitost objektově orientovaného návrhu: Důsledky pro softwarové vady (transakce IEEE při softwarovém inženýrství, vol. 29, č. 4).
S2010
Shatnawi, R. (2010). Kvantitativní šetření přijatelných úrovní rizik objektově orientovaných metrik v opensourcových systémech (IEEE Transactions on Software Engineering, Vol. 36, No. 2).
YC79
Edward Yourdon a Larry L. Constantine. Strukturovaný návrh Prentice Hall, Englewood Cliffs, N.J., 1979.