Head First 设计模式设计模式入门

Posted 2021-02-20 weixin-tt

　　这本书是18年买的了，当时我买了一堆书，以为自己不会成为屯书的仓鼠，没想到当时看了200页不到就再也没看；如今再次翻开，是因为参加 码农翻身 的读书活动，当年买书时还在的小仓鼠也飞天一年了= =

　　但还好当初我读了一些，这本书的前言部分教会了我一些学习方法。在我还上学时，我总觉得因为我太笨，不够聪明，所以别人会的东西我不会。但当我培训时，我付出时间去预习复习，上课时听讲师讲课，还读了许多教程里没有的“课外书”，我发现我学的在培训班里算好的。直到今天我才有点明白，大多人的智商好像没太大差距，掌握了正确的方法，付出足够的时间与努力，就是能学会东西的。

　　学习的方法论这本书里提了一些、

　　多喝水，读书可以适当慢一些，勤做练习与笔记，给自己点仪式感，暗示自己学的东西很重要，在大脑累时别让大脑继续记忆了，弄不懂的问题，就多睡2觉，过两天就明白了，运用到工作中..原来这些都是有道理的~

　　还是直接进正题吧。

　　遇到的问题，有些人已经帮你解决了。.设计模式就是这种存在，和平常工作、生活时遇到不懂的问题去搜索一样，总有许多答案在网上摆着了。

　　设计模式都是封装了一部分不变的部分，使这部分代码改动时不会影响到其他地方，达成系统的松耦合。第一章说的是策略模式，封装了算法族。

　　书里举了个Duck类实现的例子，一开始用继承的方式，外观、叫声2个方法。但很快，需求变动就来了，需要新增飞行的能力，增加了飞行的能力后，橡皮鸭也能飞了...而且通过继承，每个子类都需要重写方法，使代码比较臃肿，新增子类后需要的改动量大，不符合松耦合的设计思想。

　　在我遇到的项目里，我很少遇到有需要用继承去实现的功能，大部分都是普普通通的CRUD，项目里大多是用接口。

　　书里也给出了用接口的方式，但不是直接用，只用接口的话，还是需要写许多重复代码的。重复代码在项目中出现就是罪恶，会让可读性、维护性都变差。

　　找出应用中可能需要变化之处，独立出来，不要和那些不需要变化的代码混在一起。这个观点和敏捷开发那本书里的挺类似的。可能好的书都会有相似的观点吧。

　　把Duck类的行为与本体分开，就好像名词和动词分开似得，动词变成了接口，一种能力。名词则是类，Duck类本身。Duck类再去实现相应的能力，组成了人理解中的鸭子。

　　动态的改变类的行为，本来我一直不是很明白，看了2章后，原来就是set方法嘛。还是代码控制的呀。

　　针对接口编程，而不是实现类。在书中例子确实感受到了，但在工作中却实在感受不到，项目中大多接口都是只有一个实现类的，数据逻辑层接口，数据逻辑的实现……但最近有接触到双数据源的概念，需要用2个数据库取数，我们这的前人的方式是代码写2套，但现在想想，是不是写2个实现类更方便一些？

　　懂设计模式确实能让沟通成本大大降低，平常部门开会时确实是经常陷入某一个细节里，就出不来了。开完会也没对项目本身有什么整体的了解。如果能用这种“黑话”，确实能在设计层呆久些。

　　策略模式，定义算法族，封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。