What is the difference between Facade and Gateway design patterns?

or Facade==Gateway?

Reviewing Facade in the GoF book and the link in another answer to Martin Fowler's Gateway, it appears that their focus is in opposite directions.

Facade provides a simple uniform view of complex internals to (one or more) external clients;

Gateway provides a simple uniform view of external resources to the internals of an application.

This distinction lets us focus on which is more important in a design:

With the Facade, the external system is our customer; it is better to add complexity facing inwards if it makes the external interface simpler.

With the Gateway, the internal system is our customer; give it all the help we can, even if the externals are more complex.

These two patterns are very similar in the way that both they serve as wrappers over something. The difference is in the context: facade stands over a group of subsystems, while gateway can be standing over any functionality. From this point of view, to me Facade is the concrete case of Gateway (not opposite).

Facade is applied when we think that working with subsystems is complex or if we want to group several subsystem calls into one [method] execution. However, this does not necessarily mean that subsystems are not accessible, or that they are complex enough. It simply means that we have subsystems.

Gateway is applied when we want to wrap some things and expose them into different way. Gateway may be wrapping not a subsystem, but just a relatively complex functionality. Gateway is a general pattern which can be thought as a basis for Facade, Proxy, and other patterns.

If example is still needed for clarification:

Facade can calculate credit worthiness of a customer by querying checking accounts subsystem, credit accounts subsystem, savings subsystem, and back office subsystem (I guess I have seen similar example in GOF books).

class MortgateFacade {
    bool IsCreditWorth(string customerName) {
        return !_checkingAccSystem.HasNegativeBalance(customerName) && !_creditAccSystem.HasNegativeCredit(customerName) && !_backOfficeSystem.IsInBlackList(customerName);
    }
}

Gateway can query the database table and return customer by ID. (Yes, that simple!)

class CustomersGateway {
    Customer GetCustomer(int id) {
        return _db.ExecuteOne("SELECT TOP 1 FROM CUSTOMERS WHERE CUSTOMER_ID="+id).AsCustomer();
    }
}

[Obviously this is a pseudo code]

The Intent of Facade is given by http://c2.com/cgi/wiki?FacadePattern as

> Provide a unified interface to a set > of interfaces in a subsystem. Facade > defines a higher-level interface that > makes the subsystem easier to use. > This can be used to simplify a number > of complicated object interactions > into a single interface.

The focus here is on designing an interface which hides complexity, and I think the key idea is to hide multiple fine-grained interactions in a single more usable interaction. Hence the focus of Facade is client-facing.

The gateway pattern is not one of the original GOF patterns, and I see it more as an Enterprise Integration Pattern, ie at a rather higher level than the Facade. See Fowler's definition

I see the Gateway as principally about hiding technological complexity rather then interface complexity - hiding the details of connecting to mainframes and external systems. In fact I often expect the gateway to become something of a request router, perhaps even selecting different backend systems on the basis of request details. So I see Gateway as being focused on the things it's a gateway to.

Obviously, informally a Gateway is a Facade, in that it hides detail, but I think when you implement a GOF Facade and a Fowler Gateway you end up doing quite different things.

This might be somewhat simplified but here is my take on it.

• When using the Facade pattern you provide the interface that others can use to talk to your application. Example: You have implemented some application that has multiple "modules", to make the access to the "modules" easier you create a Facade to make it easier to interact with the modules... a single point of contact.
• When using the Gateway pattern you encapsulate some external part that you want to use. Example: you want to use logging but don't want to bound to a specific logging framework, in that case you can define your gateway that defines the functionality you want to use and let the gateway handle the interaction with the logging framework you want to use. This make it easy to change logging framework in the future.

Here's the direct quote from Fowler's book:

> While Facade simplifies a more complex API, it's usually done by the > writer of the service for general use. A Gateway is written by the > client for its particular use. In addition, a Facade always implies a > different interface to what it's covering, whereas a Gateway may copy > the wrapped facade entirely, being used for substitution or testing > purposes.

[Chapter 18]

I think Gateway is a specific case of Facade - a facade over an external system.

Simply put, Facade is a design pattern while Gateway is an architectural pattern.

Application Gateway, for example, is an infrastructure architecture pattern. The node resides in DMZ and insulates internal nodes from external clients who can only connect to application gateway.

When you think about architecture patterns, think about nodes. When you think about design patterns, think about classes/objects.

Node is an abstraction of: device - hardware stuff and system software - e.g. OS, platform/framework etc. System software is "assigned" to the device. Node "encapsulates" both device and system software and is related to other nodes comprising the architecture.

Gateway is a node that insulates server nodes from client nodes - client node cannot directly connect to a server node. Gateway receives the connection and then establishes connection itself to the destination node.

A facade pattern main value is to 'simplify' use of internal components (behind the facade). It could be so that one entry point or function in the facade will use multiple functions of the internal components. If a gateway is bringing the same value of 'simplifying' usage of APIs or components behind it then it could be considered a facade. In other situations, a gateway could be merely a middleware, adapter, wrapper or a call forwarding element of the architecture. Or a gateway could be wearing multiple hats, like simplifying few flows, forwarding some calls while acting as an authentication or authorisation middleware in parallel too. Thus, IMHO gateway is a highly abstract pattern that could encompass one or more specific structural patterns like facade, adapter, wrapper, decorator or middleware etc..

Martin Fowler definition of gateway is narrow in nature (at least the one here) and is closer to API Gateways acting like format decorators.

As far the implementation is concerned, there is no limit on what a gateways could and could not do. It is virtually an application of its own and could deliver any functionality.

Facade used for working with some Object's graph as with single object and Gateway for connecting two different modules/systems.

To answer your question, I would not say that Facade==Gateway, but that Facade≈Gateway. By that I mean that they are approximately equal, how they differ is not apparently clear based upon the differing opinions above.

You need to remember that one of the key components of design patterns and terminology in general is to help more easily communicate your ideas. With that being said if you always speak in terms of a facade you will a greater chance of being understood as that is the term used most frequently.

I tend to think of many of patterns as of special cases of Proxy pattern, and don't worry much which one specifically it is.

I.e:

• Facade is your simple proxy to a bunch of complicated classes.

• Adapter is a proxy to parts of the system with incompatible interfaces as the one we need at the moment

• etc...

Judging from what I've found on a Google search for "gateway pattern" it seems that Gateway == Proxy :D