feat(再看设计原则): update all articles

Author: yyc-git

doc/TODO.org

@@ -329,14 +329,14 @@ finish TODO
 
 
 
-* TODO 完成再看设计原则
+* DONE 完成再看设计原则
 每个设计原则给两个函数式编程的案例
 
 
 ** DONE draft
 
 
-** TODO update
+** DONE update
 
 
 

packages/再看设计原则/article.md

@@ -1,3 +1,3 @@
 案例代码均使用函数式编程
 
-每个设计原则给两个函数式编程的案例
+<!-- 每个设计原则给两个函数式编程的案例 -->

packages/再看设计原则/依赖倒置原则/article.md

@@ -8,23 +8,22 @@
 # 补充说明
 
 <!-- 如何分辨高层模块、低层模块？ -->
-所谓的高层、低层模块是按照依赖的方向来定的，如模块1依赖模块2，则我们说模块1属于高层模块，模块2属于低层模块
+所谓的高层、低层模块是按照依赖的方向来定的，如模块1依赖模块2，我们就说相对而言，模块1属于高层模块，模块2属于低层模块
 
 
-<!-- 在代码中，抽象、细节在代码中指的是什么？ -->
-模块间应该抽象依赖于抽象
-实现模块之间不应该发生直接的依赖关系，其依赖关系应该是通过接口产生的； 
-接口不依赖于实现模块； 
-实现模块依赖接口
+“抽象”在函数式编程的代码中指的就是接口或者类型
+“细节”在函数式编程的代码中指的就是模块或者函数
 
-所以说，符合依赖倒置原则的编程可以看作是“面向接口编程”
+依赖倒置原则具体是指模块或者函数之间不应该直接依赖，而应该是依赖于它们的接口或者类型
+
+所以说，符合依赖倒置原则的编程可以看作是“面向接口/类型编程”
 
 
 符合依赖倒置原则有下面的好处：
-- 减少模块之间的耦合性
+- 减少细节之间的耦合性
 - 便于替换细节
 - 提高系统的稳定性
-- 降低并行开发引起的风险
+- 降低并行开发细节时引起的风险
 - 提高代码的可读性和可维护性
 
 
@@ -34,7 +33,7 @@
 TODO tu
 上图是读者阅读技术书的领域模型
 
-相关伪代码如下：
+伪代码如下：
 TechnicalBook
 ```ts
 type technicalBook = {
@@ -60,11 +59,11 @@ Client
 Reader.read(TechnicalBook)
 ```
 
-如果增加小说书，读者既可以阅读技术书又可以阅读小说书，具体由Client决定让读者阅读哪本书
+如果增加小说书，让读者既可以阅读技术书又可以阅读小说书，这具体是由Client决定读者阅读哪类书
 修改后的领域模型如下：
 TODO tu
 
-修改后的相关伪代码如下：
+修改后的伪代码如下：
 TechnicalBook代码不变
 
 NovelBook
@@ -103,16 +102,16 @@ Client
 Reader.read(TechnicalBook, NovelBook, "novel")
 ```
 
-我们可以看到，每增加一本书，Reader都会受影响
-我们将其改为符合依赖倒置原则，从而使Reader不受影响
+因为Reader依赖了每类书，所以每增加一类书，Reader都需要对应修改代码
+我们将其改为符合依赖倒置原则，解除Reader与每类书的依赖
 修改后的领域模型如下：
 TODO tu
 
-现在Reader改为依赖Book这个接口，而不再依赖它的具体实现模块了
+现在提出了书的接口Book，让Reader改为依赖接口，而不依赖它的实现模块
 这样做的好处是只要Book这个接口不变，它的实现模块的变化不会影响到Reader
 
 
-修改后的相关伪代码如下：
+修改后的伪代码如下：
 Book
 ```ts
 export interface Book {
@@ -147,12 +146,4 @@ Client
 ```ts
 //选择让读者读小说书
 Reader.read(NovelBook)
-```
-
-<!-- 
-
-
-
-
-
-# 案例2 -->
+```

packages/再看设计原则/单一职责原则/article.md

@@ -1,10 +1,6 @@
 # 定义
 
-只有一个原因引起变化；
-一次只做一件事情
-
-<!-- # 解释定义 -->
-
+只有一个原因引起变化，或者说一次只做一件事情
 
 
 # 补充说明
@@ -14,24 +10,24 @@
 从函数名上就能看出该函数是否符合单一职责原则，如getAndSetData这个函数名一看就知道做了两件事情，所以应该将其拆分为getData、setData这两个函数
 
 
-如果一个函数做了多件事情，有下面的缺点：
+如果一个模块或者函数做了多件事情，有下面的缺点：
 
-- 任何一件事情的变化都会影响该函数
-- 用户调用该函数时，本能只预期它做某件事情，结果它实际上还做了其它的事情，这可能造成bug
+- 任何一件事情的变化都会影响它
+- 用户调用它时，本来只预期它做某件事情，结果它实际上还做了其它的事情，这可能造成不可预料的bug
 
 
 # 案例1
 
 TODO tu
-上图是操作书的接口，它不符合单一职责原则。
-这是因为它的getBookID、setBookID是书的数据的操作，而它的addBook是书的行为的操作
+上图是操作书的接口，它不符合单一职责原则
+这是因为它的getBookID、setBookID函数是对书的数据的操作，而它的addBook函数则是对书的行为的操作
 
 应该将其拆分为两个接口，拆分后的接口如下图所示：
 TODO tu
 
-BookData负责书的数据
-BookAction负责书的行为
-BookInfo实现BookData和BookAction
+BookData负责操作书的数据
+BookAction负责操作书的行为
+原来的BookInfo改为实现BookData和BookAction
 
 
 # 案例2
@@ -45,11 +41,10 @@ type phone = number
 
 type changeUser = (newUserData: [userName, phone]) => void
 ```
-上面是一个函数的签名
-从签名可知，该函数不符合单一职责原则
-这是因为它的形参是一个数组，它包含了多个修改用户的的值，这说明该函数做了多件事情
+上面代码是一个函数的签名
+从签名可知，该函数不符合单一职责原则，这是因为它的形参是一个元组，包含了多个新的用户值，这说明该函数做了多件事情
 
-应该将其拆分为多个函数，拆分后的函数如下所示：
+应该将其拆分为多个函数，拆分后的函数签名如下所示：
 ```ts
 type userName = string
 

packages/再看设计原则/合成复用原则/article.md

@@ -5,49 +5,51 @@
 # 补充说明
 
 “继承”属于面向对象编程，函数式编程中没有“继承”的概念
-但是，函数式编程其实也可以实现“继承”，只是把“类”换成“模块”，如Rescript支持在一个模块B中引入另一个模块A，使得B获得了A的所有成员，这相当于B继承了A
+但是，函数式编程其实也可以实现“继承”，只需要把“类”换成“模块”即可。
+如Rescript作为一个函数式编程语言，支持在一个模块B中引入另一个模块A，使B获得A所有的成员，这就相当于实现了B继承A
 
 相关代码如下：
 ```res
 module A = {
   let value1 = "A1"
 
   let func1 = () => {
+    //返回1
     1
   }
 }
 
 module B = {
-  //引入A
+  //引入A，获得了A.value1, A.func1
   include A
 
   //覆盖了A.value1
   let value1 = "B1"
 
   let func2 = () => {
-    //调用A.func1
+    //调用A.func1并返回
     func1()
   }
 }
 ```
 
-所以说合成复用原则也适用于函数式编程
+所以说合成复用原则也适合函数式编程
 
-继承的领域模型如下：
+继承在函数式编程中的领域模型如下：
 TODO tu
 
 我们来看下继承的优缺点：
 继承的优点：
 - 实现新的子模块比较容易，因为子模块可以直接通过继承获得父模块的成员
-- 可以在父模块的基础上扩展子模块
+<!-- - 可以在父模块的基础上扩展子模块 -->
 
 继承的缺点：
 
 - 继承破坏了封装，父模块的细节完全暴露给子模块，父模块的任何细节发生了改变都会影响到子模块
 - 继承是静态的，在运行时不能改变继承关系
 
 
-组合的领域模型如下：
+组合在函数式编程中的领域模型如下：
 TODO tu
 
 我们来看下组合的优缺点：
@@ -74,5 +76,5 @@ TODO tu
 因此，我们将它们由继承关系改为组合关系，修改后的领域模型如下：
 TODO tu
 
-现在，一个人可以通过组合不同的角色，来拥有多个角色
+现在，一个人可以通过组合不同的角色，来拥有多个角色，所以人与角色是“Has-A”的关系
 

packages/再看设计原则/开闭原则/article.md

@@ -5,27 +5,26 @@
 
 # 补充说明
 
-一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化
+系统应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化
 
 
-<!-- # 做项目的时候哪些地方违反了开闭原则？ -->
+<!-- # 项目中哪些地方违反了开闭原则？ -->
+在项目中，如果我们为了增加第三方库的功能而直接修改第三方库的代码，那么这就违反了开闭原则，因为这是通过修改了已有代码来实现变化
 
-具体来说，如果我们为了增加第三方库的功能而直接修改第三方库的代码，那么这就违反了开闭原则
 
-**为什么违反**
-这是通过修改了已有代码来实现变化
+<!-- **造成什么问题** -->
+这会造成下面的问题：
+升级第三方库的版本时，会导致原有的修改失效，从而不得不再修改一遍
 
-**造成什么问题**
-升级第三方库的版本时，会导致原有的修改失效，从而不得不再次修改一遍
 
-
-**如何改进**
-
-有很多改进的方法，其中一个方法就是使用设计模式中的“中间者模式”，增加一个模块A来封装第三方库，让用户改为调用模块A而不是直接调用第三方库。
-这样在需要增加第三方库的功能时，则只增加一个模块B，使其继承模块A，然后在模块B中加入增加的功能代码，让用户改为调用模块B
+<!-- **如何改进** -->
+有很多改进的方法，其中一个方法就是使用设计模式中的“中间者模式”，增加一个模块A来封装第三方库，让用户改为调用模块A而不是直接调用第三方库
+这样在需要增加第三方库的功能时，只需增加一个模块B，使其继承模块A，然后在模块B中加入增加的功能代码，并让用户改为调用模块B
 
 这样做的话就通过扩展而不是修改来实现了变化，从而符合开闭原则
 
+值得注意的是：因为开闭原则允许修改用户的代码，所以这里允许用户改为调用模块B
+
 
 # 案例1
 
@@ -46,21 +45,20 @@ TODO tu
 
 上面三种实现思路都违反了开闭原则，因为它们都是通过修改Cloth的相关代码来实现变化
 
-我们可以增加一个继承TShirt的子模块：OffTShirt，在其中增加getOffPrice函数
+我们可以增加一个继承TShirt的子模块：OffTShirt，在其中覆写getPrice函数，实现打折处理
 领域模型如下：
 TODO tu
 
-这样就只需要修改用户模块ClothStore，使其从调用TShirt的getPrice函数改为调用OffTShirt的getOffPrice函数，而不需要修改Cloth的相关代码
+这样就只需要修改用户模块ClothStore，使其从调用TShirt改为调用OffTShirt，而不需要修改Cloth的相关代码
 
 这样就通过扩展来实现了变化，符合开闭原则
 
-值得注意的是：开闭原则允许修改用户模块
-
 
 # 案例2
 
 
-我们来看下另一个例子，我们要实现一个人员管理系统，领域模型如下：
+我们来看另一个例子
+我们要实现一个人员管理系统，领域模型如下：
 TODO tu
 
 人员固定有三个数据：姓名、卡号、部门
@@ -72,7 +70,7 @@ TODO tu
 我们修改领域模型，修改后如下：
 TODO tu
 
-这里将人员和它的数据改为了组合关系
+这里将人员和它的数据改为组合关系
 比如对于原来的三个数据，现在它们的关系如下：
 ```ts
 人员 = 人员数据项1 + 人员数据项2 + 人员数据项3
@@ -83,8 +81,9 @@ TODO tu
 人员数据项3 = 名称(部门) + 值 + 类型(string)
 ```
 
-可以通过增加一个人员数据项，从而实现增加一个人员的数据；
-可以通过增加一个修改后的人员数据项，并使人员从组合修改前的数据项改为组合修改后的数据项，从而实现修改人员的数据；
-可以通过使人员不再组合某个数据项，从而实现删除人员的数据
+现在可以通过这样来实现用户的需求：
+通过增加一个人员数据项，从而实现增加人员的一个数据；
+通过增加一个修改后的人员数据项，并使人员组合修改后的数据项，从而实现修改人员的一个数据；
+通过使人员不再组合某个数据项，从而实现删除人员的某个数据
 
-这些都是通过扩展而非修改来实现变化，所以符合开闭原则
+因为这些都是通过扩展而非修改来实现变化，所以符合开闭原则

packages/再看设计原则/开闭原则/人员继承（前）.drawio

@@ -1 +1 @@
-<mxfile host="Electron" modified="2023-04-17T23:14:55.258Z" agent="5.0 (Macintosh; Intel Mac OS X 11_4_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/14.6.13 Chrome/89.0.4389.128 Electron/12.0.7 Safari/537.36" etag="q97hS0YzKS2D-LDZKWQ_" version="14.6.13" type="device"><diagram id="Bfc0rugBsH569nbIfP42" name="第 1 页">7VhNc6M4FPw1OmbKgDFwNJhkqsap3dpkZ2aPCsigRCBWyMHOr98nkAwYx5uDk5lDqqiyXuvpq7sFL0FOVOxuBK7yW54ShuxZukPOCtm25QYz+FHIvkNc3++ATNBUJ/XAHX0hGtTjsi1NST1KlJwzSasxmPCyJIkcYVgI3ozTNpyNV61wRibAXYLZFP1BU5l3qG97Pf6V0Cw3K1uLoOspsEnWJ6lznPJmADkxciLBuexaxS4iTJFneOnGXb/Se9iYIKV8y4DqJvm+WScPfBlh9tLcP93Gj1d6s8+YbfWBkb1gMF+44TAt7FruNRWLf7fcdFzVrVBLSHDsatd3Qitrf2MPhQ4Ku0aIgmszL2ywm1ondtwcVrGBpko1twW7FriAZtjkVJK7CicKb8BngOWyYBBZqlvrojwDHUaN+UxvVpvKsQ/LDUnTPD4TIcluAGkSbwgviBR7SDG9My2odrTl6bjp/eHMNZYPvWHuAtaezA5z97JBQyt3WkUZB38n93+Uj03zUH57Ce6fZHJlTVWM5yhcqid2UWChwJ8S3dCC4ZIYlnSPYi3JKUvXeM+3auu1xMmTicKcC/oC+djQD93CcGwv1GyUsYgzLgAoebtAP+hOTaaXEUTZ6E8jhnUE3eLdKHGNa2k2yBnDVU0f2i2rgQUWGS1DLiUvdNIFtLaDsdaH19JAa+uk1rP5O2ltn7ixcNSZEnrpocBpFZ8hf9Xdz1oKWmYT9YEA2Yon+BM5UuuEgJjRrISQkY0aphik8JJcalhydSdruKKw1rrNWc175C9zJQHiMHbD2hdhTtOUlEpfLrHEDwf/VZyWsiXODeEBfqPZFxe5sPEIYquP4VHpQka8hLNg2kpNwCkNqeVJE5y9Qf/vDOOExduMYPIu7gPnjA9A+6XVNq5R6H364B194Nq/2AfzV30QIN9BS181Ak81Pn3wfj7w/I/zwclKbjGRlKRQyeoQGMl5xkvM4h4FnrdlSlLNcp+z5kq/9rv6SKTc66873ko+Lr1IaUp2a3FUCrTAq5/gmm9FQs4cx9W1PnzWyRuEUmc9K5MgDEv6PK7qLy6C+5ZCDCriZdy+oL32Qz1VbsDwoIC1/AsVsM5RUeN4U+9aJ7zrXqB+PUnbtDj9EO/C1n/q8W3wjwrgPaLD1W7YudofovfyvDf1/DmX/Sae9yaejxhVZ/9YV199oKsh7P9ub/sG//1w4v8A</diagram></mxfile>
+<mxfile host="Electron" modified="2023-04-18T03:32:21.979Z" agent="5.0 (Macintosh; Intel Mac OS X 11_4_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/14.6.13 Chrome/89.0.4389.128 Electron/12.0.7 Safari/537.36" etag="rtDaz4FCV3n8fYhQhi7F" version="14.6.13" type="device"><diagram id="Bfc0rugBsH569nbIfP42" name="第 1 页">7Vhdb5swFP01fuwUIAnhMRDaSUu1ae2+Hl1wwI3BzDgl6a/ftTEBSppFWpPtYRJSfI+vsX3OMVyCnCDb3ghcpLc8JgzZo3iLnAWybcsde/CjkF2NuNaoBhJBY5PUAnf0mRiwSdvQmJS9RMk5k7TogxHPcxLJHoaF4FU/bcVZf9YCJ2QA3EWYDdFvNJZpjc5st8XfE5qkzczW1Gw4w02y2UmZ4phXHcgJkRMIzmXdyrYBYYq8hpd63PUrvfuFCZLLUwYUN9HX1TJ64PMAs+fqfn0bPl6ZxT5htjEbRvaUwf38FYfbwqrlzlAx/bnhTcdVqYWaQ4JjF9u2E1qJ/g1d5DvIrxs+8q6b+8IC61ubxJqb/Sw20FSo5iZj1wJn0PSrlEpyV+BI4RX4DLBUZgwiS3UbXZRnoKNRYzwyizWmcuz9dF3SDI9PREiy7UCGxBvCMyLFDlKa3pERdNd43MRV6w9nbLC06w3PgNh4Mtnfu5UNGka5wyrK0PsS3X/MH6vqIf/w7N2vZXRlDVUMx8ifqyucIM9C3mxIdEUzhnPSsGR6FGtRSlm8xDu+UUsvJY7WTeSnXNBnyMcN/dAt9hxrziljAWdcAJBzPUE76E7dzEwjiLLRp0YM6wV0i7e9xCUuZbNAzhguSvqgl6wGZlgkNPe5lDwzSR3trdnbaG97fe33j6mO9tZB7a1zaW8fOMGw1ZESfu4iz9EOGKHZoj6vpRQ0TwZuAAKkFlPwNXmh3gFBMaNJDiEjKzVMMUjhoTk3sOTqjJZwZGGupc5ZjFvkc3NEAeIwdsX0gzGlcUxypTeXWOKHvR8LTnOpiZv4cAGVwejdBE1g4QHEVhvDpdKFDHgOe8FUS03AORUp5UmmOHrCfu8U4wznRGPY0zP5wjniC/DC3NKNa+S7/31xQV9Mpn/ZF+NXfeGhmYPmM9XwXNX474vL+WJmn+iL2Z/74mAlOB1ITGKohE0IDKU84TlmYYsC75s8JrFhvc1ZcqWnfi8/Eil3hkC8kbxfupG8Kfmt6YtSQgOvvrJLvhERObKdiflWgLKAnCCU2utRmQRhWNKn/lfBm4swOaWQg4p6HuoHuKtf7EPlOgyfoQiynBdF0PjAu8464N3JG9RAB2kbFrcX8S4s/bsZr4MfKoDnigkX227nYrePzuV5d+j5Yy77RzzvDjwfMKr2fllXX13Q1RC23/26r/PviRP+Ag==</diagram></mxfile>

packages/再看设计原则/接口隔离原则/article.md

@@ -1,12 +1,11 @@
 # 定义
 
-用户不应该依赖它不需要的接口
 模块间的依赖关系应该建立在最小的接口上
 
 
 # 补充说明
 
-接口尽量细化，同时接口中的方法尽量少
+应该将庞大的接口拆分成更小的接口
 
 “接口”属于面向对象编程，它在函数式编程中的对应是“类型”
 
@@ -26,19 +25,17 @@ export type type1 = {
 }
 ```
 
-两者是等价的
+这两者是等价的，所以说接口隔离原则同样适合函数式编程，具体是指类型应该保持最小
 
 值得注意的是：
 类型名首写字母是小写，而接口名首写字母是大写
 
-接口隔离原则同样适合函数式编程，也就是指类型应该保持最小
-
 
 
 
 # 案例1
 
-我们开发了一个用户管理系统，其中有一个查询接口，方便管理员查询拥有，领域模型如下：
+我们开发了一个用户管理系统，其中有一个查询接口，方便管理员查询用户，领域模型如下：
 TODO tu
 
 系统上线后，发现系统速度非常慢，这是由于查询接口中的complexSerach函数性能太差造成的