add grasp principles

.obsidian/workspace.json

@@ -4,16 +4,16 @@
     "type": "split",
     "children": [
       {
-        "id": "697f5d4ef0274c85",
+        "id": "7b73df235fbf3cf0",
         "type": "tabs",
         "children": [
           {
-            "id": "9efbade930908c16",
+            "id": "4944064c3fbbcafb",
             "type": "leaf",
             "state": {
               "type": "markdown",
               "state": {
-                "file": "Readme.md",
+                "file": "arch-grasp-high-cohesion.md",
                 "mode": "source",
                 "source": false
               }
@@ -93,7 +93,7 @@
             "state": {
               "type": "backlink",
               "state": {
-                "file": "Readme.md",
+                "file": "arch-grasp-high-cohesion.md",
                 "collapseAll": false,
                 "extraContext": false,
                 "sortOrder": "alphabetical",
@@ -110,7 +110,7 @@
             "state": {
               "type": "outgoing-link",
               "state": {
-                "file": "Readme.md",
+                "file": "arch-grasp-high-cohesion.md",
                 "linksCollapsed": false,
                 "unlinkedCollapsed": true
               }
@@ -133,15 +133,16 @@
             "state": {
               "type": "outline",
               "state": {
-                "file": "Readme.md"
+                "file": "arch-grasp-high-cohesion.md"
               }
             }
           }
         ]
       }
     ],
     "direction": "horizontal",
-    "width": 300
+    "width": 300,
+    "collapsed": true
   },
   "left-ribbon": {
     "hiddenItems": {
@@ -153,34 +154,34 @@
       "command-palette:Open command palette": false
     }
   },
-  "active": "9efbade930908c16",
+  "active": "4944064c3fbbcafb",
   "lastOpenFiles": [
+    "arch-grasp-low-coupling.md",
+    "arch-grasp.md",
+    "arch-solid.md",
+    "arch-solid-dependency-inversion-principle.md",
+    "arch-solid-interface-segregation-principle.md",
+    "arch-solid-liskov-substitution-principle.md",
+    "arch-solid-open-closed-principle.md",
+    "arch-solid-single-responsibility-principle.md",
+    "arch-grasp-protected-variations.md",
+    "arch-grasp-polymorphism.md",
+    "arch-grasp-information-expert.md",
+    "arch-grasp-indirection.md",
+    "arch-grasp-high-cohesion.md",
+    "arch-grasp-creator.md",
+    "arch-grasp-controller.md",
+    "arch-grasp-pure-fabrication.md",
+    "Readme.md",
     "tls-termination.md",
     "TBD.md",
     "tls.md",
     "http-request.md",
     "http-header-hsts.md",
     "Bibliography.md",
-    "arch-solid.md",
-    "arch-single-responsibility-principle.md",
-    "arch-open-closed-principle.md",
-    "arch-liskov-substitution-principle.md",
-    "arch-interface-segregation-principle.md",
-    "arch-dependency-inversion-principle.md",
-    "arch-grasp.md",
     "node-js-non-blocking.md",
     "nodejs-import-internal-node-modules-arrangement.md",
     "ts-types-vs-interfaces.md",
-    "Readme.md",
-    "[arch-liskov-substitution.md",
-    "ts-turn-modules-into-types.md",
-    "ts-structural-type-system.md",
-    "ts-nominal-type-system.md",
-    "ts-dot-ts-files.md",
-    "ts-const-assertion.md",
-    "ts-assertion-function.md",
-    "nodejs-top-level-await.md",
-    "nodejs-callback-hell-does-not-exist.md",
     "Untitled.canvas"
   ]
 }

arch-grasp-controller.md

@@ -0,0 +1,5 @@
+---
+tags:
+  - architecture
+  - grasp
+---

arch-grasp-creator.md

@@ -0,0 +1,5 @@
+---
+tags:
+  - architecture
+  - grasp
+---

arch-grasp-high-cohesion.md

@@ -0,0 +1,6 @@
+---
+tags:
+  - architecture
+  - grasp
+---
+High Cohesion is a software design principle that emphasizes organizing and structuring code in a way that closely related functions and data are grouped together within a module or class

arch-grasp-indirection.md

@@ -0,0 +1,5 @@
+---
+tags:
+  - architecture
+  - grasp
+---

arch-grasp-information-expert.md

@@ -0,0 +1,46 @@
+---
+tags:
+  - architecture
+  - grasp
+---
+A class that has all the required information to perform a task (make a decision) should be assigned to do it. In general, this means that all the internal logic of a functionality should be controlled by the 'nearest' class to which its functionality belongs.
+# Example
+```js
+class Product {
+	constructor(name, productPrice) {
+		this.name = name;
+		this.productPrice = productPrice;
+	}
+	// this class knows everything about products. Therefore this class is an information expert to calculate its price.
+	get price() {
+		return this.productPrice;
+	}
+}
+
+class Purchase {
+	constructor(name, ...collection) {
+		this.name = name;
+		this.collection = collection;
+	}
+	// this class knows everything about purchases. Therefore this class is an information expert to calculate its price.
+	get price() {
+		return this.collection.reduce((sum, entity) => {
+			// class Purchase doesn't need to know how to calculate price of each individual entity. It's up to these entities. He only knows that price of any entity is available by a public field price. These entities in their turn are information experts to calculate their price
+			return sum += entity.price;
+		}, 0);
+	}
+}
+
+const product1 = new Product('Laptop', 2000);
+const product2 = new Product('Mouse', 40);
+const purchase1 = new Purchase('Work kit', product1, product2);
+
+const product3 = new Product('Book', 100);
+const product4 = new Product('iPhone', 1000);
+
+const total = new Purchase('All together', purchase1, product3, product4);
+
+// Now it's easy to calculate total price
+console.log(total.price);
+```
+

arch-grasp-low-coupling.md

@@ -0,0 +1,8 @@
+---
+tags:
+  - architecture
+  - grasp
+---
+modules/classes/functions should know about the properties of other modules/classes/functions only as much as they need to. The less they know, the more readable your code becomes, and it becomes easier to extend and modify. This principle also relates to defining architecture boundaries.
+
+The middleware concept is a good example of a violation of this principle. Each middleware can modify the HTTP `request`/`response`. Often, middlewares should be executed in a specific order because one middleware can add a new field to the `request` object while another one relies on the existence of this field.

arch-grasp-polymorphism.md

@@ -0,0 +1,5 @@
+---
+tags:
+  - architecture
+  - grasp
+---

arch-grasp-protected-variations.md

@@ -0,0 +1,5 @@
+---
+tags:
+  - architecture
+  - grasp
+---

arch-grasp-pure-fabrication.md

@@ -0,0 +1,8 @@
+---
+tags:
+  - architecture
+  - grasp
+---
+Pure fabrication refers to entities that do not exist in the business domain but are abstractions within the program. These abstractions can be system-level constructs that are easy to reuse. Such abstractions help reduce the amount of system-specific code within the business domain.
+## Examples
+Promise, Socket, Connection, Proxy, Request, Response, Server, Stream, Queue, Transaction, etc

arch-grasp.md

@@ -0,0 +1,29 @@
+---
+tags:
+  - architecture
+  - grasp
+---
+GRASP - General responsibility assignment software patterns
+
+> [!INFO]
+> First was proposed by Craig Larman in his book "Applying UML and Patterns"
+
+## Principles
+- [[arch-grasp-low-coupling|Low Coupling]]
+- [[arch-grasp-information-expert|Information Expert]]
+- [[arch-grasp-controller|Controller]]
+- [[arch-grasp-pure-fabrication|Pure Fabrication]]
+- [[arch-grasp-protected-variations|Protected Variations]]
+- [[arch-grasp-high-cohesion|High Cohesion]]
+- [[arch-grasp-creator|Creator]]
+- [[arch-grasp-polymorphism|Polymorphism]]
+- [[arch-grasp-indirection|Indirection]]
+
+### Creator
+Problem: Who should create instance(who should hold and destroy link)
+
+Solution: Who contains or aggregate instances, who use them heavily, who has all the information for initialization.
+
+Why: to low coupling
+
+Examples: constructor, factory, pool

arch-solid.md

@@ -4,8 +4,8 @@ tags:
   - solid
 ---
 SOLID stands for 5 principles:
-- S - [[arch-single-responsibility-principle|Single Responsibility Principle]]
-- O - [[arch-open-closed-principle|Open/Close Principle]]
-- L - [[arch-liskov-substitution-principle|Liskov's Substitution Principle]]
-- I - [[arch-interface-segregation-principle|Interface Segregation Principle]]
-- D - [[arch-dependency-inversion-principle|Dependency Inversion Principle]]
+- S - [[arch-solid-single-responsibility-principle|Single Responsibility Principle]]
+- O - [[arch-solid-open-closed-principle|Open/Close Principle]]
+- L - [[arch-solid-liskov-substitution-principle|Liskov's Substitution Principle]]
+- I - [[arch-solid-interface-segregation-principle|Interface Segregation Principle]]
+- D - [[arch-solid-dependency-inversion-principle|Dependency Inversion Principle]]