vault backup: 2025-01-17 16:09:15

5 Media/8 Courses/Design Patterns by Construx.md

@@ -234,6 +234,7 @@ Build a wrapper around a complex service to simplify the interface.
 - High cohesion / loose coupling (secondary, decouple the service provider)
 ### Bridge
 **Prerequisite**: Adapter Pattern
+The bridge pattern is very dynamic and can be changed during runtime very quickly (strategy pattern is more static.)
 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.
@@ -257,10 +258,89 @@ Bridge is often inherently an Adapter.
 
 ![[Pasted image 20250117142732.png]]
 ### Strategy
+Forces:
+- behavior needs to change at runtime
+- support different solutions to a particular problem
+- insulate clients from details of the solutions
+- added layer of indirection is acceptable (hit on performance)
+
+![[Pasted image 20250117152338.png]]
+
+
+> [!NOTE] Implementation Note
+> No definition of how nor when "context" gets bound to "concrete strategies"
+> - client decides
+> - broker or agent decides
+> - parameter
+> - dependency injection
+>   
+>   Concrete strategies need identical interface but maybe not the same parameters
+
+Example: sorting algorithms
+different sorting algorithms have different properties. Strategy design pattern can be used to let clients use different sort algorithms
+
+#### Design principles
+- design to invariants / design for change
+- encapsulation
+- liskov substitutability
+- high cohesion / loose coupling
+
+> [!Important] Key Points
+> Strategy defines family of algorithms, encapsulates each one and makes them interchangable
 
 ### Composite
+No prerequisite
+Allows to use recursion: example: make folders inside folders inside folders
 
-### Observer
+#### Forces
+- need to represent hierarchical structures
+- need to treat primitive elements and composites as uniformly as possible
+	- copying, moving, deleting files has same effect as on folder
+	- resizing one shape on drawing has same effect as resizing group of shapes
+What you can do with an individual you should do with a group
+
+![[Pasted image 20250117153232.png]]
+![[Pasted image 20250117153316.png]]
+
+
+> [!NOTE] Implementation Notes
+> - depth first vs breadth-first might be relevant in operations that traverse structure.
+> - ordering of compoonents in composite might be relevant
+> - shallow copy vs deep copy (**implement in contract! Should be crystal clear**)
+> 	- **shallow**: Only immediate object copied, not sub-referenced objects
+> 	- **deep**: copy object and all sub-referenced objects.
+
+#### Design Principles
+- Abstraction
+- Design to invariants/design for change
+- encapsulation
+- liskov substitutability
+- high cohesion / loose coupling
+
+> [!Important] Key Points
+> - hierarchical structure
+> - treat primitive elementss and composites as uniformly as possible
+> 	- copying, moving, deleting 
+> 	- resizing single shape has same effect as resizing multiple grouped shapes
+> - be careful with copy() semantics --> communicate through contract
+
+### Observer aka. Publish-Subscribe
+prerequisites: None
+aka: Implicit Invocation, Publish-Subscribe
+
+Forces:
+- 1-to-many dependency requiring object to notify many other objects when it changes state
+- need to limit direct knowledge the many and the one have of each otehr
+- added layer of indirection is acceptable (performance hit)
+
+![[Pasted image 20250117160123.png]]
+
+
+> [!Note] Implementation Notes
+> - same notification interface for all observers on same subject (even if information needs are different)
+
+
+#### Design Principles
 
 ### Template Method