Warstwa prezentacji odpowiedzialna jest za komunikację z użytkownikiem. W dzisiejszych czasach interfejsy graficzne są na tyle rozbudowane, że poprawne zaprojektowanie warstwy prezentacji stanowi poważne wyzwanie. W małych projektach często ta warstwa stanowi najbardziej złożoną część całej architektury.

Bez wykorzystania stosownych wzorców projektowych po pewnym czasie pisania aplikacji okaże się, że jakakolwiek zmiana interfejsu wiąże się ze skomplikowaną refaktoryzacją kodu.

Jedną z podstawowych cech poprawnie zaprojektowanej warstwy prezentacji jest niezależność od sposobu wyświetlania. Doskonałym przykładem jest np. blog WordPress. Za pomocą kilku kliknięć można zmienić wygląd (skórkę) strony. Sposób wyświetlania jest wyraźnie oddzielony od logiki oraz akcji użytkownika. Innymi słowy interfejs graficzny powinien pozostać nieświadomy danych, które wyświetla. Drugim przykładem obok blog’a jest wyświetlanie danych (np. zamówień) w ASP .NET – programista może użyć zarówno kontrolki DataGrid jak Repeater. Podsumowując warstwa prezentacji musi być odporna na zmianę widoku – model musi pozostać niezależny (np. powinno wykorzystywać sie IEnumarable<Order> zamiast specyficznej kolekcji dla danego API graficznego).

Często podawaną ważną cechą warstwy prezentacji jest niezależność od technologii interfejsu graficznego (WPF, Silverlight itp.). W praktyce jednak nie zawsze spełniana jest ta zasada. W idealnym świecie architektura tej warstwy powinna pozwalać na swobodną zmianę technologii UI. W rzeczywistości zaprojektowanie tak elastycznej warstwy jest bardzo trudnym i czasochłonnym zadaniem i często rezygnuje się z tego. Oczywiście wykorzystując np. Model-View-ViewModel znacznie łatwiej będzie przejść w przyszłości na inną technologie niż wykorzystując klasyczny autonomiczny widok.

Ważnym elementem wyróżniającym dobrze zaprojektowaną warstwę jest wsparcie dla testów (np. jednostkowych). W widoku autonomicznym zautomatyzowane testy są praktycznie niemożliwe – sprowadzałyby się do symulowania kliknięć użytkownika. Potrzebujemy API, które pozwoli nam symulować konkretną akcję użytkownika z poziomu kodu – np. kliknięcie w dany przycisk. Kluczem do tego jest stworzenie abstrakcji między widokiem a logiką prezentacji – konkretnie interfejsu zawierającego metody typu “SelectOrder”, “ShowDetails” itp.

Dobrą cechą jest również całkowita niezależność od warstwy biznesowej. Uzyskuje się to poprzez wprowadzenie wspomnianych już w poprzednich postach obiektów DTO. W praktyce jednak tworzenie DTO jest bardzo czasochłonne i nie zawsze opłacalne.

W przyszłych postach przedstawię kilka podstawowych wzorców projektowych – Model-View-Controller, Model-View-Presenter, Model-View-ViewModel oraz Model2. Planuje również opisanie dwóch frameworków wspomagających wykorzystanie tych wzorców zarówno w aplikacjach web (oczywiście będzie to ASP .NET MVC) jak i desktop.

Zaczynamy standardowo od czystej definicji zasady:

1. Kod z warstw z wyższego poziomu nie powinien zależeć od kodu z niższych warstw. Obie warstwy za to powinny być zależne od abstrakcji.
2. Abstrakcje nie powinny zależeć od szczegółów (konkretnej implementacji). Z kolei szczegóły (implementacja) powinna zależeć od abstrakcji.

Najlepiej rozważmy to na przykładzie aplikacji enterprise. Kodem z niższej warstwy może być np. DAL (warstwa dostępu do danych) a  z wyższej – warstwa biznesowa. Według zasady, warstwa biznesowa nie może zawierać bezpośrednio referencji do DAL:

class BusinessLayer
{
    private DataContext m_DataContext=new DataContext();
    
    public void SubmitOrder()
    {
        m_DataContext.Orders.Add( new Order());
    }
}

Wyobraźmy sobie, że pewnego dnia zmienia się dostawca warstwy dostępowej (np. z nHibernate na EntityFramework). Wtedy warstwa wyższego poziomu (biznesowa) musi również zostać zaktualizowana. Ponadto ze względu na zmianę kodu ponownie należy przetestować klasę. Zgodnie z zasadą kod powinien być zależny wyłącznie od abstrakcji a nie szczegółów:

class BusinessLayer
{
    private IDataContext m_DataContext=null;

    public BusinessLayer(IDataContext context)
    {
        m_DataContext=context;
    }
    public void SubmitOrder()
    {
        m_DataContext.Orders.Add( new Order());
    }
}

Ewentualna zmiana DAL wymaga tylko wstrzyknięcia poprzez konstruktor konkretnej implementacji. Innym rozwiązaniem jest skorzystanie z wzorca fabryka, plugin lub lokalizator.

Zasada mówi żeby tworzone przez programistę interfejsy były odpowiedzialne za jak najmniejsza funkcjonalność. Użytkownik chcąc zaimplementować taki interfejs nie powinien pisać metod, których nie potrzebuje. Jeśli znajdują się w nim niepotrzebne metody to wtedy nazywamy go interfejsem “fat” lub “polluted”.

Najlepiej rozważyć to na klasycznym przykładzie (z oodesign):

interface IWorker 
{    
    void Work();
    void Eat();
}
class Worker: IWorker
{    
    public void Work() 
    {        
    }    
    public void Eat() 
    {
    }
}
class Robot: IWorker
{    
    public void Work()
    {    
    }    
    public void Eat()
    {        
      throw new NotImplementedException();
    }
}

Mamy interfejs IWorker z dwoma metodami: Work oraz Eat. Następnie definiujemy dwie konkretne implementacje pracownika. Pierwszy reprezentuje zwykłego pracownika, który musi jeść i pracować (implementacje obydwu metod). Z kolei druga klasa reprezentuje robota, który może tylko pracować – bez jedzenia :). Przykład prezentuje łamanie zasady ISP ponieważ implementacja wymaga dostarczenia dwóch metod a przecież istnieją klasy (Robot) w których wystarczy zaimplementować wyłącznie jedną (Work). Programista nie powinien być zmuszany do pisania pustych metod (dummy methods) tylko po to aby sprostać wymaganiom interfejsu. Prawidłowe rozwiązanie polega na rozłupaniu interfejsu na dwie części:

interface IWorkable 
{    
    public void Work();
}
interface IFeedable
{
    public void Eat();
}
class Worker: IWorkable, IFeedable
{
    public void Work()
    {        
    }        
    public void Eat() 
    {        
    }
}
class Robot: IWorkable
{    
    public void Work() 
    {    
    }
}

Na początek podam czystą definicje z wiki:

“Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.”

Początkowo za wiele ta tajemnicza definicja nie mówiła mi. Innymi słowy, klasa dziedzicząca powinna  rozszerzać możliwości klasy bazowej a nie całkowicie zmieniać jej funkcjonalność. Sposób korzystania z klasy potomnej powinien być analogiczny do wywoływania klasy bazowej. Przyjrzyjmy się klasycznemu przykładowi łamania zasady Liskov (źródło: http://www.oodesign.com):

class Rectangle
{
    protected int m_Width;    
    protected int m_Height;
    
    public void SetWidth(int width)
    {    
        m_Width = width;    
    }
    public void SetHeight(int height)
    {    
        m_Height = height;    
    }    
    public int GetWidth()
    {        
        return m_Width;    
    }
    public int GetHeight()
    {        
        return m_Height;
    }    
    public int GetArea()
    {    
        return m_Width * m_Height;    
    }    
}
class Square: Rectangle 
{    
    public void SetWidth(int width)
    {    
        m_Width = width;        
        m_Height = width;    
    }
    public void SetHeight(int height)
    {    
        m_Width = height;        
        m_Height = height;    
    }
}

Następnie obliczmy pole:

Rectangle r = new Square();
r.SetWidth(5);    
r.SetHeight(10);        
int area = r.GetArea();

Użytkownik spodziewa się wyniku 50 a otrzymuje 100. Jest to przykład łamania zasady Liskov – sekwencja kodu przynosi różne efekty w zależności od tego czy posiadamy referencję na klasę bazową czy potomną. Klasa potomna nie powinna zmieniać zachowania klasy.

Zasada O\C mówi, że oprogramowanie powinno być otwarte na rozszerzenia a zamknięte na modyfikacje. Innymi słowy programista powinien być w stanie uzyskać zamierzony efekt poprzez rozszerzenie klasy czy przeładowanie metody a nie zmianę już istniejącego kodu. Zasada jest szczególnie istotna w przypadku kodu produkcyjnego, w którym wszelkie możliwości modyfikacji kodu są ograniczone. Zasada pozwala budować modularne systemy. Użycie ENUM moim zdaniem jest złamaniem Open\Closed principle. Wykorzystując w kodzie typy enumeryczne oraz instrukcje sterujące zamykamy w pewnym sensie możliwości rozszerzenia systemu. Wprowadzenie nowych opcji wymaga bowiem modyfikacji typu enumerycznego. Nie oznacza to oczywiście, że zawsze należy unikać ENUM. Często jest to najwygodniejsze rozwiązanie oraz liczba podtypów jest z góry znana (np. formatowanie tekstu – mamy zbiór zamknięty możliwych opcji).

Pod adresem http://www.oodesign.com/open-close-principle.html znajduje się krótki przykładzik obrazujący złamanie zasady.

W Inżynierii oprogramowania SOLID oznacza zestaw podstawowych zasad projektowania oprogramowania. Każda literka w wyrazie jest skrótem do jakieś zasady. ‘S’ oznacza Single Responsibility Principal. Podejrzewam, że większość osób doskonale zna już tą zasadę. Aby jednak zachować pewien porządek na blogu będę tłumaczył nawet te oczywiste reguły:).

W skrócie zasada mówi, że każdy obiekt (klasa) powinien być odpowiedzialny za jak najmniejszy fragment logiki. Niedopuszczalne jest aby klasa wykonywała dwie niezależne od siebie funkcje. Robert Martin (autor SRP) definiuje odpowiedzialność jako “reason to change”. Innymi słowy, każda klasa powinna mieć wyłącznie jeden powód do zmiany. Jeśli brzmi to zbyt abstrakcyjnie to rozważmy akademicki przykład klasy wykonującej jakieś obliczenia (choćby mnożenie macierzy – obojętnie). Jeśli taka klasa oprócz wykonywania obliczeń odpowiedzialna jest również za wyświetlenie wyników z pewnością nie spełnia zasady SRP.

Ostatnie pytanie brzmi: jak weryfikować zgodność kodu z SRP? Przede wszystkim należy to do obowiązków programisty. Żadne narzędzia w pełni nie zagwarantują poprawności. Nie mniej jednak, można wspomóc się kilkoma metrykami kodu. Za pomocą narzędzia nDepend można wyliczyć metrykę efferent coupling, która określa jak wiele zewnętrznych klas wywołuje badany fragment kodu. Gdy CE jest zbyt wysokie istnieje prawdopodobieństwo, że klasa nie spełnia SRP. Przydatne również są wszystkie metryki mierzące liczbę powiązań (np. ABC).

Na koniec należy dodać, że nie wszystkie klasy w programie muszą spełniać SRP. Warstwa usług czy wszelkie implementacje wzorca fasady z definicji przecież nie są zgodne z SRP – mają za zadanie skupiać szeroką funkcjonalność w jednym miejscu.