Skip to content

Commit 7af948e

Browse files
authored
Adding design principles overview to additional resources (#179)
1 parent 76ae5bd commit 7af948e

File tree

2 files changed

+70
-0
lines changed

2 files changed

+70
-0
lines changed

SUMMARY.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,3 +42,5 @@
4242
- [Functional Programming](./functional/index.md)
4343

4444
- [Additional Resources](./additional_resources.md)
45+
46+
- [Design principles](./design-principles.md)

design-principles.md

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
# Design principles
2+
3+
## A brief overview over common design principles
4+
5+
---
6+
7+
## [SOLID](https://en.wikipedia.org/wiki/SOLID)
8+
9+
- [Single Responsibility Principle (SRP)](https://en.wikipedia.org/wiki/Single-responsibility_principle):
10+
A class should only have a single responsibility, that is, only changes to one part of the software's
11+
specification should be able to affect the specification of the class.
12+
- [Open/Closed Principle (OCP)](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle):
13+
"Software entities ... should be open for extension, but closed for modification."
14+
- [Liscov Substitution Principle (LSP)](https://en.wikipedia.org/wiki/Liskov_substitution_principle):
15+
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness
16+
of that program."
17+
- [Interface Segregation Principle (ISP)](https://en.wikipedia.org/wiki/Interface_segregation_principle):
18+
"Many client-specific interfaces are better than one general-purpose interface."
19+
- [Dependency Inversion Principle (DIP)](https://en.wikipedia.org/wiki/Dependency_inversion_principle):
20+
One should "depend upon abstractions, [not] concretions."
21+
22+
## [DRY (Don’t Repeat Yourself)](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
23+
24+
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"
25+
26+
## [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
27+
28+
most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided
29+
30+
## [Law of Demeter (LoD)](https://en.wikipedia.org/wiki/Law_of_Demeter)
31+
32+
a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of "information hiding"
33+
34+
## [Design by contract (DbC)](https://en.wikipedia.org/wiki/Design_by_contract)
35+
36+
software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants
37+
38+
## [Encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming))
39+
40+
bundling of data with the methods that operate on that data, or the restricting of direct access to some of an object's components. Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them.
41+
42+
## [Command-Query-Separation(CQS)](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation)
43+
44+
“Functions should not produce abstract side effects...only commands (procedures) will be permitted to produce side effects.” - Bertrand Meyer: Object Oriented Software Construction
45+
46+
## [Principle of least astonishment (POLA)](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)
47+
48+
a component of a system should behave in a way that most users will expect it to behave. The behavior should not astonish or surprise users
49+
50+
## Linguistic-Modular-Units
51+
52+
“Modules must correspond to syntactic units in the language used.” - Bertrand Meyer: Object Oriented Software Construction
53+
54+
## Self-Documentation
55+
56+
“The designer of a module should strive to make all information about the module part of the module itself.” - Bertrand Meyer: Object Oriented Software Construction
57+
58+
## Uniform-Access
59+
60+
“All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.” - Bertrand Meyer: Object Oriented Software Construction
61+
62+
## Single-Choice
63+
64+
“Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.” - Bertrand Meyer: Object Oriented Software Construction
65+
66+
## Persistence-Closure
67+
68+
“Whenever a storage mechanism stores an object, it must store with it the dependents of that object. Whenever a retrieval mechanism retrieves a previously stored object, it must also retrieve any dependent of that object that has not yet been retrieved.” - Bertrand Meyer: Object Oriented Software Construction

0 commit comments

Comments
 (0)