"Facade" design pattern vs "Facade" from architecture

Question

Does Facade Design Pattern inherits the concept of Facade from architecture? I mean in architecture the term Facade usually represents the front side or the exterior of any building. Does the Facade Design Pattern also serves this kind of purpose in software architecture? If this is true, is the concept also applicable for "Factory Pattern" vs "Factory", "Bridge Pattern" vs "Bridge", "Proxy Pattern" vs "Proxy" and other design patterns ?

Answer 1

In general, yes. The Gang of Four pattern work was inspired by Christopher Alexander.

Christopher Alexander is the architect who first studied patterns in buildings and communities and developed a "pattern language" for generating them.

I find the architectural metaphors parallel the software designs to a significant extent. Of course, no metaphor is perfect, so you could certainly find discrepancies as well. The GoF noted,

Finding good names has been one of the hardest parts of developing our catalog.

Answer 2

Facade Pattern refers to filtering informations or walling large implementations / complex details.

It serves as putting like a curtain or wall over some complex methods or architecture to allow easier access. That's how the Facade Pattern is presented (see the answer here for "What's the Facade Pattern"). You may also, via Facade, hide some methods or functionalities to your classes.

One of the finest examples is the Repository pattern. You may hide all the database logic (DTOs to Business object) behind some walls, since you may, one day, change databases (like SQL to MySql or Oracle, SQL to EntityFramework). It hides things, like a wall, while showing some things, like windows.

For the rest of your list, it is pretty much applicable.

• Factory pattern creates objects from a certain context without exposing the implementation of the instanciation (your class calling the factory doesn't create, the Factory does)
• Bridge pattern help to link abstraction with implementation without dependency (I want to save to multiple databases, but I want one entry point for all the implementations of differents technologies)
• Proxy pattern put a mask in front of objects that you may not want to create now.

So yeah, pretty much all patterns have a real life application to some extent.

Answer 3

More generally you are asking that, "Do design pattern names depict the idea of their internal design in terms of real life entities?

Conceptually the answer is YES. In your examples

• Facade represents a scenario where hiding a set of internal entities/behaviors with a coordinator entity to perform operations.
• Factory represents a scenario where a factory entity produces/manufactures objects for you.
• Bridge represents a scenario how to connect two similar yet distinct(disconnected) entities.
• Adapter represents a scenario how to connect two different distinct entities.

And we should also notice that it also depends on the personal flavor and individual understandings. For an example Interpreter pattern has been introduced by GoF, carries the meaning that it depicts a typical programming language interpreter (or compiler). But generally the term 'Interpreter' means something like a translator, so people can often misunderstand what this pattern means. Because of that some people suggest it is not a good name for that pattern and some name like 'Expression' would be a better alternative.

So one other thing we should learn from the previous point is we should not directly work with our own understandings with what pattern name suggests, because it can be different with what they mean. We should look into their real idea first. i.e. what is the programming solution they suggest.

Ex: Bridge pattern suggests about a bridge. But in terms of programming, it achieves with decoupling the abstraction from ones implementation.