Miałem gorącą dyskusję na ten temat w firmie dzisiaj. Co o tym myślicie?
Kolegom z pracy fasada kojarzy się przede wszystkim z http://en.wikipedia.org/wiki/Interface_segregation_principle (tzn nie wiem czy znają tą zasadę w kontekście SOLID, ale ich pogląd na fasadę jest mniej więcej taki jak meritum tej zasady) i są niechętni temu, żeby fasada zarządzała jakimkolwiek stanem.
To może to nie jest Fasada tylko Broker skoro chcesz żeby zarządzała czymś?
Przykład 1:
Fasada, która rozpoznaje czy system pod spodem zaczął transakcję i zapamiętująca jej numer. Równocześnie fasada wystawia metodę, która pozwala na zwrócenie aktualnej transakcji. Czy to jest fasada, czy może już nie?
Przykład 2:
Zrobiłem warstwę komunikacji ze sprzętem. Komunikacja odbywa się po socketach i przesyłane są generalnie obiekty (które moja warstwa serializuje i deserializuje). Niektóre odpowiedzi zawierają w sobie pole lastPromptNum. Warstwa rozpoznaje czy odpowiedź zawiera to pole i zapisuje go w podanym jej jako parametr holderze (tzn klasa opakowująca zwykłą referencję). Czy to jest fasada czy może już nie?
Fasada upraszcza i organizuje interfejs zatem:
przykład 1: jeżeli oryginalny system udostępnia transakcję to metoda udostępniająca transakcję w fasadzie jest ok. Zapamiętanie identyfikatora transakcji też o ile pobranie go z oryginalnego interfejsu jest możliwe, ale skomplikowane (np. musisz pobrać meta dane potem opis transakcji i dopiero wtedy jej numer).
Przykład 2: bardziej pasuje mi tu fasadę z proxy ponieważ poza oryginalną akcją wykonywane są też pewne dodatkowe akcje.
@Shalom:
O co konkretnie chodzi? http://en.wikipedia.org/wiki/Message_broker jakoś mi nie pasuje nijak tutaj.
@Koziołek:
Nigdzie nie znalazłem sugestii, żeby pełnomocnik miał grzebać w odpowiedziach z obiektu do którego deleguje i potem jeszcze te informacje przetrzymywać i udostępniać na zewnątrz.
Czy ktokolwiek widział jakiś artykuł eksperta od wzorców na temat stanu w fasadzie?
Nie nie, bardziej: http://www.openloop.com/softwareEngineering/patterns/architecturePattern/arch_Broker.htm
Fasada to jest dla mnie po prostu takie proxy które upraszcza interfejs dla jakiegoś skomplikowanego obiektu.
Broker to jest obiekt który agreguje w sobie jeden lub więcej skomplikowanych obiektów i zapewnia warstwę korzystania z nich, często łącząc i przetwarzając dane uzyskane z kilku obiektów które agreguje.
Np. mamy po jednym obiekcie na każdą giełdę i te obiekty potrafią zwracać nam informacje o kursach na tej giełdzie. Użytkownik który gra na więcej niż jednej giełdzie jest zainteresowany kursami wszystkich spółek które go interesuje i nie obchodzi go że one są na różnych giełdach. W efekcie można napisać takiego Brokera który dostaje konfigurację spółek które interesują użytkownika, a potem na żądanie zwraca aktualne kursy rzeczonych spółek (pobierając odpowiednie dane z obiektów które agreguje i przetwarzając je).
Z architektonicznego punktu widzenia to wygląda to jak fasada -> mamy obiekt który agreguje w sobie jakiś skomplikowany obiekt/obiekty i udostępnia bardziej przyjazne API, ale cel jest inny,