Jaka jest różnica między wzorem elewacji a wzorem adaptera?

I've been reading both definitions and they seem quite the same. Could anyone point out what are their differences?

Dzięki

The Facade Pattern wiki page has a brief note about this.

"An Adapter is used when the wrapper must respect a particular interface and must support a polymorphic behavior. On the other hand, a facade is used when one wants an easier or simpler interface to work with."

I heard an analogy that you should think of your universal remote control that you've set up to work with all your different stereo systems - you press "on" and it turns on your cable box, your receiver, and your TV. Maybe it's a really fancy home theater and it dims the lights and draws the shades too. That's a Facade - one button/function that takes care of a more complicated set of steps.

The Adapter pattern just links two incompatible interfaces.

EDIT: A quick analogy for the Adapter pattern (based on the comments) might be something like a DVI-to-VGA adapter. Modern video cards are often DVI, but you've got an old VGA monitor. With an adapter that plugs into your video card's expected DVI input, and has its own VGA input, you'll be able to get your old monitor working with your new video card.

Adapter == dopasowanie kwadratowego kołka do okrągłego otworu.

Fasada == jeden panel sterujący do obsługi wszystkich komponentów wewnętrznych.

Honestly, many patterns could be implemented the same way programmatically -- the difference is in intent.

Wzorzec projektowy adaptera ma na celu „przetłumaczenie” interfejsu jednej lub większej liczby klas na interfejs, którego klient spodziewa się użyć - adapter przetłumaczyłby wywołania na oczekiwany interfejs na rzeczywisty interfejs używany przez opakowane klasy.

Wzorzec Fasada jest używany, gdy potrzebny jest prostszy interfejs (i ponownie można go zaimplementować w ten sam sposób, opakowując naruszające klasy). Nie powiedziałbyś, że używasz fasady, gdy istniejący interfejs jest niekompatybilny, tylko wtedy, gdy potrzebujesz aby był bardziej czytelny, mniej źle zaprojektowany itp.

Fasada:

Kluczowe wnioski : (z artykułu w Journaldev autorstwa Pankaja Kumara)

1. Wzorzec elewacji bardziej przypomina pomoc dla aplikacji klienckich
2. Wzór elewacji można zastosować w dowolnym momencie rozwoju, zwykle gdy liczba interfejsów rośnie, a system staje się skomplikowany .
3. Interfejsy podsystemu nie są świadome istnienia Facade i nie powinny mieć żadnych odniesień do interfejsu Facade
4. Wzorzec elewacji powinien być stosowany do podobnych rodzajów interfejsów , jego celem jest zapewnienie pojedynczego interfejsu zamiast wielu interfejsów wykonujących podobne zadania

Diagram klas elewacji:

Adapter:

1. Jest to wzór strukturalny
2. Przydatna jest praca z dwoma niekompatybilnymi interfejsami
3. To sprawia, że ​​rzeczy działają po ich zaprojektowaniu

Schemat klas adaptera:

Więcej informacji na temat adaptera można znaleźć w tym poście SE:

Różnica między wzorem mostka a wzorem adaptera

Kluczowe różnice:

1. Fasada definiuje nowy interfejs, podczas gdy Adapter używa starego interfejsu . Adapter sprawia, że ​​dwa istniejące interfejsy współpracują ze sobą, w przeciwieństwie do definiowania całkowicie nowego
2. Adapter i fasada to opakowania; ale są to różne rodzaje opakowań. Celem programu Facade jest stworzenie prostszego interfejsu, a celem adaptera jest zaprojektowanie do istniejącego interfejsu

Zapoznaj się również z artykułem o źródłach, aby lepiej zrozumieć.

Fasada służy do organizowania wielu usług za jedną bramą usług. Adapter zaprojektowano tak, aby umożliwiał korzystanie ze znanego interfejsu w celu uzyskania dostępu do nieznanego.

Celem a

fasada to prostota

adapter to współdziałanie .

Fasada jest zwykle kontrastowana z adapterem.

+--------------------------------------------------------------+-----------------------------------------------+
|                            Facade                            |                    Adapter                    |
+--------------------------------------------------------------+-----------------------------------------------+
| Simplifies multiple complex components with single interface | Provides differnet interface for an interface |
| Works with multiple components                               | Works with single component                   |
| Control panel is an example                                  | A power adapter is an example                 |
| High-level interface                                         | Low-level interface                           |
+--------------------------------------------------------------+-----------------------------------------------+

Jak zwykle istnieją podobieństwa między kilkoma wzorami. Ale widzę to tak:

• Fasada służy do hermetyzacji całej warstwy i oferuje pewne metody „wygodnego” dostępu do niej
• Adapter jest używany, gdy masz dwa komponenty, które powinny już współpracować, ale tego nie robią, tylko z powodu pewnych „nieistotnych” różnic w interfejsie.

Spróbuję to wyjaśnić prostymi słowami, bez większych formalności.

Wyobraź sobie, że masz kilka klas domeny i interfejs użytkownika, z którym chcesz wchodzić w interakcje. Fasada może służyć do udostępniania funkcji, które można wywołać z warstwy interfejsu użytkownika, aby warstwa interfejsu użytkownika nie wiedziała o żadnych klasach domeny innych niż fasada. Oznacza to, że zamiast wywoływać funkcje w klasach domeny, wywołujesz pojedynczą funkcję z fasady, która będzie odpowiedzialna za wywoływanie potrzebnych funkcji z innych klas.

An adapter, on the other hand, can be used to integrate other external components that might have the same functionality you need but their functions are not called quite the same way. Say you've got a Car class in your domain and you work with an external car provider that has a Car class defined as well. In this class, you've got the function car.getDoors() but the external provider has the equivalent car.getNumDoors(). You don't want to change the way you call this function, so you can use an adapter class to wrap the external Car class so that a call to getDoors() of the adapter is delegated to getNumDoors() of the external class.

Adapter pattern allows two,previously incompatible, interfaces to work with each other. Has 2 separate interfaces in play.

The Facade pattern takes a known interface, that is low level/fine grained, and wraps it with a higher level/course grained interface. Has a single interface, that has been simplified by wrapping with another.

Adapter makes two interfaces work together.

Facade exposes a single class to a higher, and more limited level. For example, a view model facade may only expose certain read only properties of a lower level class.

Facade

Abstracts complexity to provide a simpler interface. Say for example, an computer OS abstracts the complexity of underlying hardware. Or a high-level programing languages(Python/JavaScript) abstracts complexity when compared to a low-level language(C).

Adapter

It's analogues to a hardware adapters. Say you want to connect a USB device to a serial port, you will need a USB-serial port adapter.

Adapter pattern links two incompatible interfaces by providing a new interface.

Facade pattern simplifies a complex subsystem(having multiple components) with a single interface.

The difference between these two patterns is clear, but not in the realm of Design Patterns, but Domain Modeling. In the following, I'll explain why.

First, I want to reiterate others have said here, and then I'll add the note:

A Facade is an interface to a subsystem (an external or a legacy system) that simplifies the access for the client (us). Facade hides the interface of the other subsystem (aggregate some calls, or hide some APIs that we don't need), thus your client only accesses that subsystem through this Facade.

Z drugiej strony adapter to opakowanie otaczające inną usługę lub obiekt. Sprawia, że ​​opakowany obiekt jest zgodny ze standardowym interfejsem, którego oczekuje klient. Powiedzmy, że w obiekcie „Ledger” istnieje metoda, którą należy dostosować (zmienić parametry, zmienić nazwę itp.). Możesz go owinąć adapterem.

Teraz różnica może nie być oczywista. W tym miejscu chcę przywołać kluczową różnicę między tymi dwoma wzorcami, nie pozostawiając miejsca na dalsze zamieszanie :

Fasada nie zmienia modelu domeny innego podsystemu, podczas gdy Adapter tak. To jest kluczowa różnica. Kropka.

Dlatego łączysz te dwa elementy podczas tworzenia warstwy antykorupcyjnej . Załóżmy, że masz podsystem, którego chcesz użyć, ale nie chcesz, aby jego model domeny bałaganił model domeny. Co byś zrobił? Utworzyłbyś warstwę antykorupcyjną. W jaki sposób? Najpierw tworzysz fasadę, która upraszcza dostęp do interfejsu dla podsystemu, a następnie adaptery dla obiektów domeny używanych w tym interfejsie (pamiętaj, że fasada nadal zawiera model domeny dla drugiego podsystemu), aby była zgodna z Twoim modelem.

W modelowaniu domeny można używać wielu wzorców projektowych. Dotyczy to również wzorców projektowych elewacji i adapterów. Chociaż różnica między tymi dwoma wzorcami może nie być wyraźna w dziedzinie „wzorców projektowych”, jest bardziej wyraźna w dziedzinie „modelowania domeny”.

Czytałem obie definicje i wydają się być takie same.

Naprawdę?

Zauważyłem, że termin Adapter jest czasami używany do opisania tego, co w rzeczywistości jest strategią , być może dlatego, że słowo to jest bardziej wyraziste.

Na przykład w Zend Framework wszystkie klasy Adapter są w rzeczywistości implementacjami wzorca Strategy , ponieważ zawijają tylko kod natywny za klasami, aby mieć kilka zachowań.

Adaptery są często używane do opakowywania starszego lub „starego” kodu.

The main goal of the Facade pattern is to make the class or subsystem easier to use, while the main goal of the Adapter pattern is to adjust the interface to what the client expects.