143 lines
6.5 KiB
Markdown
143 lines
6.5 KiB
Markdown
---
|
||
title: Design Patterns by Construx
|
||
created_date: 2025-01-16
|
||
updated_date: 2025-01-16
|
||
aliases:
|
||
tags:
|
||
- course
|
||
type: course
|
||
course_name: Design Patterns
|
||
author: Construx
|
||
source: https://construx.vueocity.com/portal/design-patterns
|
||
status: not_started
|
||
---
|
||
# Design Patterns by Construx
|
||
- **🏷️Tags** : #01-2025 #book
|
||
---
|
||
## Summary
|
||
|
||
> [!summary] Summary
|
||
> 3 Sentences only!
|
||
> - What are the main ideas?
|
||
> - If I implemented one idea from this book right now, which one would it be?
|
||
> - How would I describe the course to someone else?
|
||
|
||
---
|
||
## Ideas and Thoughts
|
||
|
||
> [!info]+ Inspiring Questions
|
||
> - Did you think about other concepts from other resources?
|
||
> - Do the concepts fit to your past, to your memories?
|
||
> - Can you relive them and reflect them from a different angle?
|
||
|
||
|
||
---
|
||
## Chapters
|
||
### Getting Started
|
||
|
||
> [!definition] UML Notation
|
||
> Contents
|
||
|
||
> [!Definition] What is a Design Pattern
|
||
> A standard solution to a recurring problem.
|
||
>
|
||
> We should not reinvent the wheel. Patterns are much more reusable than code.
|
||
|
||
A *bridge* is a design pattern because it is a standard solution to a recurring problem: we need to get things across a not passable obstacle.
|
||
For every problem you have *design criteria* to choose the best type of bridge (e.g. span, clearance, loads, cost, etc.). In design patterns design criteria are called *Goal forces* and *constraint forces*.
|
||
As a beginner: focus on the problem, not the solutions!
|
||
|
||
### UML Notations:
|
||
#### Note
|
||
![[Pasted image 20250116161217.png]]
|
||
#### Class, Attribute and Operation
|
||
![[Pasted image 20250116160836.png]]
|
||
|
||
Operations are viewed from extern
|
||
Methods are viewed from intern
|
||
|
||
### Minimize Overall Complexity
|
||
Measures of complexity
|
||
- Cyclomatic complexity: the number of decisions that are being made --> local complexity
|
||
- Depth of decision making: embedding of decision within decision and decision --> local complexity
|
||
- number of parameters: --> global complexity
|
||
- fan out: number of functions that are called by the function --> global complexity
|
||
|
||
![[Pasted image 20250116161534.png]]
|
||
|
||
Local complexity is a measure on how complicated each function is, whereas the global complexity is the complexity in between functions.
|
||
Remember to get an appropriate balance.
|
||
|
||
### Use Abstractions
|
||
**Syntax**: Is all about structure
|
||
**Semantics**: Is all about meaning
|
||
|
||
- Colorless green dreams sleep furiously: correct syntax, completely wrong semantics --> defective or buggy code, because it is semantically meaningless
|
||
|
||
The *compiler* is a master of syntax but cannot know anything about semantics.
|
||
The programmer needs to focus much more on semantics, because the complier will take care of the syntax.
|
||
|
||
> [!NOTE] Abstraction
|
||
> the principle of ignoring those aspects of a subject that are not relevant to the current purpose in order to concentrate solely on those that are.
|
||
>
|
||
> It is a tool to reduce and manage complexity.
|
||
|
||
what is the role of one function / subroutine? The more abstraction you have, the less performant the code becomes.
|
||
Abstraction is not learnable. Good abstractions lead to clean code, which is maintainable and leads to less defects.
|
||
|
||
### Encapsulate Design Decisions
|
||
Abstraction: permission to ignore
|
||
Encapsulation: I prevent you from knowing
|
||
Meaning they are not the same thing.
|
||
|
||
Goal:
|
||
- **hide design decision** (data representation, algorithms, etc.)
|
||
- **Modules should be black boxes**: programm to an interface, not through an interface
|
||
|
||
Idea: Design by Contract
|
||
Requires vs Guarantees
|
||
A function promises to give certain outputs depending on the inputs
|
||
This is important for documentation of code if the code is used by different people. Docstrings for example.
|
||
We only worry about semantic things. Explain exactly what the input values should be and what the return values will be. Explain exactly what errors and exceptions. Include Constraints on state (function may open file), include performance limits (use no more than 200 bytes per instance, etc).
|
||
Defensive contract: requires less and guarantees more (check input for example).
|
||
Contracts are great, because you can treat the function as a blackbox. When you modify the contract you need to inform all the users of the function about the updates of the contract
|
||
|
||
**Desing by Contract is the means to encapsulation**
|
||
Use: **Purpose, Requires and Guarantees**
|
||
|
||
### Maximize Cohesion, Minimize Coupling
|
||
**Cohesion**: Indivisibility of a given part: Does this function do exactly one thing? It should also not split functionality into two separate functions
|
||
**Coupling**: Dependence between parts: Do not connect things that don't need to be connected. If you must connect things, connect them such that they can be disconnected as easily as possible.
|
||
|
||
Goal: Highly cohesive, very loosely coupled
|
||
|
||
Generally software solves problems by *Decomposition, solution, recomposition*. There are an infinite amount of different solutions, which have different quality. Cohesion and Coupling characterise the quality of the solution.
|
||
|
||
![[Pasted image 20250116171230.png]]
|
||
|
||
Always try to Decouple code:
|
||
|
||
| **Avoid** | **Do** |
|
||
| ----------------------------------- | -------------------------------------------------------------------------------------------------------- |
|
||
| Global variables (form of coupling) | Design by Contract |
|
||
| Friend (C++) | Dependency inversion: if you depend on things, depend on the most generic thing (type of car, not model) |
|
||
| Self-modifying code | Publish-subscribe (observer pattern) |
|
||
| Reflection | Law of Demeter |
|
||
#### Law of Demeter
|
||
Principle of least knowledge.
|
||
a.b().c() breaks the law --> violates coupling
|
||
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
|
||
|
||
---
|
||
## Exercises
|
||
|
||
---
|
||
```query
|
||
Design Patterns Construx
|
||
-file: "Design Patterns by Construx.md"
|
||
```
|