vault backup: 2025-01-17 14:08:14
This commit is contained in:
@@ -218,9 +218,22 @@ Patterns are not mutually exclusive and can be used on top of each other.
|
|||||||
> - portability across multiple providers
|
> - portability across multiple providers
|
||||||
> - two versions: object vs class adapter
|
> - two versions: object vs class adapter
|
||||||
|
|
||||||
### Façade
|
Interesting application:
|
||||||
|
In testing you might want to test hidden / private functions. So you can create a inherited object lets call it test-object, where those functions are exposed. So the test-object is basically an adapter.
|
||||||
|
### Façade (also called Wrapper)
|
||||||
|
Build a wrapper around a complex service to simplify the interface.
|
||||||
|
- Depending on the language you might not be able to preventing the client to go around the facade.
|
||||||
|
- An adapter can be a wrapper. It all depends on your intent:
|
||||||
|
If your intent is syntax adapting it is an adapter.
|
||||||
|
If your intent is hiding complexity it is a wrapper.
|
||||||
|
It can be both at the same time if your intent is to do both at the same time
|
||||||
|
|
||||||
|
#### Design principles
|
||||||
|
- Encapsulation
|
||||||
|
- Abstraction (hide details that are not needed)
|
||||||
|
- High cohesion / loose coupling (secondary, decouple the service provider)
|
||||||
### Bridge
|
### Bridge
|
||||||
|
**Prerequisite**: Adapter Pattern
|
||||||
|
|
||||||
### Strategy
|
### Strategy
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user