https://mp.weixin.qq.com/s/qRjn_4xZdmuUPQFoWMBQ4Q
面条型代码就是所有逻辑堆砌在一起，就像写一篇文章，不怎么分段落。比如古代雕刻文字，在一块木板上雕刻一首诗，如果诗人要把其中的一个修改下，那得重新雕刻这首诗。非常容易发现这种模式的缺点：耦合太严重，牵一发而动全身。
过程式代码在面条型代码基础上有了很大的进步，它遵循“自顶向下，逐步求精”的思想，把一个大问题划分成若干个小问题，分而治之。对应上面雕刻诗的例子，诗是由若干个行组成的，如果每块木板上只雕刻一行诗，万一要改某个字，只用重新雕刻那一行就行，不用重新雕刻整首诗。但如果要修改多个字，而且在不同的行时，这种极端情况下整个首诗又得重新雕刻了。
面向对象代码换了一种思考方式，诗是由行组成的，行又是由一个个字组成的，这也即是活字印刷的思想，这些字还可以复用于其它不同的诗，复用性非常强。
再回过头看底层逻辑，平时我们看到的现象只是现象层，核心是要洞察到事物的底层逻辑，只有那样才能真正理解现象、运用规律，如果你不懂营销文案背后的底层逻辑，你所有的勤奋都是低水平的重复，很难写出高质量的营销文案，偶尔一两次起得了良好的效果你也不知道为什么能吸引人。设计模式也是一样，你能熟悉地画出各种模式的UML图，可你依然还是用不好设计模式，本质还是没有掌握设计模式的底层逻辑，只看到了设计模式的现象层的招式。设计模式的底层逻辑是“找到变化，封装变化”，这里就有两个问题：什么在变化，如何封装变化，大师以为我们都知道，所以并没有讲具体怎么去寻找变化，怎么去封装变化。接下来具体谈谈怎么去运用设计模式的底层逻辑。
从封装的类型上看，有数据的封装、方法的封装、类型的封装等。就具体的封装方法而言，常见的有配置项、接口、抽象方法、类、注解、插件等具体的手段，再往上看主要使用了继承、组合的方法，再往上看封装的原则，常见的原则有单一职责、开闭原则、依赖倒置、隔离原则……大部分人平时更多地关注如何封装变化，并没有深入去思考什么在变化。
非线性关系比线性关系要复杂，常见也有两种方法：一种是通过注册机制，另一种通过抽象层屏蔽复杂性。当一个对象包含多个对象时，如果直接去管理，需要承担的职责太多，通过注册机制就比较好解决，增加一个对象，是通过注册机制主动告知对象。另外一种方法就是通过抽象层屏蔽复杂性，比如门面模式，在门面内把所有的复杂度都规避，对外提供简洁的接口。
设计模式还是要应用到实际的业务中才能发挥它的价值， Alan Shalloway 提到一个观点：无法预测哪里有变化，但能知道哪里可能有变化。平时我们在做业务需求开发时，要有这种识别变化的意识，先不要陷入面向过程的思维中，不要一上来就考虑如何去实现，而是思考它是什么，会有哪些变化，比如对象的数量、对象的外观、对象的种类……当把这些思考清楚之后，才能设计得更合理。
有了前面所讲内容的铺垫，这里再深入总结下对象设计的一些思考。对象设计有三个问题：有哪些对象？对象之间的关系是怎样的？对象的职责有哪些？当把这三个问题梳理清楚了，对象设计也就容易得多，也是面向对象分析与设计的核心。正常来讲，我们知道结构决定功能，功能决定行为，这是非常符合人的逻辑认识，但要想了解清楚对象的结构又是非常难的，就像新冠病毒的分子结构也不是那么容易破解的，尤其是复杂业务，它所包含的业务对象并不那么容易弄清楚它的结构。
原文：https://www.cnblogs.com/rsapaper/p/14702615.html