Facade Pattern
A classic structural design pattern in software engineering that provides a simplified interface over a complex subsystem, hiding internal implementation details and reducing coupling between callers and the subsystem. It is particularly applicable in third-party library integration, layered architecture, and legacy system encapsulation.
Timeline (last 90 days)
The Facade Pattern is one of the 23 classic design patterns catalogued by the Gang of Four in their 1994 book "Design Patterns," and belongs to the category of structural patterns.
The core idea of the Facade Pattern is to establish a simplified interface on top of a complex system so that business logic does not have to face the underlying complexity directly.
A facade does not prevent callers from bypassing it and accessing subsystems directly; it provides convenience rather than enforced encapsulation.
The Facade Pattern is not just about simplifying calls; more importantly, it acts as a boundary that decides which information can cross the boundary and enter the application.
If the facade's pay method still returns a Stripe-specific Payment Intent object, the third-party coupling remains.
The improved approach is to define a Payments protocol whose pay method returns a custom PaymentResult object unrelated to Stripe, so that business logic depends only on the protocol and is unaware of the concrete implementation.
When objects from any system spread throughout a codebase, they cause that system to shape your architecture and introduce a large amount of coupling, which applies to scenarios such as weather APIs, graphics engines, ORMs, and AI APIs.
When a facade is implemented correctly, testing is easier because the entire facade can be replaced with a mock object (such as a FakeStripe implementing the same interface).
When implementing a facade, purely pass-through wrappers should be avoided; methods should expose operations with business meaning (such as pay and refund_order) rather than Stripe-specific methods.
When implementing a facade, creating a God Facade should be avoided; it should be split into several cohesive and independent services or classes.
2 more timeline events
All Facts (12)
The Facade Pattern is one of the 23 classic design patterns catalogued by the Gang of Four in their 1994 book "Design Patterns," and belongs to the category of structural patterns.
50%UnverifiedThe core idea of the Facade Pattern is to establish a simplified interface on top of a complex system so that business logic does not have to face the underlying complexity directly.
50%UnverifiedA facade does not prevent callers from bypassing it and accessing subsystems directly; it provides convenience rather than enforced encapsulation.
50%UnverifiedThe Facade Pattern is not just about simplifying calls; more importantly, it acts as a boundary that decides which information can cross the boundary and enter the application.
50%UnverifiedIf the facade's pay method still returns a Stripe-specific Payment Intent object, the third-party coupling remains.
50%UnverifiedThe improved approach is to define a Payments protocol whose pay method returns a custom PaymentResult object unrelated to Stripe, so that business logic depends only on the protocol and is unaware of the concrete implementation.
50%UnverifiedWhen objects from any system spread throughout a codebase, they cause that system to shape your architecture and introduce a large amount of coupling, which applies to scenarios such as weather APIs, graphics engines, ORMs, and AI APIs.
50%UnverifiedWhen a facade is implemented correctly, testing is easier because the entire facade can be replaced with a mock object (such as a FakeStripe implementing the same interface).
50%UnverifiedWhen implementing a facade, purely pass-through wrappers should be avoided; methods should expose operations with business meaning (such as pay and refund_order) rather than Stripe-specific methods.
50%UnverifiedWhen implementing a facade, creating a God Facade should be avoided; it should be split into several cohesive and independent services or classes.
50%UnverifiedWhen implementing a facade, important behaviors that callers genuinely need to know about should not be hidden, such as whether payment is synchronous or whether customer authentication is required.
50%UnverifiedThe goal of an Adapter is to make interfaces compatible, whereas the goal of a Facade is to simplify access to a complex subsystem.
50%