Wzorzec projektowy Facade

Intencja

• Zapewnia ujednolicony interfejs do zestawu interfejsów w podsystemie.Facade definiuje interfejs wyższego poziomu, który sprawia, że podsystem jest łatwiejszy w użyciu.
• Owijanie skomplikowanego podsystemu prostszym interfejsem.

Problem

Segment społeczności klientów potrzebuje uproszczonego interfejsu do ogólnej funkcjonalności złożonego podsystemu.

Dyskusja

Facade omawia hermetyzację złożonego podsystemu w ramach pojedynczego obiektu interfejsu. Zmniejsza to krzywą uczenia się niezbędną do skutecznego wykorzystania podsystemu. Promuje również odłączenie podsystemu od jego potencjalnie wielu klientów. Z drugiej strony, jeśli Fasada jest jedynym punktem dostępu do podsystemu, ograniczy funkcje i elastyczność, których mogą potrzebować „zaawansowani użytkownicy”.

Obiekt Fasada powinien być dość prostym obrońcą lub ułatwiaczem. Nie powinien stać się wszechwiedzącą wyrocznią lub obiektem „boga”.

Struktura

Facade bierze „zagadkę zawiniętą w enigmę owianą tajemnicą” i wprowadza opakowanie, które oswaja amorficzną i niezrozumiałą masę oprogramowania.

SubsystemOne i SubsystemThree nie wchodzą w interakcję z wewnętrznymi komponentami SubsystemTwo. Używają SubsystemTwoWrapper „fasady” (tj. abstrakcji wyższego poziomu).

Przykład

Fasada definiuje ujednolicony interfejs wyższego poziomu do podsystemu, który ułatwia jego użytkowanie. Konsumenci napotykają Fasady podczas zamawiania z katalogu. Konsument dzwoni pod jeden numer i rozmawia z przedstawicielem działu obsługi klienta. Przedstawiciel obsługi klienta działa jako fasada, zapewniając interfejs do działu realizacji zamówień, działu rozliczeń i działu wysyłki.

Lista kontrolna

1. Zidentyfikuj prostszy, ujednolicony interfejs dla podsystemu lub komponentu.
2. Zaprojektuj klasę 'wrapper’, która hermetyzuje podsystem.
3. Fasada/wrapper przechwytuje złożoność i współpracę komponentu, i deleguje do odpowiednich metod.
4. Klient używa (jest sprzężony z) tylko fasady.
5. Rozważ, czy dodatkowe Fasady zwiększyłyby wartość.

Rules of thumb

• Facade definiuje nowy interfejs, podczas gdy Adapter używa starego interfejsu.Pamiętaj, że Adapter sprawia, że dwa istniejące interfejsy działają razem, w przeciwieństwie do definiowania zupełnie nowego.
• Gdy Flyweight pokazuje, jak stworzyć wiele małych obiektów, Facadeshows pokazuje, jak sprawić, by pojedynczy obiekt reprezentował cały podsystem.
• Mediator jest podobny do Facade w tym, że abstrahuje funkcjonalność istniejących klas. Mediator abstrahuje/scentralizuje arbitralną komunikację pomiędzy obiektami kolegów. Rutynowo „dodaje wartość” i jest znany/odwoływany przez obiekty kolegialne. W przeciwieństwie do tego, Facade definiuje prostszy interfejs do podsystemu, nie dodaje nowej funkcjonalności i nie jest znany przez klasy podsystemu.
• Abstrakcyjna fabryka może być używana jako alternatywa dla Facade do ukrywania klas specyficznych dla danej platformy.
• Obiekty Facade są często Singletonami, ponieważ tylko jeden obiekt Facade jest wymagany.
• Adapter i Facade są zarówno wrapperami; ale są to różne rodzaje wrapperów. Intencją Facade jest stworzenie prostszego interfejsu, a intencją Adaptera jest zaprojektowanie do istniejącego interfejsu.Podczas gdy Facade rutynowo owija wiele obiektów, a Adapter owija pojedynczy obiekt; Facade może być front-endem pojedynczego złożonego obiektu, aAdapter może owijać kilka starszych obiektów.

Pytanie: Czyli sposobem na odróżnienie wzorcaAdapter od wzorca Facade jest to, że Adapter opakowuje jedną klasę, a Facade może reprezentować wiele klas?

Odpowiedź: Nie! Pamiętaj, że wzorzec Adapter zmienia interfejs jednej lub więcej klas w jeden interfejs, którego oczekuje klient. Podczas gdy większość podręcznikowych przykładów pokazuje adapter dostosowujący jedną klasę, może być konieczne dostosowanie wielu klas, aby zapewnić interfejs, do którego klient jest zakodowany. Podobnie, fasada może dostarczać uproszczony interfejs do pojedynczej klasy z bardzo złożonym interfejsem. Różnica między nimi nie polega na tym, ile klas „opakowują”, lecz na ich intencji.