Obserwator i obserwowany

Wzorzec projektowy obserwatora i obserwowanego nie jest zbyt często wykorzystywany w aplikacjach .Net. Wiąże to się z faktem iż C# wspiera zdarzenia (events),  które w większości przypadków są rozwiązaniem wystarczająco dobrym. Microsoft zauważył jednak, że istnieją bardziej rozbudowane scenariusze, takie jak nasze, w których nie zdają one egzaminu, dlatego dodał interfejsy IObserver<T> i IObservable<T>. Różnią się one od klasycznej definicji książkowej tego wzorca kilkoma szczegółami:

• Są generyczne (parametryzowane typem) 
• IObservable zawiera tylko metodę Subscribe akceptującą jako parametr obserwatora i zwracającą obiekt implementujący IDisposable, zamiast wywołania metody Unsubscribe należy wywołać metodę Dispose z wyniku metody Register
• Obserwator posiada 3 metody OnNext, OnError i OnCompleted i jest bardziej skoncentrowany na obserwacji zmiany jednej wartości niż ogólnego stanu obserwowanego obiektu.

RX – Linq dla obserwatorów

LINQ jest bardzo potężnym fragmentem standardowej biblioteki .Net opartym o 2 proste interfejsy IEnumerable i IEnumerator. Sprawił że operacje na kolekcjach stały się tak proste, że większość programistów .Net prędzej zmieni pracę niż zrezygnuje z ich używania. LINQ jest zbiorem metod rozszerzających i wzorcu dekoratora: większość metod jako parametr przyjmuje instancję IEnumerable i ewentualnie inne parametry mające wpływ na zachowanie metody. Wewnątrz tej metody jest tworzona i zwracana instancja klasy implementującej IEnumerable, która akceptuje  parametry metody rozszerzającej jako parametry konstruktora. Metoda GetEnumerator tej klasy wywołuje metodę GetEnumerator oryginalnej kolekcji i przekazuje ją do konstruktora własnej klasy implementującej interfejs IEnumerator, wraz z parametrami swojego konstruktora. Dopiero ta klasa podczas wywoływania metody MoveNext analizuje parametry przekazane w konstruktorze i dokonuje decyzji czy wywoływać metodę MoveNext z oryginalnego Enumeratora, oraz jak przekształcić jej wynik, aby otrzymać docelową kolekcję.

Zarówno interfejs IEnumerable jak i IObservable opisują serię danych, pozwalają odczytywać kolejne elementy, oraz dostarczają informacji o tym czy seria zawiera więcej elementów. Podstawową różnicą jest fakt iż w przypadku IEnumerable to kod kliencki musi odczytywać kolejne elementy, a w przypadku IObservable to biblioteka wysyła kolejne elementy.

Na tym etapie utworzenie zestawu rozszerzeń do interfejsu IObservable wydaje się być dobrym pomysłem, tak właśnie powstała biblioteka Reactive Extensions. Pomysł okazał się tak dobry, że został zaadaptowany w większości języków programowania. Oprócz oryginalnej dokumentacji stworzonej przez Microsoft, powstała alternatywna wielo-platformowa dokumentacja pozwalająca lepiej zrozumieć koncepcje. Po zapoznaniu się z nią postanowiliśmy wykorzystać bibliotekę do implementacji jednej z funkcjonalności. Zaskoczył nas fakt iż pomimo, że integracja z RX nie była uwzględniona w oryginalnej wycenie zadania, udało się je dostarczyć na czas.

Dostarczanie wartości właściwości gdy zostaje podniesione zdarzenie

Jak wspominałem w pierwszej części artykułu API, z którego korzystamy składa się w większości z par właściwość – zdarzenie. Kluczowe więc dla nas było żeby istniał sposób na  dostarczenie wartości właściwości po podniesieniu zdarzenia. Na szczęście okazało się, że RX posiada odpowiednią metodę

var sizeObservable =
    Observable
        .FromEventPattern(
            handler => someObject.SizeChanged += handler,
            handler => someObject.SizeChanged -= handler)
        .Select(o => someObject.Size);

Ponieważ w większości przypadków nasz kod wymagał aby aktualna wartość właściwości natychmiastowo wyświetliła się na ekranie, stworzyliśmy własne rozszerzenie, które do powyższej metody dodawało dostarczenie tej wartości w momencie subskrypcji.

Komunikacja między wątkami

Ponieważ nasza aplikacja wykorzystuje wiele wątków, wsparcie przesyłania wiadomości pomiędzy wątkami była czymś czego oczekiwaliśmy. RX posiada metodę ObserveOn, która jako parametr przyjmuje obiekt typu Dispatcher. Niestety nie mogliśmy jej wykorzystać ponieważ inna biblioteka, którą wykorzystujemy, ukrywa ten obiekt pod własną abstrakcją. Na szczęście okazało się, że napisanie takiego rozszerzenia (Dispatch) własnoręcznie nie jest szczególnie trudne: 1 metoda rozszerzająca, 2 klasy mniej niż 100 linijek kodu.

Obserwowanie wielu źródeł na raz

Często to co użytkownik widzi na ekranie jest wyliczane na podstawie kilku wartości dostarczanych przez bibliotekę. Kolejną fukcjonalnością jakiej oczekiwaliśmy od RX była możliwość łączenia wartości z różnych źródeł. Rozwiązaniem jest metoda CombineLatest przyjmująca jako parametr kilka obiektów IObservable i funkcję która jako parametry akceptuje ostatnie znane wartości dostarczone przez obiekty Observable, a jako wynik zwraca wartość dostarczoną do obserwatora.

Observable
    .CombineLatest(
        firstObservable,
        secondObservable,
        thirdObservable,
        (firstValue, secondValue, thirdValue) => firstValue * secondValue * thirdValue);

Poprawa wydajności

Filtrowanie wartości

Podobnie jak LINQ, RX posiada metodę Where, pozwalającą usunąć z sekwencji wartości nie spełniających określonych warunków, odciążając w ten sposób obserwatora. Dodam że inne implementacje RX nazywają tą metodę Filter.

Usuwanie duplikatów

RX posiada metodę Distinct, która gwarantuje, że obserwator otrzyma każdą wartość tylko raz.W naszej aplikacji jednak okazało się, że znacznie bardziej użyteczna jest metoda DistinctUntilChanged, która usuwa duplikaty następujące po sobie. Ustawienie CombineLatest, DistinctUntilChanged i Dispatch w odpowiedniej kolejności pozwoliło wyeliminować większość nadmiarowej komunikacji między wątkami.

Debouncing

RX zwiera metodę Debounce. Która ogranicza częstotliwość dostarczania kolejnych wiadomości. Jest ona użyteczna jeżeli nowe wartości mogą przychodzą tak często, że użytkownik nie jest w stanie ich konsumować, a utrata części komunikatów nie jest problemem. Dobrym przykładem może tu być czujnik poziomu płynu chłodniczego, w trakcie jazdy po wyboistej drodze, gdy znajdujemy się w okolicach krytycznie niskiego poziomu. W takim przypadku czujnik co chwila wysyła informację, że wszystko jest OK albo że należy dolać płynu, to sprawia, że kontrolka na desce cały czas by mrugała denerwując użytkownika. Po zastosowaniu metody Debounce kontrolka zapalałaby się na kilka – kilkanaście sekund i gasła.

Testy jednostkowe

W naszym projekcie cały czas staramy się podnosić poziom pokrycia kodu testami. Jeżeli to ułatwia pracę stosujemy biblioteki Moq i NSubstitute. Niestety obie te biblioteki domyślnie zwracają null dla właściwości typu IObservable, co zmusza nas do rozszerzenia kodu inicjującego test. Nie jest to jednak tak uciążliwe na jakie wygląda.

Analiza problemów z produkcji

Podobnie jak LINQ i metody asynchroniczne, generuje bardzo długie i nieczytelne stosy wywołań. Czasami zdarza się, że w całym stosie nie ma żadnej linijki kodu należącej do naszej aplikacji.

Nie rezygnujemy z event-agregatora

Event agregator ma miejsce w naszym projekcie i nie planujemy go usuwać. Istnieją zdarzenia o których informujemy przy pomocy obydwóch mechanizmów.

Nasza podróż przez różne rozwiązania, nauczyła nas, że jeżeli istnieją różne rozwiązania jednego problemu, to każde z nich ma swoje wady i zalety, i nie należy się kurczowo trzymać jednego rozwiązania.

Wzorzec Event aggregator, zwany czasami mediatorem albo event busem, dostarcza kanału komunikacji pomiędzy modułami aplikacji, ograniczając powiązania między nimi: moduł wysyłający wiadomość nie ma pojęcia kto na niego zareaguje, nie wiem nawet czy ktokolwiek to zrobi. Moduł oczekujący na wiadomość zazwyczaj nie musi znać nadawcy, interesuje go tylko treść wysłanej wiadomości.

Modułem naszej aplikacji, w którym ten wzorzec jest szczególnie użyteczny, jest obszar powiadomień.

W aplikacji istnieje tylko jedna instancja klasy odpowiadającej za ten obszar, klasa ta nasłuchuje na zdarzenia wysyłane przez wiele różnych klas. Bez tego wzorca wyświetlenie powiadomienia o przyjściu nowej wiadomości wymagałoby śledzenia dostępności samego serwisu wiadomości, zmian na liście rozmów oraz zmian na liście wiadomości w każdej rozmowie. Co gorsza każdy moduł, który chciałby reagować na przyjście nowej wiadomości musiałby powtórzyć znaczną część tego kodu. Dzięki event-aggregatorowi ta część kodu jest napisana raz, w klasie która wysyła wiadomość, natomiast klasy zainteresowane przyjściem nowej wiadomości wywołują tylko jedną linijkę:

_messageAggregator.Register(MessageHandlingMethod);

Drugim problemem jakim rozwiązał ten wzorzec, jest komunikacja między wątkami. Napisaliśmy jedną metodę rozszerzającą do event-aggregatora, która przenosi obsługę powiadomienia na główny wątek aplikacji:

public static void RegisterOnDispatcher(
    this MessageAggregator self,
    DispatcherService dispatcherService,
    Action handler)
{
    self.Register(message => dispatcherService.Invoke(() =>f handler(message)));
}

Zrozumienie ciała metody wymaga chwili zastanowienia, jednak jej użycie jest proste:

_messageAggregator.RegisterOndispatcher(MessageHandlingMethod);

Problemy z event-aggregatorem

Wzorzec ten jest tak wygodny, że bardzo szybko zdominował znaczną część naszego kodu. W pewnym momencie zorientowaliśmy się jednak że powoduje on pewne problemy, a innych nie rozwiązuje.

Po pierwsze wiele klas wylicza swój stan początkowy na podstawie stanu serwisu, a na wiadomość zapisuje się żeby odświeżyć swój stan, co powoduje że każda z tych klas ma dwie zależności: serwis i event-aggregator.

Wysłanie wiadomości przez event-aggregatora wymaga napisania dodatkowej klasy, ponieważ programiści są z natury leniwi starają się pominąć ten krok gdy tylko jest to możliwe, nawet kosztem „wycieku abstrakcji”. Zdarzały się przypadki gdy mieliśmy serwis, który nasłuchiwał na zdarzenia z dwóch innych serwisów i wyliczał jakąś wartość, jednak nie wysyłał żadnego powiadomienia o zmianie tej wartości. Klasy które korzystały z tej klasy nasłuchiwały na zdarzenia z oryginalnych serwisów.

Nasza aplikacja pozwala na zmianę wielu ustawień „w locie”, czyli bez konieczności restartu aplikacji. W momencie zapisu ustawień „menadżer ustawień” wysyła wiadomość. Wiele klas jest na nią zarejestrowanych i wykonuje swoją logikę, nawet jeśli konkretne ustawienie nie uległo zmianie, aby ograniczyć ten efekt dodaliśmy do wiadomości dodatkową informację o tym, które wartości uległy zmianie, co jednak zmusza nas do dopisywania kilku dodatkowych linijek kodu za każdym razem gdy pojawia się nowe ustawienie.

W aplikacji pojawiły się problemy wydajnościowe związane z komunikacją między wątkami. Co prawda wywołanie metody Dispatcher.Invoke nie jest szczególnie ciężkie i nie należy się go bać, a już na pewno nie kosztem niepoprawnego działania programu, jednak wywoływanie jej kilkanaście tysięcy razy może przyprawić o zadyszkę nawet mocne komputery i spowodować „zawieszenie” się aplikacji. Wspomniana wcześniej metoda RegisterOnDispatcher powodowała, że „Handler” był uruchamiany na głównym wątku aplikacji, nawet w przypadkach gdy efektywnie nic nie robił np. pierwsza linijka obsługi zmiany ustawień zawierała sprawdzenie czy ustawienie, którego zmianą jest klasa jest zainteresowana, nie uległo zmianie. Trudniejszym do wyśledzenia przypadkiem był przypadek gdy ustawienie uległo zmianie, ale efektywna wartość wyliczona na jego podstawie pozostała bez zmian. W tej architekturze były to problemy bardzo trudne do naprawy.

W kolejnej części artykułu opiszę jak biblioteka Reactive Extensions rozwiązała nasze problemy.

Jeden z produktów jakie ostatnio rozwijaliśmy w naszym zespole, jest aplikacją desktopową opartą o rozbudowaną bibliotekę, która dostarczała spójne API do komunikacji, opartej o różne protokoły związane z telekomunikacją, co sprawiało że generowała naprawdę dużo sygnałów.

Architektura biblioteki

Większość klas w tej bibliotece pasowała do takiego wzorca:

public class Class1
{
    public void SetDescription(string description, CompletionHandler handler)
    {
         /* Some logic here */
    }

    public void SetSize(int size, CompletionHandler handler)
    {
        /* Some logic here */
    }

    public string Description { get; private set; }

    public int Size { get; private set; }

    public event EventHandler DescriptionChanged;

    public event EventHandler SizeChanged;
}

• Metody SetDescription i SetSize wysyłają wartość przekazaną jako pierwszy parametr i wywołują metodę przekazaną jako Handler gdy serwer potwierdzi albo odrzuci żądanie
• Właściwości Description i Size zwracają ostatnią znaną wartość
• Zdarzenia DescriptionChanged i SizeChanged są uruchamiane gdy serwer powiadomi aplikację o zmianie wartości – niezależnie czy zmiana była spowodowana przez wywołanie metody Set* czy przez inne interakcje z serwerem np. działanie drugiej aplikacji

Biblioteka przetwarza wszystkie żądania na swojej własnej wewnętrznej puli wątków co ma swoje zalety i wady. Podstawową zaletą był fakt iż biblioteka, sama z siebie, nie wpływała na działanie wątku głównego aplikacji. Wadą był fakt iż wszystkie callbacki i zdarzenia podnoszone przez bibliotekę były uruchamiane na innym wątku, co wymuszało opracowanie jakiegoś mechanizmu do komunikacji między wątkami.

Ręczne zarządzanie wątkami – Nie chcesz tego robić

Już od początku rozwoju aplikacji zorientowaliśmy się, że ręczna komunikacja między wątkami kończy się powstaniem dużej ilości długiego i powtarzalnego kodu, który wygląda mniej więcej tak:

public class SomeOtherClass : IDisposable
{
    private readonly SomeClass _someObject;
    private readonly DispatcherService _dispatcherService;

    public SomeOtherClass(
        SomeClass someObject,
        DispatcherService dispatcherService)
    {
        _someObject = someObject;
        _dispatcherService = dispatcherService;

        _someObject.DescriptionChanged += SomeObjectOnDescriptionChanged;
        _someObject.SizeChanged += SomeObjectOnSizeChanged;
    }
    
    private void SomeObjectOnDescriptionChanged(object sender, EventArgs e)
    {
        _dispatcherService.Invoke(LoadState);
    }

    private void SomeObjectOnSizeChanged(object sender, EventArgs e)
    {
        _dispatcherService.Invoke(LoadState);
    }

    private void LoadState()
    {
        PropertyVisibleOnUI = $"Description: {_someObject.Description} Size: {_someObject.Size}";
    }
    
    public string PropertyVisibleOnUI { get; set; }

    public void Dispose()
    {
        _someObject.DescriptionChanged -= SomeObjectOnDescriptionChanged;
        _someObject.SizeChanged -= SomeObjectOnSizeChanged;
    }
}

Kod staje się jeszcze bardziej złożony jeżeli założymy, że niektóre właściwości klasy są złożonymi obiektami, które mają właściwości, zdarzenia, metody asynchroniczne. A takich warstw może być znacznie więcej.

API do obsługi wiadomości tekstowych napisane w tej konwencji mogło wyglądać tak:

public interface IConversationService
{
    event EventHandler ConverstionStarted;
    event EventHandler ConversationEnded; 
    IEnumerable Conversations { get; }
}

public interface IConversation
{
    event EventHandler MessageAdded;
    void SendMessage(string body, CompletionHandler handler); 
    IEnumerable Messages { get; }
}

public interface IMessage
{
    event EventHandler IsReadChanged;
    bool IsMine { get; }
    string Body { get; }
    bool IsRead { get; }
}

Koniecznie potrzebowaliśmy lepszego rozwiązania. W drugiej części artykułu opiszę jak wzorzec event-aggregator pomógł nam pokonać te problemy.