设计模式杂谈

设计模式一共是23种，其实就是23种的解决问题的方法或者说是思路。有人很看好设计模式，觉得这个就是圣经，有的人觉得设计模式也就那样。我个人对设计模式还是非常推崇的，

写代码要优先从设计的角度去思考问题。在设计之初就想到扩展点，一定不能光为了实现功能而且写代码。那样后期的改动，bug的修改，重构，都是灾难级别的。

从设计的角度去看这些模式都是优先遵循6大设计原则。6大设计原则才是做程序设计的圣经。做程序设计不是一定要满足设计原则，但是是要尽量去满足。比如说单一职责，现在产品开发那么急，如果严格遵循单一职责的话，那就意味着开发量非常大，根本开发不完，一个类一个职责，那就把标准降一降一个函数一个职责。比如说开闭原则，那目前就是就一个扩展点，就写成一个函数够了。以后需要扩展了在实现接口，做起来也不是很费事。就是在工时ok的情况下，尽量满足设计原则，及时不满足那也要把可扩展的地方抽成函数。一个函数我认为最多不能超过10行，除非是设置值，sql查询这种，行数很多，但是表达的逻辑很少，这种的逻辑体，函数的长度可以适当长一些。

23种设计模式是23种解决问题的思路，多么复杂的逻辑，都能用上一部分，我推崇的原因是，它这个场景下的这个类设计已经是非常合理了。我们实际使用的场景和原生设计模式的场景有偏差，都是可以改动的，大的架子其实是不变的，只是小细节的改动，我在使用设计模式的时候，直接就拿标准的设计模式类图看，将自己的场景对应的映射标准的类图，那里不符合在改动那里就可以了。23种设计模式总有你的菜，逻辑约复杂，就肯定更能用的上，那就模式之间组合这用呗。我认为做设计的时候，要先想和那个模式有相似的地方，然后按照这个模式的标准去思考，这样思路会非常清晰。

学习设计模式，一定要比较这学，才有意思。要体会这些标准类设计的意图是哪里，相似模式之间的对比在哪里，有可能就是一个函数的问题，就会让类和类之间的关系就不一样了，就会让扩展性更好，比如说模板方法里面的hook函数，点睛之笔。