设计模式 原则&分类
words: 900 views: time: 3min设计模式的主要目标在于保证程序的高可用及高扩展性，在实际开发中不应该过多地纠结使用哪种设计模式，而是应该多体会设计模式的原则，换言之，只要遵循一定的原则，这些所谓的模式完全可能在无意识的状态下自发出现在产品代码中。其实这些设计模式也都不是谁突然间硬想出来的，而是从大量实践中总结出来的比较好的组织代码结构的方式。
好的设计能够有效避免或者延缓程序架构的腐化，通常，很多程序结构一开始也许设计得还可以，但随着业务功能的不断扩展和变化，可能就不得不在结构上做出一些妥协让步，慢慢地也就失去了结构。
另外，在设计过程中也要注意避免过度设计，即为不可能发生的变动付出过多的复杂度代价。总之不要滥用设计模式，不要觉得一个地方有可能会变动，就忍不住考虑是否应该增加复杂度来换取灵活性。而要避免过度设计，关键在于能正确的预见变化，以及权衡所引入的复杂度相对于发生变化的可能性和破坏力是否值得，当然这些都需要一定的经验积累以及对业务的认识。
1. 设计模式原则
1.开闭原则
即对扩展开放，对修改封闭。在程序需要扩展的时候，不要去修改原有的代码，而是扩展原有代码，实现一个热插拔的效果。
2.单一职责原则
不要存在多于一个导致类变更的原因，也就是说每个类的职责应该单一，否则就应该把类进行拆分。
3.里氏替换原则
任何引用基类的地方必须能透明地使用其子类的对象。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
4.依赖倒转原则
面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不要直接与具体类交互，而与具体类的上层接口交互。
5.接口隔离原则
每个接口中不存在子类用不到却必须实现的方法，否则，就应该将接口拆分，使用多个隔离的接口。
6.迪米特法则（最少知道原则）
一个类对自己依赖的类知道的越少越好，无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
2. 设计模式分类
1.创建型模式
工厂模式、单例模式、建造者模式、原型模式等
2.结构型模式
适配器模式、组合模式、装饰器模式、代理模式、门面模式、桥接模式、享元模式等
3.行为型模式
策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、访问者模式、调停者模式等