|
| 1 | +# 定义 |
| 2 | + |
| 3 | +高层模块不应该依赖低层模块，两者都应该依赖其抽象 |
| 4 | +抽象不应该依赖细节 |
| 5 | +细节应该依赖抽象 |
| 6 | + |
| 7 | + |
| 8 | +# 补充说明 |
| 9 | + |
| 10 | +<!-- 如何分辨高层模块、低层模块？ --> |
| 11 | +所谓的高层、低层模块是按照依赖的方向来定的，如模块1依赖模块2，则我们说模块1属于高层模块，模块2属于低层模块 |
| 12 | + |
| 13 | + |
| 14 | +<!-- 在代码中，抽象、细节在代码中指的是什么？ --> |
| 15 | +模块间应该抽象依赖于抽象 |
| 16 | +实现模块之间不应该发生直接的依赖关系，其依赖关系应该是通过接口产生的； |
| 17 | +接口不依赖于实现模块； |
| 18 | +实现模块依赖接口 |
| 19 | + |
| 20 | +所以说，符合依赖倒置原则的编程可以看作是“面向接口编程” |
| 21 | + |
| 22 | + |
| 23 | +符合依赖倒置原则有下面的好处： |
| 24 | +- 减少模块之间的耦合性 |
| 25 | +- 便于替换细节 |
| 26 | +- 提高系统的稳定性 |
| 27 | +- 降低并行开发引起的风险 |
| 28 | +- 提高代码的可读性和可维护性 |
| 29 | + |
| 30 | + |
| 31 | + |
| 32 | +# 案例1 |
| 33 | + |
| 34 | +TODO tu |
| 35 | +上图是读者阅读技术书的领域模型 |
| 36 | + |
| 37 | +相关伪代码如下： |
| 38 | +TechnicalBook |
| 39 | +```ts |
| 40 | +type technicalBook = { |
| 41 | + getContent: () => string |
| 42 | +} |
| 43 | + |
| 44 | +export let TechnicalBook: technicalBook = { |
| 45 | + getContent: () => { |
| 46 | + return "技术书的内容" |
| 47 | + } |
| 48 | +} |
| 49 | +``` |
| 50 | +Reader |
| 51 | +```ts |
| 52 | +export let read = (technicalBook: technicalBook) => { |
| 53 | + let content = technicalBook.getContent() |
| 54 | + |
| 55 | + ... |
| 56 | +} |
| 57 | +``` |
| 58 | +Client |
| 59 | +```ts |
| 60 | +Reader.read(TechnicalBook) |
| 61 | +``` |
| 62 | + |
| 63 | +如果增加小说书，读者既可以阅读技术书又可以阅读小说书，具体由Client决定让读者阅读哪本书 |
| 64 | +修改后的领域模型如下： |
| 65 | +TODO tu |
| 66 | + |
| 67 | +修改后的相关伪代码如下： |
| 68 | +TechnicalBook代码不变 |
| 69 | + |
| 70 | +NovelBook |
| 71 | +```ts |
| 72 | +type novelBook = { |
| 73 | + getContent: () => string |
| 74 | +} |
| 75 | + |
| 76 | +export let NovelBook: novelBook = { |
| 77 | + getContent: () => { |
| 78 | + return "小说书的内容" |
| 79 | + } |
| 80 | +} |
| 81 | +``` |
| 82 | +Reader |
| 83 | +```ts |
| 84 | +export let read = (technicalBook: technicalBook, novelBook: novelBook, needReadBook: string) => { |
| 85 | + let content = null |
| 86 | + |
| 87 | + switch (needReadBook) { |
| 88 | + case "technical": |
| 89 | + content = technicalBook.getContent() |
| 90 | + break |
| 91 | + case "novel": |
| 92 | + default: |
| 93 | + content = novelBook.getContent() |
| 94 | + break |
| 95 | + } |
| 96 | + |
| 97 | + ... |
| 98 | +} |
| 99 | +``` |
| 100 | +Client |
| 101 | +```ts |
| 102 | +//选择让读者读小说书 |
| 103 | +Reader.read(TechnicalBook, NovelBook, "novel") |
| 104 | +``` |
| 105 | + |
| 106 | +我们可以看到，每增加一本书，Reader都会受影响 |
| 107 | +我们将其改为符合依赖倒置原则，从而使Reader不受影响 |
| 108 | +修改后的领域模型如下： |
| 109 | +TODO tu |
| 110 | + |
| 111 | +现在Reader改为依赖Book这个接口，而不再依赖它的具体实现模块了 |
| 112 | +这样做的好处是只要Book这个接口不变，它的实现模块的变化不会影响到Reader |
| 113 | + |
| 114 | + |
| 115 | +修改后的相关伪代码如下： |
| 116 | +Book |
| 117 | +```ts |
| 118 | +export interface Book { |
| 119 | + getContent(): string |
| 120 | +} |
| 121 | +``` |
| 122 | +TechnicalBook |
| 123 | +```ts |
| 124 | +export let TechnicalBook: Book = { |
| 125 | + getContent: () => { |
| 126 | + return "技术书的内容" |
| 127 | + } |
| 128 | +} |
| 129 | +``` |
| 130 | +NovelBook |
| 131 | +```ts |
| 132 | +export let NovelBook: Book = { |
| 133 | + getContent: () => { |
| 134 | + return "小说书的内容" |
| 135 | + } |
| 136 | +} |
| 137 | +``` |
| 138 | +Reader |
| 139 | +```ts |
| 140 | +export let read = (book: Book) => { |
| 141 | + let content = book.getContent() |
| 142 | + |
| 143 | + ... |
| 144 | +} |
| 145 | +``` |
| 146 | +Client |
| 147 | +```ts |
| 148 | +//选择让读者读小说书 |
| 149 | +Reader.read(NovelBook) |
| 150 | +``` |
| 151 | + |
| 152 | +<!-- |
| 153 | +
|
| 154 | +
|
| 155 | +
|
| 156 | +
|
| 157 | +
|
| 158 | +# 案例2 --> |
0 commit comments