前八周学习了几种设计模式，我现在就之前学的几种设计模式中的一些小问题，进行总结一下。
状态模式
优点：1.减少错误的发生并降低维护的难度。
因为不再使用switch（m_state）来进行判断当前状态，能降低新增状态时候，未能检测到状态（可能忘记写或者写措字）的bug；
2.状态执行环境单一化
与每一个状态有关的对象及操作都被实现在一个场景状态类里面，这样特别便于修改，以及了解每一个状态对象与其搭配子系统。
3.不同的项目场景可以共享
缺点：1.状态模式的使用必然要增加系统中类和对象的个数，导致系统运行开销增大。
2.状态模式的设计与结构都比较复杂，如果使用不当将导致程序结构和代码的混乱，增加系统设计的难度。
3.状态模式对于“开闭原则”的支持并不太好，增加新的状态类需要修改那些负责状态转换的源代码，否则无法转换到新增状态；而且修改某一个状态类的行为也需要修改对应类的源代码。
说到底状态模式的本质就是一个环境对象，以及很多不同的状态对象，每次给这个环境对象设置不同的状态对象，是不是很像玩游戏给枪上子弹。
外观模式
优点：外观模式的优点可以说一眼看出，内部子系统怎么弄我不管，我用一个大控制板，把这些一罩住，那外面的怎么用，直接看这个控制板了，比如操作系统和计算机硬件，汽车控制面板和硬件。
缺点：普通人根本不知道内部怎么实现，就算内部耦合再高，性能算是最差，你在调用时候甚至沾沾自喜，这多方便，我自己只需要调这个方法，就可以实现这个功能，殊不知内部性能特别差。有点自欺欺人的感觉。
所以外观模式我觉得不能纯粹的使用，必须要把内部的子系统搭配好了，再来用才是最好的。由内而定外。
单例模式
优点：单例模式的优点不言而喻，比如unity开发游戏时候，音乐播放器有一些游戏要求仅仅是只能有一个，有一些游戏你不能在待机时候，突然播放n多个bgm那岂不是把玩家吵死，这个时候单例的好处就出来了，全局唯一和方便获取。
缺点：缺点之前我也提到过，就是滥用单例，首先单例的特点有2个，全局唯一和方便获取，但大部分人在写代码时候看到其中一个时候就会不自觉的冒出使用单例模式的念头，这也可能是现在大部分程序员说使用的最多的就是单例模式（我认识的unity程序员都是这样说的），现在就特别要指出不能滥用单例，比如全局唯一的对象，你只需要使用静态的计数器Count 而不是需要一个静态对象（两者相比资源消耗一眼看的出），而如果你是想要方便获取，那就可以使用引用注入，把对象注入到所需的就可以实现。
中介者模式和桥接模式
这两没啥好说，只是我觉得这两个结构很相似，在此不赘述，有兴趣的可以自己去比对一下他们的结构图。
策略模式和模板方法模式
两者其实都是对算法的包装，一个是基于计算层次，一个是基于大的流程图的层次，策略模式是提供一个算法接口，然后这个接口里面包含了很多的算法自己通过接口去调，而模板方法是把一个大流程图，可能这个流程里面某一些步骤取决于条件，写一个抽象方法类，把里面某一些的取决于条件的步骤，让子类去重写。
以上就是我对之前的几种设计模式的一些小总结。
来源：CSDN
作者：风萧水寒人往前
链接：https://blog.csdn.net/qq_43546758/article/details/103240855