vault backup: 2025-01-17 10:53:18

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

@@ -130,7 +130,64 @@ a.b() doesn't break the law
 
 ### Design for Invariants, Design for Change
 Product Families: attack different target markets with different value propositions with the same base platform: (pickup truck and suv example. For ford it's the same car (slight difference in build but 95% the same)).
-Core of the software design is made for the invariants, meaning all the things that do not change and are the same throughout the software. An example might be the base driver code and the base I2C/SPI interface, which all the drivers use. Every driver 
+The **core of the software design is made for the invariants**, meaning all the things that do not change and are the same throughout the software. An example might be the base driver code and the base I2C/SPI interface, which all the drivers use. Every driver has different registers that need to be set with different values, but the core structure can be designed to be invariant.
+Design for Change means the same thing: to *separate common from variable functionality*: use templates, inheritance, conditional compilation, frameworks.
+*Hide variation behind abstract interfaces*: Outside sees a routine that moves data from A to B and doesn't care how it is being done. It can be done by ftp, scp, tcp/ip, bluetooth, etc. Design patterns that make abstract interfaces are adapter, bridge, strategy, factory method, abstract factory, template method, iterator, decorator, proxy, etc. The client side code does not need to be changed when the bridge implementation changes.
+*Use delayed-binding strategies*: C does early binding, python does very late binding. Examples: named constants, configuration/preference files, dependency injection/ function pointers, inversion of control, data-driven design (set of data to configure software, e.g xml files or so?), self-configuration (android: different hardware configurations. It pings the hardware upon boot and asks about specifications of the hardware.). A problem is that usually software is developed sequentially: first for customer A, then customer B, etc. Better would be to find out about more about the landscape before starting the development. 
+
+### UML: Association and Multiplicity
+**Association**: represents links between objects
+**Multiplicity**: constraints on number of links
+![[Pasted image 20250117100749.png]]
+
+Multiplicity: 1 to many. If you are a customer must you have at least 1 order? The 
+\*-Notation means that it can also be 0. There are four cases which are noted differently:
+
+| Lower Bound | Upper Bound | UML Notation |
+| ----------- | ----------- | ------------ |
+| 0           | 1           | 0..1         |
+| 0           | Many        | \*           |
+| 1           | 1           | 1            |
+| 1           | Many        | 1..\*        |
+Note that it can also be specific numbers: e.g. 3..7
+#### UML Notation: Composition and Aggregation
+Composition: exclusive membership: ♦
+Aggregation: non-exclusive membership: ♢
+When using composition and aggregation, be specific about the multiplicity.
+Diamonds are trendy and are often misused: you can specify multiplicity to represent the exact same thing as composition and aggregation.
+
+### UML: Sequence Diagram
+Describes interactions between objects (dynamics). 
+Primary Concepts: Objects, lifeline, activation context, message
+Naming: objectName:class, objectName, :class
+
+![[Pasted image 20250117102354.png]]
+ ---- is the lifeline
+ time goes from top to bottom
+ opt: optional
+ \[too cold] is a condition
+
+
+### UML: Inheritance and Abstraction
+An arrow pointing to the base class is done by Inheritance
+![[Pasted image 20250117102805.png]]
+
+An abstract class is a base class, which itself cannot create any objects, have any instances. It just creates an interface. If shape was abstract you could only create rectangles and circles, but no other shapes. Abstract methods within abstract classes need to be implemented
+
+### Design Principle: Liskov Substitutability
+
+T (superclass) <-- S (subclass)
+Goal: objects of class T may be replaced with objects of class S without altering any desirable properties of that program (e.g. correctness)
+- preconditions in subclass S as strict or less strict than in superclass T
+- postconditions in subclass S as strict or less strict than in superclass T
+- No new exceptions should be introduced in subclass S
+--> A subclass S must require no more and promise no less than its superclass T
+
+Example:
+
+
+
+
 
 ---
 ## Exercises