feat(再看设计原则): finish update

Author: yyc-git

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

@@ -1,8 +1,6 @@
 # 定义
 
-高层模块不应该依赖低层模块，两者都应该依赖其抽象
-抽象不应该依赖细节
-细节应该依赖抽象
+高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象
 
 
 # 补充说明
@@ -14,13 +12,9 @@
 <!-- “抽象”在函数式编程的代码中指的就是接口或者类型
 “细节”在函数式编程的代码中指的就是模块或者函数 -->
 
-“抽象”在代码中具体指的就是接口或者类型
-“细节”在代码中具体指的就是模块或者函数
-
-依赖倒置原则具体是指模块或者函数之间不应该直接依赖，而应该是依赖于它们的接口或者类型
-
-所以说，符合依赖倒置原则的编程可以看作是“面向接口/类型编程”
+“抽象”在代码中具体指的就是接口或者类型，“细节”在代码中具体指的就是模块或者函数
 
+依赖倒置原则具体是指模块或者函数之间不应该直接依赖，而应该是依赖于它们的接口或者类型。所以说，符合依赖倒置原则的编程可以看作是“面向接口/类型编程”
 
 符合依赖倒置原则有下面的好处：
 - 减少细节之间的耦合性
@@ -33,10 +27,11 @@
 
 # 案例1
 
-TODO tu
-上图是读者阅读技术书的领域模型
+以读者读书的系统为例，领域模型如下：
 
-伪代码如下：
+![阅读技术书的领域模型图](./1.png)
+
+现在只有技术书，伪代码如下：
 TechnicalBook
 ```ts
 type technicalBook = {
@@ -62,12 +57,15 @@ Client
 Reader.read(TechnicalBook)
 ```
 
-如果增加小说书，让读者既可以阅读技术书又可以阅读小说书，这具体是由Client决定读者阅读哪类书
+现在增加小说书，读者只能阅读技术书或者小说书，这由Client决定。
 修改后的领域模型如下：
-TODO tu
+
+<!-- 既可以选择阅读技术书或者选择阅读小说书，这具体是由Client决定读者阅读哪类书 -->
+![修改后的领域模型图](./2.png)
 
 修改后的伪代码如下：
-TechnicalBook代码不变
+
+TechnicalBook代码不变，故省略
 
 NovelBook
 ```ts
@@ -105,16 +103,12 @@ Client
 Reader.read(TechnicalBook, NovelBook, "novel")
 ```
 
-这里的问题是因为Reader依赖了每类书，所以每增加一类书，Reader都需要对应修改代码
-我们将其改为符合依赖倒置原则，解除Reader与每类书的依赖
-修改后的领域模型如下：
-TODO tu
-
-现在提出了书的接口：Book，让Reader改为依赖书的接口，而不依赖书的实现模块
-这样做的好处是只要Book接口不变，它的实现模块的变化不会影响到Reader
+这里的问题是因为Reader依赖了每类书，所以如果一类书发生了变化，或者增加了一类书，那么Reader都需要对应修改代码。
 
+我们需要解除Reader与每类书的依赖，从而使其符合依赖倒置原则。修改后的领域模型如下：
+![重构后领域模型图](./3.png)
 
-修改后的伪代码如下：
+现在提出了书的接口：Book，让Reader改为依赖书的接口，而不依赖书的实现模块。这样做的好处是只要Book接口不变，它的实现模块的变化不会影响到Reader。修改后的伪代码如下：
 Book
 ```ts
 export interface Book {

packages/再看设计原则/依赖倒置原则/1.png

@@ -1 +1 @@
-<mxfile host="Electron" modified="2023-04-17T02:02:22.989Z" 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="bQjiZp3qGXUN2eX79w0X" version="14.6.13" type="device"><diagram id="YagxbB3KC2PYYdOba1ut" name="第 1 页">tZXBbqMwEIafBqk9dBWgSZNjTbLdldpVd1Npzy42YNV4kJk2SZ9+x2AgJK02OfSCmH/GDjP/ZyeIk3J7Z3lVPICQOogmYhvEyyCKFtczejph1wqzm6gVcqtEK4WDsFbv0osTr74qIetRIQJoVNVYTMEYmeJI49bCZlyWgR7/asVzeSSsU66P1b9KYNGq8+hm0H9IlRfdL4ezRZspeVfsO6kLLmCzJ8WrIE4sALZv5TaR2s2um0u77vsn2f7DrDR4yoLFXADeRRt7m77Bise/f8WLK2/GG9evvuEgiYJbpgxKm/FUupCxICIbY/IkZgzg5afJwDeFu25S9UaVmhuKWAYG1z4TUsy1yg29p9JtS8KbtKhoyLc+gVCRmhZKi3u+g1fXUI08fekiVoBV77Qt135PSlv0vMwno4q1W0myU62sqeaxm1J4ID3w7ajwntfohRS05lWtnvs2Sm5zZRggQumLmk7bj4jJUebHSe3J7ac+hb37dGoklBLtjkq6BR36/sSEsY83A3/RzGvFPnuLuefeM5/3ew9Y0Isn4wxKro8pOXRfq8b5Gi289CfFDS1TWieggWxfGmiKOhy0zPADGEolhG42q3iqTP7k4FhehYNy3yxcxoPyx4/BSRaQI29tcx5p/iz1I9QKFbj9bVvLKiDKm1FNWTBdNorFBAw1wVVjliQcNtIhcZqzn5+xY7u9vfMT3f0qb6cfeMtyic05X15c7h19StR9QomDFBfCpS6e6XF5xAdNDXs+Dng4H5H2vhjTcH1Mg5OA1ma6uXgLAkuaDwgZk8Bo+snk29QxESUUh0P8X0z2LgSy7AuxmZ94KXS3yRngUDj8LTW5vf/2ePUP</diagram></mxfile>
+<mxfile host="Electron" modified="2023-05-16T20:16:22.107Z" 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="ahzCg_nv7yuT8iYb1Q3W" version="14.6.13" type="device"><diagram id="YagxbB3KC2PYYdOba1ut" name="第 1 页">tZVNc9owEIZ/jWeSQzrYDhSOyKS0M0knLZnpWbFkWxNZ65E3fOTXd2XLGANtyCEX8L67Euy+j+QgTsrt0vKqeAAhdRCNxDaIF0EUheFoQl9O2bXKdBy1Qm6V8EW9sFJv0osjr74qIetBIQJoVNVQTMEYmeJA49bCZliWgR7+asVzeSKsUq5P1T9KYOG7iL72+nep8qL75XAyazMl74p9J3XBBWwOpPguiBMLgO1TuU2kdsPr5tKu+/aP7P6PWWnwkgWzqQBcRhs7T9dwx+NfP+PZjTdjzfWrbzhIomDOlEFpM55KFzIWRGRjTJ7EjAG8/DAZ+KZw102q3qhSc0MRy8DgymdCirlWuaHnVLptSVhLi4qGPPcJhIrUtFBa3PMdvLqGauTpSxexAqx6o2259ntS2qLnZToaVKzcSpKdamVNNY/dlMIj6YFvB4X3vEYvpKA1r2r1vG+j5DZXhgEilL6o6bT9EzE5yk5N8T65juX2QPImLSWUEu2OSvoz0y7xJyaMfbzp+YsmXisO2ZtNPfee+Xy/d48FPXgyPkDJ7Sklx+5r1Thfo4WX/UlxQ8uU1gloINsXBpqiDgctMzwDQ6mE0M1mFU+VyZ8cHIubsFfum4WLuFd++zE4yQJy5K1tziPNn6V+hFqhAre/bWtZBUR5M6oxC8aLRrGYgKEmuGr8k4TDRjokzjj73wP1vt3dhXihu5/l7fiMtyyX2JzzxdX1wdGnRL1PKHGU4kK41NUzfVyf8EHTwD0fRzx8HJH2vhjScHtKg5OA1ma6uXgLAkuaM4QMSWA0/WT0ZeyYiBKKwz5+F5ODC4Es+0RsphdeCt1t8gFwKOxfS03u4OUe3/0F</diagram></mxfile>

packages/再看设计原则/依赖倒置原则/2.png

@@ -7,23 +7,21 @@
 
 如果一个模块或者函数做了多件事情，那么应该将其拆分
 
-从函数名上就能看出该函数是否符合单一职责原则，如“getAndSetData”这个函数名一看就知道做了两件事情，所以应该将其拆分为getData、setData这两个函数
-
+从函数名上就能看出一个函数是否符合单一职责原则，如“getAndSetData”这个函数名一看就知道做了两件事情，应该将其拆分为getData、setData这两个函数
 
 如果一个模块或者函数做了多件事情，有下面的缺点：
-
 - 任何一件事情的变化都会影响它
 - 用户调用它时，本来只预期它做某件事情，结果它实际上还做了其它的事情，这可能造成不可预料的bug
 
 
 # 案例1
 
-TODO tu
-上图是操作书的接口，它不符合单一职责原则
-这是因为它的getBookID、setBookID函数是对书的数据的操作，而它的addBook函数则是对书的行为的操作，所以该接口做了两件事情
+![书的接口图](./1.png)
+
+上图是操作书的接口，它不符合单一职责原则。这是因为它的getBookID、setBookID函数是对书的数据的操作，而它的addBook函数则是对书的行为的操作，所以该接口做了两件事情
 
-应该将其拆分为两个接口，每个接口只做一件事情。拆分后的接口如下图所示：
-TODO tu
+应该将其拆分为两个接口，使每个接口只做一件事情。拆分后的接口如下图所示：
+![重构后的书的接口图](./2.png)
 
 BookData接口负责操作书的数据
 BookAction接口负责操作书的行为
@@ -32,19 +30,16 @@ BookAction接口负责操作书的行为
 
 # 案例2
 
-
-
 ```ts
 type userName = string
 
 type phone = number
 
 type changeUser = (newUserData: [userName, phone]) => void
 ```
-上面的代码是一个函数（changeUser）的签名
-从签名可知，该函数不符合单一职责原则，这是因为它的形参是一个元组，包含了多个数据，这说明该函数做了多件事情
+上面的代码是函数（changeUser）的签名。从签名可知，该函数不符合单一职责原则，这是因为它的形参是一个元组，包含了多个数据，这说明该函数做了多件事情。
 
-应该将其拆分为多个函数，每个函数只做一件事情。拆分后的函数签名如下所示：
+应该将其拆分为多个函数，使每个函数只做一件事情。拆分后的函数签名如下所示：
 ```ts
 type userName = string