Na moim blogu co jakiś czas można znaleźć informacje dotyczące pisania dobrego oraz złego kodu w c#. Oprócz tego zacząłem pisać serie artykułów związanych z tą tematyką. Wiele informacji w tych artykułach można było znaleźć już wcześniej na moim blogu ale myślę, że ten cykl stanowi dobre dopełnienie i podsumowanie tego wszystkiego co piszę tutaj. Oczywiście artykuły rozszerzają tematykę, oraz zawierają więcej przykładów więc tym bardziej zachęcam do lektury.

Dziś została opublikowana pierwsza część:

http://msdn.microsoft.com/pl-pl/library/dobre-i-zle-praktyki-w-c-sharp–czesc-1.aspx

Dziś czas na kolejną metrykę badania kodu  – TypeRank.

Wartość metryki jest liczona za pomocą algorytmu Google Page Rank, który jest wykorzystywany przez wyszukiwarki do indeksowania stron. W świecie wyszukiwarek internetowych im większa wartość tym strona znajdzie się wyżej podczas prezentowania wyników. Algorytm bada powiązania między stronami internetowymi. Strona dostaje wyższą ocenę, gdy więcej innych stron wskazuje na nią. Stwierdzono, że skoro do danej strony odwołuje się więcej innych witryn to prawdopodobnie zawiera ona treść o lepszej jakości.

Przykład:

W sieci istnieją tylko 4 strony internetowe A, B, C, D. Na początku każda posiada więc wartość PageRank równą 0.25 ponieważ uniwersum składa się z 4 elementów a przyjmuje się skale od 0-1. Strony B, C, D zawierają odnośniki do A. Zatem PageRank witryny A wynosi:

Jeśli dodatkowo założy się, że B zawiera odnośnik również do C, z kolei D do wszystkich innych (A,B,C), wtedy wartość rankingu jest dzielona przez liczbę odnośników:

Innymi słowy strona A jest wyżej w rankingu jeśli strona B zawiera wyłącznie odnośnik do A, a nie jednocześnie do np. A, B, C.

Empirycznie stwierdzono, że PageRank wyliczany na podstawie powyższego wzoru generuje zbyt duże wartości. Z tego względu do wzoru dodano tzw. współczynnik tłumienia, który najczęściej przyjmuje wartość 0.85. Kompletny wzór zatem wygląda następująco:

gdzie:

PR – PageRank danej strony,

d – współczynnik tłumienia. Wartość między 0 i 5, najczęściej 0.85,

L – liczba odsyłaczy na danej stronie internetowej,

N – całkowita liczba stron internetowych.

TypeRank działa w identyczny sposób. Jedyną różnicą jest liczenie metryki na podstawie typów (klas, struktur itp.) a nie stron internetowych. W przeciwieństwie do PageRank, wartości duże TypeRank są niepożądane ponieważ oznaczają, że wiele klas jest zależnych od badanego typu. Podczas modyfikacji typów z dużą wartością TypeRank należy uważnie przetestować ponownie system – są one szczególnie wrażliwe na zmiany. Jeśli to możliwe należy rozdzielać typy z wysoką wartością metryki lub przynajmniej unikać zaawansowanej logiki w takich typach.

Dziś trochę o matematycznej walidacji kodu czyli o metrykach.  LCOM (lack  cohesion of methods) umożliwia obliczenie jak bardzo nasze metody są spójne. Do obliczania tej wartości istnieją gotowe narzędzia takie jak nDepend, ale aby w pełni zrozumieć znaczenie metryki obliczymy sami jej wartość dla prostej klasy.

Powinno dążyć się do jak największej spójności a tym samym do jak najniższej wartości LCOM. Przed wyjaśnieniem czym jest metryka LCOM wprowadźmy następujące pojęcia:

M – zbiór metod danej klasy (M₁,M₂…M_n),

I_i – zbiór zmiennych składowych klasy wykorzystywanych przez metodę M_i.

Wartość LCOM jest równa:

Innymi słowy, LCOM ma na celu wyeliminowanie zmiennych składowych, które wykorzystywane są tylko w jednej metodzie. Zmienne składowane, które wywoływane są wyłącznie w jednej metodzie powinny być przeniesione do tej metody i zadeklarowane w jej ciele.

Pełna definicja LCOM wygląda następująco:

Rozważny poniższy fragment kodu:

public class ClassA
{
    private int m_Var1 = 0;
    private int m_Var2 = 0;
    private int m_Var3 = 0;
    private int m_Var4 = 0;
    
    void Method1()    
    {    
        m_Var1 = 0;    
        m_Var2 = 1;     
    }    
    void Method2()    
    {    
        m_Var1 = 0;    
        m_Var3 = 4;    
    }    
    void Method3()    
    {    
        m_Var4 = 5;    
    }
}

Na podstawie kodu można wyznaczyć:

I₁ = {m_Var1,m_Var2}

I₂ = {m_Var1,m_Var3}

I₃ = {m_Var4}

Następnie należy wyznaczyć wszystkie kombinacje metod których jest:

Występują dwa zbiory puste zatem wartość metryki LCOM wynosi dwa.

Na podstawie metryki można stwierdzić, że klasa została źle zaprojektowana. Powinno dążyć do zerowej wartości LCOM poprzez przenoszenie składowanych wykorzystywanych tylko w jednej metodzie do ciała tej metody. Pola składowe powinny być wykorzystywane przez jak największą liczbę metod a najlepiej wszystkie. Powinniśmy unikać sytuacji gdzie jedna metoda korzysta z pól całkowicie innych niż druga metoda tej samej klasy!

Metrykę LCOM można również wyrazić za pomocą:

gdzie:

M – liczba metod,

F – liczba pól,

MF – liczba pól wykorzystywanych przez daną metodę. Wyrażenie sum(MF) określa sumę wykorzystywanych pól przez każdą z metod.

Metryka wyliczana na podstawie wzoru przyjmuje wartości między 0 a 1. Wartość 0 oznacza maksymalną spójność, z kolei 1 brak spójności. W praktyce kryterium LCOM ciężko spełnić i dlatego wprowadzono pewną modyfikację o szerszym zasięgu:

LCOM HS przyjmuje wartości od 0 do 2. W przypadku wykrycia klasy z LCOM HS > 1.0 należy koniecznie klasę zrefaktoryzować.

W ostatnim poście opisałem atrybut ThreadStatic pozwalający na korzystanie ze statycznych pól w sposób niezależny w każdym wątku. Dziś pora na analogiczną klasę, wprowadzoną w .NET 4.0 – ThreadLocal. Zacznijmy od przykładu:

class ClassA
{    
    private ThreadLocal<int> _value=new ThreadLocal<int>();

    public void RunAsync(object value)
    {
        var thread = new Thread(Run);
        thread.Start(value);
        thread.Join();
    }
    private void Run(object value)
    {
        if(value!=null)
            _value.Value = (int)value;

        Console.WriteLine(_value);
    }
}

Następnie wywołujemy RunAsync:

var classA = new ClassA();
classA.RunAsync(2);
classA.RunAsync(null);      

Bez użycia ThreadLocal, otrzymalibyśmy na ekranie 2,2. Powyższy przykład używa jednak ThreadLocal więc pola są niezależne – na ekranie wyświetli się 2,0.

Należy jednak uważać na wątki z puli. Jak wiemy, wątek z puli po zakończeniu działania jest zwracany z powrotem do puli a nie niszczony. Z tego względu może się okazać, że dwa wątki odpalone jeden po drugim będą współdzielić taką samą wartość- jeden się zakończy i potem ten sam będzie uruchomiony.

ThreadLocal umożliwia jeszcze Lazy Loading. Jeśli wartość nie zostanie jawnie ustawiona wtedy można skorzystać z lazy loading aby ją określić np.:

class ClassA
{
    private ThreadLocal<int> _value = new ThreadLocal<int>(() => 5);

    public void RunAsync(object value)
    {
        var thread = new Thread(Run);
        thread.Start(value);
        thread.Join();
    }
    private void Run(object value)
    {
        if(value!=null)
            _value.Value = (int)value;

        Console.WriteLine(_value);
    }
}

W przypadku gdy _value.Value nie zostało ustawione, wtedy próba wywołania _value.Value zwróci zawsze 5. Stanowi to zaletę w porównaniu do ThreadStatic gdzie nie mogliśmy określić wartości domyślnej. Druga oczywista zaleta to fakt, że ThreadStatic dotyczył wyłącznie statycznych pól.

W C# istnieje dość mało popularny atrybut ThreadStaticAttribute. Do czego on służy? Zacznijmy od przykładu:

internal class Program
{
    [ThreadStatic] 
    private static int _value;

    private static void Main(string[] args)
    {
        Thread thread1 = new Thread(PrintValue);
        Thread thread2 = new Thread(PrintValue);
        thread1.Start(4);
        thread1.Join();
        thread2.Start();
    }
    static private void PrintValue(object args)
    {
        if(args!=null)
            _value = (int) args;
        Console.WriteLine(_value);
    }
}

Co się pojawi na wyjściu? Bez atrybutu ThreadStatic byłoby to (4,4). Atrybut jednak mówi, że pole statyczne będzie unikalne dla każdego wątku. Czyli Thread1 będzie miał własną kopię oraz tak samo Thread2. Statyczne pola oznaczone tym atrybutem nie są współdzielone przez wątki. W powyższym przykładzie, pierwszy wątek ustawi wartość na 4 a drugi z kolei będzie miał swoją kopie i wyświetli wartość domyślną czyli 0.

Należy zaznaczyć, że pole ThreadStatic powoduje pewien overhead i czytanie takiej wartości jest dużo wolniejsze (nawet kilkadziesiąt razy). Kiedy używać tego? Szczerze mówiąc rzadko, tak samo jak rzadko należy używać klas statycznych. Jeśli mamy jednak pole statyczne, które jest modyfikowane przez różne wątki, wtedy aby uniknąć kosztownych blokad, warto oznaczyć je ThreadStatic.

Ważna uwaga: nie należy inicjalizować pól statycznych ThreadStatic wartością początkową. Dlaczego? Pomyślmy kiedy wartość początkowa jest wstawiana. Na etapie kompilacji? Nie… Ma to miejsce w momencie pierwszego dostępu do pola a konkretnie kiedy zostanie wywołany konstruktor statyczny. Niestety wartość domyślna będzie widziana tylko dla pierwszego wątku, który chciał uzyskać dostęp:

internal class Program
{
    [ThreadStatic] private static int _value = 54;

    private static void Main(string[] args)
    {
        Console.WriteLine(_value);
        Thread thread1 = new Thread(PrintValue);
        Thread thread2 = new Thread(PrintValue);
        thread1.Start();
        thread1.Join();
        thread2.Start();
    }
    static private void PrintValue(object args)
    {
        Console.WriteLine(_value);
    }
}

Powyższy kod wyświetli wartości 54,0,0. Główny wątek wywoła inicjalizację wartością 54 a następne niestety już tego nie uczynią. Jedynie możemy mieć pewność, że wartość w nowych wątkach będzie wartością domyślną  ( dla liczb zero a dla obiektów NULL).