Metryki kodu — głębokość dziedziczenia (DIT)
W tym artykule przedstawiono jedną z metryk przeznaczonych specjalnie do analizy obiektowej: głębokość dziedziczenia. Głębokość dziedziczenia, nazywana również głębokością drzewa dziedziczenia (DIT), jest zdefiniowana jako "maksymalna długość węzła do korzenia drzewa". Można to zobaczyć za pomocą prostego przykładu. Utwórz nowy projekt Biblioteka klas i przed napisaniem dowolnego kodu oblicz metryki kodu, wybierając pozycję Analizuj > metryki kodu dla rozwiązania.
Ponieważ wszystkie klasy dziedziczą z System.Object
klasy , głębokość wynosi obecnie 1. Jeśli dziedziczysz z tej klasy i sprawdzasz nową klasę, możesz zobaczyć wynik:
Zwróć uwagę, że im niższy węzeł w drzewie (Class2
w tym przypadku), tym wyższa głębokość dziedziczenia. Możesz nadal tworzyć dzieci i spowodować zwiększenie głębokości tak samo, jak chcesz.
Założenia
Głębokość dziedziczenia opiera się na trzech podstawowych założeniach CK:
Im głębsza klasa w hierarchii, tym większa liczba metod, które prawdopodobnie odziedziczy, co utrudnia przewidywanie jego zachowania.
Głębsze drzewa obejmują większą złożoność projektowania, ponieważ zaangażowanych jest więcej klas i metod.
Głębsze klasy w drzewie mają większy potencjał ponownego wykorzystania odziedziczonych metod.
Założenia 1 i 2 informują, że posiadanie większej liczby głębokości jest złe. Jeśli tak się skończyło, będziesz w dobrej formie; jednak założenie 3 wskazuje, że większa liczba głębokości jest dobra dla potencjalnego ponownego użycia kodu.
Analiza
Poniżej przedstawiono sposób odczytywania metryki głębokości:
Niska liczba głębokości
Niska liczba głębokości oznacza mniejszą złożoność, ale także możliwość mniejszego ponownego użycia kodu poprzez dziedziczenie.
Duża liczba głębokości
Duża liczba głębi oznacza większy potencjał ponownego użycia kodu przez dziedziczenie, ale także większą złożoność z wyższym prawdopodobieństwem błędów w kodzie.
Analiza kodu
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:
Wewnątrz obszaru konserwacji jest reguła dziedziczenia:
Ta reguła wyświetla ostrzeżenie, gdy głębokość dziedziczenia osiągnie wartość 6 lub większą, dlatego dobrym rozwiązaniem jest zapobieganie nadmiernemu dziedziczeniu. Aby dowiedzieć się więcej na temat reguły, zobacz CA1501.
Łączenie tego wszystkiego
Wysokie wartości dit oznaczają, że potencjał błędów jest również wysoki, a niskie wartości zmniejszają potencjał błędów. Wysokie wartości dit wskazują większy potencjał ponownego użycia kodu poprzez dziedziczenie, niskie wartości sugerują mniejsze ponowne użycie kodu, choć dziedziczenie do użycia. Ze względu na brak wystarczających danych nie ma obecnie akceptowanego standardu dla wartości DIT. Nawet badania przeprowadzone niedawno nie wykazały wystarczających danych, aby określić realną liczbę, która może być używana jako liczba standardowa dla tej metryki Shatnawi. Chociaż nie ma dowodów empirycznych na jego poparcie, kilka zasobów sugeruje, że DIT około 5 lub 6 powinno być górną granicą. Na przykład zobacz https://www.devx.com/architecture-zone/45611/
.
Cytatów
CK
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
Krishnan
Subramanyam, R. & Kryszna, M. S. (2003). Empiryczna analiza metryk CK pod kątem złożoności projektowej zorientowanej na obiekt: implikacje dla wad oprogramowania (transakcje IEEE na temat inżynierii oprogramowania, vol. 29, nr 4). Pobrano 14 maja 2011 r., pierwotnie uzyskane z witryny internetowej University of Massachusetts Dartmouth https://ieeexplore.ieee.org/abstract/document/1191795
Shatnawi
Shatnawi, R. (2010). Badanie ilościowe akceptowalnych poziomów ryzyka metryk zorientowanych na obiekty w systemach typu open source (transakcje IEEE na temat inżynierii oprogramowania, vol. 36, nr 2).