99 lines
3.1 KiB
Markdown
99 lines
3.1 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 i
|
||
|
||
|
||
|
||
|
||
---
|
||
## Exercises
|
||
|
||
---
|
||
```query
|
||
Design Patterns Construx
|
||
-file: "Design Patterns by Construx.md"
|
||
```
|