vault backup: 2025-01-17 15:08:14
This commit is contained in:
@@ -234,7 +234,28 @@ Build a wrapper around a complex service to simplify the interface.
|
||||
- High cohesion / loose coupling (secondary, decouple the service provider)
|
||||
### Bridge
|
||||
**Prerequisite**: Adapter Pattern
|
||||
Remember the fundamental design pattern of favouring association over inheritance. In a CNC-milling machine example we have 60 different subclasses of a programStep, which all cut different cuts. If I want to add a new communication protocol to communicate with the machine (tcp instead of serial) I would have to add another layer which adds another 60 subclasses, and so forth. This would be really bad and this is where the bridge pattern thrives:
|
||||
|
||||
Goal force: decouple abstraction from implementation so that the two can vary independently. There are variations on two dimensions: the type of cut, the type of communication.
|
||||
Constraint force: layer of indirection: slight performance hit
|
||||
|
||||
**Abstraction and Implementation can vary independently!**
|
||||
|
||||
![[Pasted image 20250117141550.png]]
|
||||
|
||||
Bridge is often inherently an Adapter.
|
||||
|
||||
> [!NOTE] No definition of how "abstractions" get bound to "implementors"
|
||||
> - statically at "abstraction" instantiation
|
||||
> - dynamically as parameter or dependency injection?
|
||||
|
||||
#### Design principles
|
||||
- favor association over inheritance
|
||||
- high coehision/ loose coupling
|
||||
- design to invariants / design for change
|
||||
- liskov substitutability
|
||||
|
||||
![[Pasted image 20250117142732.png]]
|
||||
### Strategy
|
||||
|
||||
### Composite
|
||||
|
||||
Reference in New Issue
Block a user