feat: ✨ CA chap 10

zhumeisongsong · Nov 9, 2024 · 1edcef7 · 1edcef7
1 parent 5adfb31
commit 1edcef7
Show file tree

Hide file tree

Showing 13 changed files with 81 additions and 18 deletions.
diff --git a/_posts/2019-12-25-clean-architecture.md b/_posts/2019-12-25-clean-architecture.md
@@ -31,15 +31,15 @@ pin: true
 
 [Design Principles](/blog/posts/clean-architecture-part3)
 
-<!-- [Chap7. SRP: The Single Responsibility Principle]()
+<!-- [Chap7. SRP: The Single Responsibility Principle]() -->
 
-[Chap8. OCP: The Open-Closed Principle]()
+<!-- [Chap8. OCP: The Open-Closed Principle]() -->
 
-[Chap9. LSP: The Liskov Substitution Principle]()
+<!-- [Chap9. LSP: The Liskov Substitution Principle]() -->
 
-[Chap10. ISP: The Interface Segregation Principle]()
+[Chap10. ISP: The Interface Segregation Principle](/blog/posts/clean-architecture-part3-chap10)
 
-[Chap11. DIP: The Dependency Inversion Principle]() -->
+<!-- [Chap11. DIP: The Dependency Inversion Principle]() -->
 
 ### Part 4 Component Principles
 

diff --git a/_posts/clean-architecture-part3-chap10.md b/_posts/clean-architecture-part3-chap10.md
@@ -1,9 +1,51 @@
 ---
-title: "Clean Architecture Part3. Chap10."
+title: "Clean Architecture Part3. Chap10. ISP: the Interface Segregation Principle"
 excerpt: ""
-coverImage: "/blog/assets/hello-world/cover.jpg"
+coverImage: "/blog/assets/clean-architecture-10-cover.jpg"
 date: "2019-06-20"
 ogImage:
-  url: "/blog/assets/hello-world/cover.jpg"
+  url: "/blog/assets/clean-architecture-10-cover.jpg"
 categories: ["clean"]
 ---
+
+![10.1](/blog/assets/clean-architecture/10-isp.png)
+
+In the situation illustrated in Figure 10.1, there are several users who use the operations of the OPS class. Let’s assume that User1 uses only op1, User2 uses only op2, and User3 uses only op3.
+
+Now imagine that OPS is a class written in a language like Java. Clearly, in that case, the source code of User1 will inadvertently depend on op2 and op3, even though it doesn’t call them. This dependence means that a change to the source code of op2 in OPS will force User1 to be recompiled and redeployed, even though nothing that it cared about has actually changed.
+
+This problem can be resolved by segregating the operations into interfaces as shown in Figure 10.2.
+
+![10.2](/blog/assets/clean-architecture/10-isp-2.png)
+
+Again, if we imagine that this is implemented in a statically typed language like Java, then the source code of User1 will depend on U1Ops, and op1, but will not depend on OPS. Thus a change to OPS that User1 does not care about will not cause User1 to be recompiled and redeployed.
+
+## ISP and Language
+
+Clearly, the previously given description depends critically on language type. 
+
+Statically typed languages like Java force programmers to create declarations that users must import, or use, or otherwise include. It is these included declarations in source code that create the source code dependencies that force recompilation and redeployment.
+
+In dynamically typed languages like Ruby and Python, such declarations don’t exist in source code. Instead, they are inferred at runtime. Thus there are no source code dependencies to force recompilation and redeployment. This is the primary reason that dynamically typed languages create systems that are more flexible and less tightly coupled than statically typed languages.
+
+This fact could lead you to conclude that the ISP is a language issue, rather than an architecture issue.
+
+## ISP and Architecture
+
+If you take a step back and look at the root motivations of the ISP, you can see a deeper concern lurking there. In general, it is harmful to depend on modules that contain more than you need. This is obviously true for source code dependencies that can force unnecessary recompilation and redeployment—but it is also true at a much higher, architectural level.
+
+Consider, for example, an architect working on a system, S. He wants to include a certain framework, F, into the system. Now suppose that the authors of F have bound it to a particular database, D. So S depends on F. which depends on D (Figure 10.3).
+
+![10.3](/blog/assets/clean-architecture/10-isp-3.png)
+
+Now suppose that **D contains features that F does not use** and, therefore, that S does not care about. Changes to those features within D may well force the redeployment of F and, therefore, the redeployment of S. Even worse, a failure of one of the features within D may cause failures in F and S.
+
+## Conclusion
+
+Depending on something that carries baggage that **you don’t need** can cause you troubles that you didn’t expect.
+
+We’ll explore this idea in more detail when we discuss the **Common Reuse Principle** in [Chapter 13, "Component Cohesion"](/blog/posts/clean-architecture-part4-chap13).
+
+## References
+
+https://github.com/leewaiho/Clean-Architecture-zh/blob/master/docs/ch10.md
diff --git a/_posts/clean-architecture-part3-chap11.md b/_posts/clean-architecture-part3-chap11.md
@@ -1,5 +1,5 @@
 ---
-title: "Clean Architecture Part3. Chap11."
+title: "Clean Architecture Part3. Chap11. DIP: The Dependency Inversion Principle"
 excerpt: ""
 coverImage: "/blog/assets/hello-world/cover.jpg"
 date: "2019-06-25"

diff --git a/_posts/clean-architecture-part3-chap7.md b/_posts/clean-architecture-part3-chap7.md
@@ -1,5 +1,5 @@
 ---
-title: "Clean Architecture Part3. Chap7."
+title: "Clean Architecture Part3. Chap7. SRP: The Single Responsibility Principle"
 excerpt: ""
 coverImage: "/blog/assets/hello-world/cover.jpg"
 date: "2019-06-05"

diff --git a/_posts/clean-architecture-part3-chap8.md b/_posts/clean-architecture-part3-chap8.md
@@ -1,5 +1,5 @@
 ---
-title: "Clean Architecture Part3. Chap8."
+title: "Clean Architecture Part3. Chap8. OCP: The Open-Closed Principle"
 excerpt: ""
 coverImage: "/blog/assets/hello-world/cover.jpg"
 date: "2019-06-10"

diff --git a/_posts/clean-architecture-part3-chap9.md b/_posts/clean-architecture-part3-chap9.md
@@ -1,5 +1,5 @@
 ---
-title: "Clean Architecture Part3. Chap9."
+title: "Clean Architecture Part3. Chap9. LSP: The Liskov Substitution Principle"
 excerpt: ""
 coverImage: "/blog/assets/hello-world/cover.jpg"
 date: "2019-06-15"

diff --git a/_posts/clean-architecture-part6-chap34.md b/_posts/clean-architecture-part6-chap34.md
@@ -7,3 +7,23 @@ ogImage:
   url: "/blog/assets/hello-world/cover.jpg"
 categories: ["clean"]
 ---
+
+## Package By Layer
+
+## Package By Feature
+
+## Ports and Adapters
+
+## Package By Component
+
+## The Devil Is in the Implementation Details
+
+## Organization Versus Encapsulation
+
+## Other Decoupling Modes
+
+## Conclusion
+
+## References
+
+https://github.com/leewaiho/Clean-Architecture-zh/blob/master/docs/ch34.md
diff --git a/public/assets/clean-architecture-10-cover.jpg b/public/assets/clean-architecture-10-cover.jpg
diff --git a/public/assets/clean-architecture-12-cover.jpg b/public/assets/clean-architecture-12-cover.jpg
diff --git a/public/assets/clean-architecture/10-isp-2.png b/public/assets/clean-architecture/10-isp-2.png
diff --git a/public/assets/clean-architecture/10-isp-3.png b/public/assets/clean-architecture/10-isp-3.png
diff --git a/public/assets/clean-architecture/10-isp.png b/public/assets/clean-architecture/10-isp.png
diff --git a/src/interfaces/categories.ts b/src/interfaces/categories.ts
@@ -1,17 +1,18 @@
 export const defaultCategories = {
+  "system-design": "system-design",
   ddd: "ddd",
+  clean: "clean",
   architecture: "architecture",
-  "system-design": "system-design",
-  git: "git",
-  react: "react",
-  project: "project",
+  solid: "solid",
   basic: "basic",
   typescript: "typescript",
-  "gas-station": "gas-station",
-  solid: "solid",
+  react: "react",
   nextjs: "nextjs",
   "semantic-release": "semantic-release",
+  git: "git",
   oss: "oss",
+  "gas-station": "gas-station",
+  project: "project",
 } as const;
 
 export type Category =