Czym jest Fasada Design Pattern?

Wikipedia ma świetny przykład wzoru elewacji.

/* Complex parts */

class CPU {
    public void freeze() { ... }
    public void jump(long position) { ... }
    public void execute() { ... }
}

class Memory {
    public void load(long position, byte[] data) { ... }
}

class HardDrive {
    public byte[] read(long lba, int size) { ... }
}

/* Facade */

class ComputerFacade {
    private CPU processor;
    private Memory ram;
    private HardDrive hd;

    public ComputerFacade() {
        this.processor = new CPU();
        this.ram = new Memory();
        this.hd = new HardDrive();
    }

    public void start() {
        processor.freeze();
        ram.load(BOOT_ADDRESS, hd.read(BOOT_SECTOR, SECTOR_SIZE));
        processor.jump(BOOT_ADDRESS);
        processor.execute();
    }
}

/* Client */

class You {
    public static void main(String[] args) {
        ComputerFacade computer = new ComputerFacade();
        computer.start();
    }
}

Jak wyjaśniono w poprzedniej odpowiedzi, zapewnia prosty interfejs do klienta. Na przykład: "oglądaj ESPN" jest zamierzoną funkcją. Ale składa się z kilku kroków takich jak:

1. Włącz telewizor w razie potrzeby;
2. sprawdzanie działania satelity/kabla;
W razie potrzeby Przełącz na ESPN.

Ale fasada uprości to i po prostu dostarczy klientowi funkcję "watch ESPN".

Fasada ukrywa złożoność systemu i zapewnia interfejs do klienta, z którego klient może uzyskać dostęp do systemu.

public class Inventory {
public String checkInventory(String OrderId) {
    return "Inventory checked";
}
}

public class Payment {
public String deductPayment(String orderID) {
    return "Payment deducted successfully";
}
}


public class OrderFacade {
private Payment pymt = new Payment();
private Inventory inventry = new Inventory();

public void placeOrder(String orderId) {
    String step1 = inventry.checkInventory(orderId);
    String step2 = pymt.deductPayment(orderId);
    System.out
            .println("Following steps completed:" + step1
                    + " & " + step2);
   }
}

public class Client {
       public static void main(String args[]){
         OrderFacade orderFacade = new OrderFacade();
         orderFacade.placeOrder("OR123456");
         System.out.println("Order processing completed");
       }
  }

Fasadę nie należy opisywać jako klasę, która zawiera wiele innych klas. W rzeczywistości jest to interfejs do tych klas i powinno ułatwić korzystanie z klas, w przeciwnym razie Klasa fasady jest bezużyteczna.

Krótkie i proste wyjaśnienie:

• Wzór elewacji zapewnia zunifikowany interfejs do zestawu interfejsów) w podsystemie.
• Facade definiuje interfejs wyższego poziomu, który sprawia, że podsystem łatwiejszy w użyciu.

Spróbuj zrozumieć scenariusz z fasadą i bez:
Jeśli chcesz przelać pieniądze z accout1 na account2, to dwa podsystemy, które należy wywołać, to wypłata z account1 i wpłata na account2.

Wzór elewacji jest owijką wielu innych interfejsów w wyniku czego powstaje prostszy interfejs.

Wzorce projektowe są przydatne, ponieważ rozwiązują powtarzające się problemy i ogólnie upraszczają kod. W zespole programistów, którzy zgadzają się na stosowanie tych samych wzorców, poprawia to wydajność i zrozumienie podczas utrzymywania drugiego kodu.

Spróbuj przeczytać więcej wzorów:

Wzór Elewacji: http://www.dofactory.com/Patterns/PatternFacade.aspx#_self1

Lub bardziej ogólnie: http://www.dofactory.com/Patterns/Patterns.aspx

Dodatkowym zastosowaniem wzoru elewacji może być zmniejszenie krzywej uczenia się zespołu. Podam ci przykład:

Załóżmy, że Twoja aplikacja musi współdziałać z MS Excel, korzystając z modelu obiektowego com dostarczonego przez Excel. Jeden z członków Twojego zespołu zna wszystkie interfejsy API programu Excel i tworzy na nich fasadę, która spełnia wszystkie podstawowe scenariusze aplikacji. Żaden inny członek zespołu nie musi poświęcać czasu na naukę interfejsu API programu Excel. Zespół może korzystać fasada bez znajomości wewnętrznych lub wszystkich obiektów MS Excel zaangażowanych w realizację scenariusza. Czy to nie wspaniałe?

W ten sposób zapewnia uproszczony i ujednolicony interfejs na szczycie złożonego podsystemu.

Fasada eksponuje uproszczone funkcje, które są najczęściej nazywane, a implementacja ukrywa złożoność, z którą klienci w przeciwnym razie mieliby do czynienia. Ogólnie implementacja używa wielu pakietów, klas i funkcji. Dobrze napisane fasady sprawiają, że bezpośredni dostęp do innych klas jest rzadki. Na przykład, gdy odwiedzam bankomat i wypłacam pewną kwotę. Bankomat ukrywa, czy idzie prosto do posiadanego banku, czy też przechodzi przez sieć wynegocjowaną dla Zewnętrznego Banku. Na Bankomat działa jak fasada pochłaniająca wiele urządzeń i podsystemów, z którymi jako klient nie muszę się bezpośrednio zmagać.

Odnośnie Twoich zapytań:

Czy fasada jest klasą, która zawiera wiele innych klas?

Co czyni go wzorcem projektowym? Dla mnie jest to jak normalna Klasa

Wszystkie wzorce projektowe również są normalnymi klasami. @Unmesh Kondolikar słusznie odpowiedział na to pytanie.

Możesz mi wyjaśnić o tej fasadzie, jestem nowy w projektowaniu wzory.

Według GoF, Fasada wzór projektu jest defind jako:

Zapewnij zunifikowany interfejs zestawowi interfejsów w podsystemie. Wzór elewacji definiuje interfejs wyższego poziomu, który ułatwia korzystanie z podsystemu

Wzórfasady jest zwykle używany, gdy:

1. prosty interfejs jest wymagany do uzyskania dostępu do złożonego systemu.
2. abstrakcje i implementacje podsystemu są ściśle / align = "left" /
3. potrzebny jest punkt wejścia do każdego poziomu oprogramowania warstwowego.
4. System jest bardzo złożony lub trudny do zrozumienia.

Ta strona internetowa oferuje opcje rezerwacji

1. loty
2. hotele
3. Loty + Hotele

Fragment kodu:

import java.util.*;

public class TravelFacade{
    FlightBooking flightBooking;
    TrainBooking trainBooking;
    HotelBooking hotelBooking;

    enum BookingType {
        Flight,Train,Hotel,Flight_And_Hotel,Train_And_Hotel;
    }; 

    public TravelFacade(){
        flightBooking = new FlightBooking();
        trainBooking = new TrainBooking();
        hotelBooking = new HotelBooking();        
    }
    public void book(BookingType type, BookingInfo info){
        switch(type){
            case Flight:
                // book flight;
                flightBooking.bookFlight(info);
                return;
            case Hotel:
                // book hotel;
                hotelBooking.bookHotel(info);
                return;
            case Train:
                // book Train;
                trainBooking.bookTrain(info);
                return;
            case Flight_And_Hotel:
                // book Flight and Hotel
                flightBooking.bookFlight(info);
                hotelBooking.bookHotel(info);
                return;
             case Train_And_Hotel:
                // book Train and Hotel
                trainBooking.bookTrain(info);
                hotelBooking.bookHotel(info);
                return;                
        }
    }
}
class BookingInfo{
    String source;
    String destination;
    Date    fromDate;
    Date     toDate;
    List<PersonInfo> list;
}
class PersonInfo{
    String name;
    int       age;
    Address address;
}
class Address{

}
class FlightBooking{
    public FlightBooking(){

    }
    public void bookFlight(BookingInfo info){

    }
}
class HotelBooking{
    public HotelBooking(){

    }
    public void bookHotel(BookingInfo info){

    }
}
class TrainBooking{
    public TrainBooking(){

    }
    public void bookTrain(BookingInfo info){

    }
}

Wyjaśnienie:

1. FlightBooking, TrainBooking and HotelBooking są różne podsystemy dużego systemu : TravelFacade

2. TravelFacade oferuje prosty interfejs do rezerwacji jednej z poniższych opcji

   Flight Booking
   Train Booking 
   Hotel Booking
   Flight + Hotel booking 
   Train + Hotel booking
   

3. Rezerwuj API z TravelFacade wewnętrznie wywołania poniżej API podsystemów

   flightBooking.bookFlight
   trainBooking.bookTrain(info);
   hotelBooking.bookHotel(info);
   

4. W ten sposób TravelFacade zapewnia prostsze i łatwiejsze API bez ujawniania podsystemowych interfejsów API.

Najważniejsze informacje: (z journaldev artykuł autorstwa Pankaj Kumar )

1. wzór elewacji jest bardziej jak Pomocnik dla aplikacji klienckich
2. wzór elewacji można zastosować w dowolnym punkcie zabudowy, Zwykle gdy liczba interfejsów rośnie i system staje się complex.
3. Interfejsy podsystemu nie są świadome elewacji i są Nie powinno mieć żadnych odniesień do interfejsu fasady
4. wzór elewacji powinien być stosowany dla podobnego rodzaju interfejsów, jego celem jest zapewnienie jednego interfejs zamiast wielu interfejsów, które wykonują podobne zadania]}

Fasada to klasa o poziomie funkcjonalności, która leży pomiędzy zestawem narzędzi a kompletną aplikacją, oferująca uproszczone korzystanie z klas w pakiecie lub podsystemie. Intencją wzoru elewacji jest zapewnienie interfejsu, który sprawia, że podsystem jest łatwy w użyciu. -- Wyciąg z Książki wzorce projektowe w C#.

Facade omawia enkapsulację złożonego podsystemu w obrębie jednego obiektu interfejsu. Zmniejsza to krzywą uczenia się niezbędną do skutecznego wykorzystania podsystemu. Promuje również oddzielenie podsystemu od potencjalnie wielu klientów. Z drugiej strony, jeśli fasada jest jedynym punktem dostępowym dla podsystemu, ograniczy to funkcje i elastyczność, których mogą potrzebować" zaawansowani użytkownicy".

Źródło: https://sourcemaking.com/design_patterns/facade

Kolejny przykład fasady: powiedzmy, że Twoja aplikacja łączy się z bazą danych i wyświetla wyniki w interfejsie użytkownika. Możesz użyć fasady, aby skonfigurować aplikację, tak jak w przypadku uruchamiania przy użyciu bazy danych lub z mock objects. Więc wykonasz wszystkie wywołania bazy danych do klasy facade, gdzie odczyta konfigurację aplikacji i zdecyduje się odpalić zapytanie db lub zwrócić obiekt makiety. w ten sposób aplikacja staje się niezależna od db w przypadku, gdy db jest niedostępne.

Wzorzec projektowy jest ogólnym rozwiązaniem wielokrotnego użytku do powszechnie występującego problemu w danym kontekście w projektowaniu oprogramowania.

Wzór konstrukcyjny elewacji jest wzorem strukturalnym, ponieważ określa sposób tworzenia relacji między klasami lub podmiotami. Wzór konstrukcyjny elewacji służy do zdefiniowania uproszczonego interfejsu do bardziej złożonego podsystemu.

Wzór elewacji jest idealny przy pracy z dużą liczbą klas współzależnych, lub z klasami, które wymagają stosowanie wielu metod, szczególnie gdy są one skomplikowane w użyciu lub trudne do zrozumienia. Klasa fasady to" owijarka", która zawiera zestaw elementów, które są łatwo zrozumiałe i proste w użyciu. Członkowie ci uzyskują dostęp do podsystemu w imieniu użytkownika fasady, ukrywając szczegóły implementacji.

Wzór konstrukcyjny fasady jest szczególnie przydatny podczas zawijania podsystemów, które są źle zaprojektowane, ale nie mogą być refakturowane, ponieważ kod źródłowy jest niedostępny lub istniejący interfejs jest szeroko stosowany. Czasami możesz zdecydować się na wdrożenie więcej niż jednej fasady, aby zapewnić podzbiory funkcjonalności do różnych celów.

Przykładem zastosowania wzoru elewacji jest integracja strony internetowej z aplikacją biznesową. Istniejące oprogramowanie może zawierać duże ilości logiki biznesowej, które muszą być dostępne w określony sposób. Witryna internetowa może wymagać jedynie ograniczonego dostępu do tej logiki biznesowej. Na przykład witryna internetowa może wymagać pokazania, czy Element dla sprzedaż osiągnęła ograniczony poziom zapasów. Metoda IsLowStock klasy facade może zwrócić wartość logiczną, aby to wskazać. Za kulisami metoda ta może ukrywać złożoność przetwarzania bieżącego fizycznego zapasów, przychodzących zapasów, przydzielonych artykułów i niskiego poziomu zapasów dla każdego artykułu.

Istnieje bardzo dobry przykład wzorca - Rozrusznik Samochodowy .

Jako kierowcy, po prostu włączamy kluczyk i samochód startuje. Tak proste, jak to tylko możliwe. Za kulisami bierze udział wiele innych systemów samochodowych (jak akumulator, silnik, paliwo itp.), aby samochód zaczął się pomyślnie, ale są ukryte za rozrusznikiem.

Jak widać, rozrusznik to Fasada. Daje nam łatwy w użyciu interfejs, bez martwienia się o złożoność wszystkie inne systemy samochodowe.

Podsumujmy:

wzór elewacji upraszcza i ukrywa złożoność dużych bloków kodu lub interfejsów API, zapewniając czystszy, zrozumiały i łatwy w użyciu interfejs.

Wszystkie wzorce projektowe to niektóre klasy ułożone w taki lub inny sposób, który pasuje do konkretnej aplikacji. Celem wzoru elewacji jest ukrycie złożoności operacji lub operacji. Możesz zobaczyć przykład i poznać wzór elewacji z http://preciselyconcise.com/design_patterns/facade.php

Jest to w zasadzie system prześwitu pojedynczego okna.Przypisujesz dowolną pracę, która będzie delegowana do określonej metody w innej klasie.

Wzór konstrukcyjny elewacji wchodzi w skład wzoru konstrukcyjnego. W skrócie Fasada oznacza wygląd zewnętrzny. Oznacza to, że w projekcie elewacji coś ukrywamy i pokazujemy tylko to, czego właściwie wymaga klient. Czytaj więcej na blogu poniżej: http://www.sharepointcafe.net/2017/03/facade-design-pattern-in-aspdotnet.html

Wzór elewacji zapewnia zunifikowany interfejs do grupy interfejsu podsystemu. Fasada definiuje interfejs wysokiego poziomu, co upraszcza pracę z podsystemem.