Patrząc na dowolną bazę danych ustawień (np. rejestr Windows) mamy przed oczami następujący obraz: aplikacja wywołuje funkcję i zmienia dane, gdy dane gdzieś są potrzebne, są odczytywane i używane. Niby wszystko ładnie, co jednak, gdy potrzebujemy użyć zmienionych danych natychmiast po ich użyciu? Albo gdy chcemy zapewnić dostęp do konkretnych danych tylko i wyłącznie, gdy są w użyciu (np. pobieranie aktualnej rozdzielczości, pozycji okna)? Zwykle w takim przypadku stosuje się albo ręczne powiadomienia, albo odpytania. Jedno i drugie z elegancją wspólnego ma tyle, co garbage collector z C. Ostatnio, pracując nad własnym systemem opcji, znalazłem rozwiązanie ładniejsze i zdecydowanie sprawniejsze.
Założenie: chcemy mieć prostą metodę na dostęp do określonej informacji tylko po jej załadowaniu, w momencie zmiany aplikacja ma natychmiastowo reagować na nową wartość, ponadto chcemy, żeby było to przezroczyste z resztą systemu opcji. Krótko: używany normalnych metod Options.Get(name, value) i Options.Set(name, value), które działają niezależnie od tego, czy dana informacja jest zapisywana, czy używana runtime.
Wykonanie: klasa Options przechowuje wszystkie parametry jako dziedziczące po abstrakcyjnej klasie bazowej, na ten przykład po IValue. Wyprowadzamy z IValue klasę pochodną IRuntimeValue - klasa przesłania metody Get i Set, wywołując... właśnie, co? Dodajmy interfejs IRuntimeDelegate - z dwoma metodami: bool ValueSet(name, newValue) oraz bool ValueGet(name, byRefValue). IRuntimeValue wymaga przekazania mu wskaźnika do istniejącego IRuntimeValue - w momencie wywołania odpowiednich metod, wywoływane są odpowiednie metody.
Jak wygląda za to implementacja od strony użytkownika? Normalnie dodawanie opcji opierało się na wywołaniu Options.Add(name, type, value) - w tym przypadku używana jest nowa metoda Options.Register(name, type, delegate). W efekcie - po zarejestrowaniu opcji działającej jako runtime możemy swobodnie używać mechanizmów modyfikacji opcji, nie przejmując się tym, czy są one osadzone na stałe, czy używane wyłącznie tymczasowo. Rozwiązanie, przetestowane praktycznie w kilku implementacjach (pomysł nie jest mój, podziękowania należą się pomysłodawcom działania OMA DM w Symbianie), sprawdza się dobrze i działa naprawdę sprawnie. Do tego jest zdecydowanie wygodniejsze niż przekazywanie wszędzie setek interfejsów, parametrów, wskaźników, callbacków itd.
Brak komentarzy:
Prześlij komentarz