The classic Facade pattern simplifies a subsystem, while Laravel facades provide static-style access to container services.
Two meanings of facade
The word facade causes confusion in Laravel projects. The classic Facade design pattern is a structural pattern that provides a simplified interface to a complex subsystem. Laravel facades are static-looking proxies to services resolved from the container. They are useful, but they are not exactly the same concept.
Classic Facade pattern
A classic facade might expose a simple publishProfile method while internally coordinating validation, image processing, storage, cache clearing, and notifications. The caller gets a clean entry point. The subsystem can remain complex internally, but the facade controls how outside code interacts with it.
Laravel facades
Laravel facades such as Cache, Storage, and Queue provide convenient access to services. They read like static calls, but the framework resolves underlying instances from the container. This makes them testable through Laravel helpers. They are practical at framework edges, but overuse inside domain logic can hide dependencies.
When a facade helps
A facade helps when a subsystem has many moving parts and most callers need a simple use case. For example, a ContentPublishingFacade could coordinate a publishing pipeline. The facade should offer high-level operations, not expose every internal detail. If the facade grows too broad, split it by use case.
When dependency injection is clearer
For core application services, constructor injection often communicates dependencies better than repeated facade calls. A service that depends on a notifier and repository should say so in its constructor. This improves tests and makes coupling visible. Laravel facades remain useful for infrastructure and simple framework services.
Testing considerations
Classic facades can be tested as orchestration units, while collaborators are faked or mocked. Laravel facades can be faked with framework tools, but tests may become less explicit if too many facades are used. The design question is whether the dependency should be part of the class contract.
Practical rule
Use Laravel facades when they improve readability at the framework boundary. Use the classic Facade pattern when you need to simplify a subsystem for callers. Use dependency injection when collaborators are important to the behavior of a class.
Internal reading path
This article is part of a connected OOP and design patterns series. Continue with these related guides:
- Adapter Pattern in PHP: Wrapping Third-Party Services Safely
- Service Layer in Laravel: Keeping Controllers Thin and Workflows Clear
- Dependency Injection in Laravel: Writing Flexible Services
Practical checklist
- Name the responsibility before choosing a pattern.
- Prefer small contracts where behavior varies or external services are involved.
- Keep controllers at the edge and move workflows into named application code.
- Add tests around the behavior that is most likely to change.
- Use patterns to reduce coupling, not to make simple code look advanced.