Jako zwolennik leniwej optymalizacji, czyli nie przejmowania się wydajnością aplikacji dopóki owa aplikacja nie zacznie spowalniać – mam kłopot z dzisiejszym wpisem. Jest tak, ponieważ chciałbym tutaj naświetlić wzorzec projektowy Remote Facade – Zdalna Fasada, który wymusza na nas taką optymalizacje już na etapie projektu architektury programu. Wpis ten jest rozwinięcie tematu o Data Transfer Object, a oba wzorce doskonale się uzupełniają.
Problem jaki przeważnie niesie optymalizacja to trudne do pogodzenia światy: czytelności kodu oraz jego wydajności. Stąd jest ważne by oprzeć poprawę efektywności kodu na jakimś sprawdzonym wzorcu. Zacznijmy jednak od początku, czym jest Remote Facade?
“Zapewnia ogólną fasadę dla szczegółowych obiektów, której celem jest poprawa efektywności ruchu sieciowego.”
gdzie przez “ogólną fasadę” mamy tu namyśli wzorzec Fasady z Gangu Czworga. Taki obiekt upraszcza nam interfejs, a w przypadku obiektów zdalnych ma za zadanie zmniejszyć ilość interakcji między nimi. Zdalnym obiektem może tu być nie tylko obiekt wywoływany na przeciwnym krańcu kuli ziemskiej, ale nawet obiekt wywoływany na tym samym komputerze (w ramach innego procesu).
Remote Facacde zastępuje wszystkie metody set() i get() jedną metodą set oraz jedną metodą get (zwanymi jako blokowe metody dostępu). Fasada może działać na zasadzie bramy dostępowej. Implementacja nie powinna być trudna , ważne jest tutaj by wybrać taki format przechowywania danych, aby łatwo można było te dane wysłać przez sieć. Trzeba uważać na serializacje całego obiektu, nie zawsze jest to dobry pomysł. W takim przypadku warto użyć DTO. Innym problemem wynikającym z stosowania Remote Facade jest poziom szczegółowości. Możemy mieć wiele fasad obejmujących stosunkowo niewielki zakres działania lub wprost przeciwnie ograniczyć się jedynie do kilku. To drugie podejście zaleca Fowler w swojej książce Architektura Systemów Zarządzania Przedsiębiorstwem. Wzorce projektów. Ciekawym pomysłem jest wykorzystanie Remote Facade jako mechanizmu zabezpieczeń czy obsługi transakcji. Listy dostępu mogą określać, który użytkownik ma dostęp do wywołania danej metody.
Na zakończenie, warto mieć na uwadze, że Remote Facade nie może zawierać żadnej logiki dziedziny. Jeśli konieczne jest użycie dziedziny np. do sterowania przebiegiem pracy czy koordynowania to można albo implementacje przenieść do obiektów szczegółowych lub użyć wzorca Transaction Script. Remote Facade nie użyjemy wszędzie tam gdzie potrzebujemy asynchronicznych komunikatów, zresztą takie podejście mija się z celem stosowania fasady.
Więcej informacji na ten temat w książce “Architektura Systemów Zarządzania Przedsiębiorstwem. Wzorce projektowe“. M. Fowler.