fix img

专栏/白话设计模式 28 讲（完）/26 谈谈我对设计原则的思考.md.html

@@ -700,7 +700,7 @@ class CrucianCarp(FishAnimal):
 鲫鱼的活动方式：在水里游...
 </code></pre>
 <p>上面这些代码组织成如下的类图结构：</p>
-<p><img src="assets/b9e67010-9df7-11e8-a532-c96c5ba7ae58.jpg" alt="enter image description here" /></p>
+<p><img src="assets/b9e67010-9df7-11e8-a532-c96c5ba7ae58.jpg" alt="png" /></p>
 <h5><strong>优点：</strong></h5>
 <ul>
 <li><strong>提高程序设计灵活性</strong>。将接口进行细分后，多个接口可自由发展，互不干扰。</li>
@@ -710,7 +710,7 @@ class CrucianCarp(FishAnimal):
 <h3>实际项目中是否一定要遵循这些设计原则</h3>
 <h4>软件设计是一个逐步优化的过程</h4>
 <p>从上面六个原则的讲解中，应该体会到<strong>软件的设计是一个循序渐进，逐步优化的过程</strong>。经过一次次的逻辑分析，一层层的结构调整和优化，最终得出一个较为合理的设计图。整个动物世界的类图如下：</p>
-<p><img src="assets/0cf1e5f0-9df8-11e8-87cc-5b643420a0df.jpg" alt="enter image description here" /></p>
+<p><img src="assets/0cf1e5f0-9df8-11e8-87cc-5b643420a0df.jpg" alt="png" /></p>
 <p>我们对上面五个原则做一个总结：</p>
 <ol>
 <li><strong>单一职责原则告诉我们实现类要职责单一</strong>。用于类的设计，增加一个类时使用 SRP 原则来核对该类的设计是否纯粹干净，也就是让一个类的功能尽可能单一，不要想着一个类包揽所有功能。</li>
@@ -752,7 +752,7 @@ class CrucianCarp(FishAnimal):
 <p>这一原则正如这句话本身一样容易理解。简单就是说要让你的程序能简单、快速地被实现；愚蠢是说你的设计要简单到傻瓜都能理解，即简单就是美！</p>
 <p>为什么要简单呢？因为大多数的技术团队，每一个团队成员的技术水平都是参差不齐。如果你的程序设计的太复杂，有些成员可能无法理解这种设计的真实意图，而且复杂的程序讲解起来也会增加沟通成本。为什么说愚蠢呢？对同样需要的一个软件，每个人都有自己独特的思维逻辑和实现方式，因此你写的程序对于另一个人来说就是个陌生的项目。所以你的代码要愚蠢到不管是什么时候，不管是谁来接手这个项目，都要能很容易地被看懂；否则，不要让他看到你的联系方式和地址，你懂得~</p>
 <p>有些人可能会觉得设计模式这东西很大上（神化了它的功能），学了一些设计模式，就为了模式而模式，去过渡地设计你的程序，这是非常不可取的。监听模式是一种应用非常广泛的设计模式，合理地应用能很好地对程序进行解耦，使程序的表现层和数据逻辑层分离！但在我接手过的一些项目中却看有这样的设计：A 监听 B，B 又监听 C，C 再监听 D，这就会出现数据的层层传递和连锁式的反应。因为如果 D 的数据发生变更，就会引起 C 的更新，C 的更新又会影响 B，B 又影响 A，同时数据也从 D 流向 C，再流向 B，再流向 A。这种一环扣一环的设计有时是非常可怕的，一旦程序出现问题，追踪起来将会非常困难；而且只要其中某一环境出现需求的变更，就可能会影响后续的所有环。如果是一个新人来接手这样的项目，你能想像到他也会有多抓狂！这就是一个明显的过渡设计的例子，只要你仔细地分析需求和业务逻辑，一定可以用更好的实现方式来替换他。</p>
-<p><img src="assets/75fe7220-9df8-11e8-87cc-5b643420a0df.jpg" alt="enter image description here" /></p>
+<p><img src="assets/75fe7220-9df8-11e8-87cc-5b643420a0df.jpg" alt="png" /></p>
 <h4>DRY 原则（Don’t Repeat Yourself）</h4>
 <blockquote>
 <p>Don't repeat yourself</p>