此章记录下阅读设计模式读后感，也做监督己用。

——2019.12.31

第一章小结：

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

（鸭子例子：使用策略模式实现一个独立的鸭子的行为的类）

设计原则1：找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起出现。   ok

设计原则2：针对接口编程，而不是针对实现编程。  ok (个人理解的最通俗的例子：若某些子类的某种行为实现方法太多太杂，可直接把所有实现方法拉出来，单独成为一个实现类，同时子类的某种行为的实现方法也灵活了起来，保证代码的可维护性和可复用性)

设计原则3：多用组合，少用继承。ok

第一章读后感：第一感觉，更明白了设计模式到底是什么，他不是具体代码，而是解决代码复杂度的一个方法，基于oo原则，是一种大家约定俗成的开发套路；第二感觉，策略模式这一名称真的是太贴切，太传神了，把多样的，易变的方法组合成一个类，让具体事例去使用这个方法，却不需要知道具体实现；第三感觉，大厅开发我有了一种新的理解，虽然暂时还不能动代码，不过可以考虑的方面多了一层，比如调用的操作可以有一个公用的类，调用者不需要知道具体实现，还要再考虑一下；第四感觉，有趣，有趣的多。——2019.12.31

第二章小结：

观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会受到通知，并自动更新。

（例子：报社和订阅）

设计原则4：为了交互对象之间的松耦合而努力。

第二章读后感：其实观察者模式是比较简单的，刚入门的时候已经仔细查看过其定义，对于其原理还是懂一些的，读完此章，对于具体的观察者--被观察者实现更了解了一些，对于自己正在维护的代码多了一些思路，希望后面的代码维护过程中能熟练运用。——2020.01.02

出于好奇我读了一遍大厅的观察者模式代码，发现居然使用了两个观察者模式，直连使用，其中cell的写法较为直观普通，简单的监听的下发数据。datacenter的模式看起来比较高级，我还顺便复习了一下，lua中__index和__newIndex的用法，大佬就是大佬，写法都很高级。

第三章小结：

装饰者模式：动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

设计原则5：类应该对修改关闭，对扩展打开。

第三章读后感：说实话对装饰者模式的感触不是很深，不过也基本上了解了大概内容，io的例子还是懵懵懂懂知道一些的，希望下一章工厂模式和生成器模式能给我带来更大的感触。——2020.01.03

第四章小结：

工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

抽象工厂模式：提供了一个接口，用于创建相关或依赖对象的家族，而不需要明确指出具体类。

设计原则6：要依赖抽象，不要依赖具体类。

第四章读后感：对于工厂方法和抽象工厂有了一个模糊的定义，总之就是尽量减少依赖具体类的实例化。我觉得这一张要再看一遍。——2020.01.06   --耗时1小时40分钟（需要复读）

回顾：今天又花了一些时间回顾了一下内容。对于两个方法有了新的认识：工厂方法是某个抽象类中的方法，他可以让某个具体类转变为抽象类，从而对某个具体类解耦；抽象工厂是定义一系列不表明具体类的抽象类，他把具体的类的应用放到了每个子类中，从而达到解耦的效果。我觉得可以找一两个具体的例子看一看。——2020.01.07

第五章小结：

单件模式：确保一个类只有一个实例，并提供一个全局访问点。

第五章读后感：这一章比较简单，主要就是如何实现一个单件实例，以及在多线程中可能出现的问题和实际运用中的好处。——2020.01.08

第六章小结：

命令模式：将“请求”封装成对象，以便使用不同的请求，队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

第六章读后感：仔细想想，这一章和之前学习的“封装变化”有些类似。把每一个请求封装到对象里，调用者只需持有对象，调用约定好的方法，就能调用请求，把调用者和请求解耦开，还可以实现撤销操作，因为调用的时候封装的对象都知道啦，再调用的时候存一下undo操作就可以了。

第七章小结：

适配器模式：将一个类的接口，转化成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

设计原则7：最少知识原则：只和你的密友谈话。

第七章读后感：仔细想想，这不就是我正在编写的子大厅模块的功能吗，抛出最小的方法让子游戏能够使用。对于大厅和游戏的两个调用使用同一个接口模块去转化，而真正调用的时候不必去关心其中的实现。只不过这个最少知识原则我好想经常会违背。再想到更深一层，是不是我应该在更底层去做这个封装变化的事情，等到后面新加功能和模块的时候就不必去实现两个地方，直接把协议和所需数据封装起来，这样后面会更加的方便。（挺好诶，下一次会做这个事情。）——2020.01.21

第八章小结：

模板方法模式：在每一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

设计原则8：好莱坞原则：别找我，我会找你。

第八章读后感：从过年来，到最近，因为疫情的原因，和工作内容的强度，暂停阅读了这本书很久，因为重构移动大厅的原因，发现了很多不足，重新从第一章读了过来，主要重视看了类图的构成，突然发现已经阅读进度已经超过了阅读笔记，今天记录一下。这一章主要就是父类里面定义步骤，并暴露出一些接口可以让子类复写以完成某些功能。好莱坞原则告诉我们，把决策权放在高层，底层不能调用高层。——2020.06.24

第九章小结：

组合模式：允许你将对象组成树结构来表现“整体/部分”的层次结构。组合能让客户以一致的方法处理个别对象和对象组合。

迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。

设计原则9：类应该只有一个改变的理由。

第九章读后感：迭代器模式比较简单，主要是包装了一下表内部实现，在脚本语言中暂时感觉用处不大，哈哈哈，可能以后看到这句话会觉得大错特错吧，目前是这种感觉，组合模式更类似于一种递归，记忆比较深的是树状图，父节点和子节点都是继承同一个类，所以能够使用相同的方法去处理某些事情，达到递归的目的。——2020.06.24

第十章小结：

状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

第十章读后感：在动作固定的时候，随着状态的改变动作会进行不同的操作。此时可以生成一个父类状态，对于所有的动作做空处理或异常处理，各状态继承父类，对于要做的操作进行重写。在动作发生的时候修改持有状态的引用，把动作委托给状态实例。这样的好处就是避免了一大堆的if else语句，解耦了各动作在不同状态时的动作，对于增加新的状态非常的友好，对于增加新的动作也比较方便。弊端就是多了非常多的类代码和实例代码。——2020.07.01

第十一章小结：

代理模式：为另一个对象提供一个替身或占位符以访问这个对象。

第十一章读后感：这一章我读的比较潦草，讲了太多java中的代理的事，更多的处理网络交互的事情。

第十二章小结：

复合模式：复合模式结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性的问题。

第十二章读后感：终于看到了鼎鼎有名的mvc模式，模型，视图，控制器，已经观察者模式和策略模式在其中起到的重要作用。加深了对mvc的理解，更容易把日常工作中的代码带入到此模式中。——2020.07.22（哈哈，这本书就快看完了，今年的一个大目标。。。）

终章：最后一张列举了一些实用的设计模式，接下来我会用一到两天的时间把所有设计模式的类图总结出来，并放到此笔记中，以便后续方便查看和复习。——2020.7.27

桥接模式

生成器模式

责任链模式

蝇量模式

解释器模式

中介者模式

备忘录模式

原型模式

访问者模式