Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
V tomto článku se dozvíte o jedné z metrik navržených speciálně pro objektově orientované analýzy: Hloubka dědičnosti. Hloubka dědičnosti, označovaná také jako hloubka stromu dědičnosti (DIT), je definována jako "maximální délka z uzlu do kořene stromu" CK. Můžete to vidět pomocí jednoduchého příkladu. Vytvořte nový projekt knihovny tříd a před napsáním libovolného kódu vypočítejte metriky kódu výběrem možnosti Analyzovat > výpočet metrik kódu pro řešení.
Vzhledem k tomu, že všechny třídy dědí z System.Object, hloubka je aktuálně 1. Pokud dědíte z této třídy a prozkoumáte novou třídu, uvidíte výsledek:
Všimněte si, že čím nižší je uzel ve stromu (Class2 v tomto případě), tím větší je hloubka dědičnosti. Můžete i nadále vytvářet děti a způsobit, že se hloubka zvýší tak, jak chcete.
Předpoklady
Hloubka dědičnosti je predikována na třech základních předpokladech CK:
Čím hlouběji třída v hierarchii, tím větší je počet metod, které bude pravděpodobně dědit, což znesnadňuje predikci jeho chování.
Hlubší stromy zahrnují větší složitost návrhu, protože jsou zapojeny více tříd a metod.
Hlubší třídy ve stromu mají větší potenciál pro opakované použití zděděných metod.
Předpoklady 1 a 2 říkají, že větší číslo pro hloubku je špatné. Pokud by to tam skončilo, byli byste na tom dobře; předpoklad 3 však naznačuje, že vyšší číslo pro hloubku je dobré pro potenciální opětovné použití kódu.
Analysis
Tady je postup, jak si přečtete metriku hloubky:
Nízké číslo pro hloubku
Nízké číslo pro hloubku znamená menší složitost, ale také možnost menšího opakovaného použití kódu prostřednictvím dědičnosti.
Vysoké číslo pro hloubku
Vysoké číslo pro hloubku znamená větší potenciál opětovného použití kódu prostřednictvím dědičnosti, ale také vyšší složitost s vyšší pravděpodobností chyb v kódu.
Code Analysis
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:
V rámci oblasti udržovatelnosti platí pravidlo pro dědičnost:
Toto pravidlo vydá upozornění, když hloubka dědičnosti dosáhne 6 nebo vyšší, takže je dobrým pravidlem, které pomáhá zabránit nadměrné dědičnosti. Další informace o pravidle najdete v tématu CA1501.
Dát vše dohromady
Vysoké hodnoty pro DIT znamenají, že potenciál chyb je také vysoký, nízké hodnoty snižují potenciál chyb. Vysoké hodnoty metriky DIT označují větší potenciál opětovného použití kódu prostřednictvím dědičnosti, zatímco nízké hodnoty naznačují méně opětovného využití kódu tímto způsobem. Vzhledem k nedostatku dostatečných dat neexistuje aktuálně přijatý standard pro hodnoty DIT. I studie provedené v nedávné době nenašly dostatečná data k určení přijatelného čísla, které by bylo možné použít jako standardní číslo pro tuto metriku Shatnawi. Ačkoli neexistují žádné empirické důkazy, které by ji mohly podporovat, několik zdrojů naznačuje, že DIT kolem 5 nebo 6 by měl být horní limit. Podívejte se například na https://www.devx.com/architecture-zone/45611/.
Citace
CK
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
Krishnan
Subramanyam, R. & Krishnan, M. S. (2003). Empirická analýza metrik CK pro složitost návrhu Object-Oriented: Důsledky chyb softwaru (IEEE Transactions on Software Engineering, Vol. 29, No. 4). Citováno 14. května 2011, původně získáno z University of Massachusetts Dartmouth webové stránky https://ieeexplore.ieee.org/abstract/document/1191795
Shatnawi
Shatnawi, R. (2010). Kvantitativní šetření úrovní přijatelných rizik objektově orientovaných metrik v systémech s otevřeným zdrojovým kódem (IEEE Transactions on Software Engineering, Vol. 36, No. 2).