设计模式七大原则——NWU_LK

设计模式七大原则

七大设计原则

• 单一职责原则
  目的： 降低代码复杂度、系统解耦合、提高可读性

  含义： 对于一个类，只有一个引起该类变化的原因；该类的职责是唯一的，且这个职责是唯一引起其他类变化的原因。

  解决： 将不同的职责封装到不同的类或者模块中。 当有新的需求将现有的职责分为颗粒度更小的职责的时候，应该及时对现有代码进行重构。当系统逻辑足够简单，方法足够少，子类够少或后续关联够少时，也可以不必严格遵循你SRP原则，避免过度设计、颗粒化过于严重。

• 开闭原则
  目的： 提高扩展性、便于维护

  含义： 对扩展开放，对修改封闭。即系统进行扩展是被鼓励的，对现有系统代码进行修改是不被支持的。也就是说，当软件有新的需求变化的时候，只需要通过对软件框架进行扩展来适应新的需求，而不是对框架内部的代码进行修改。

  解决： 设计模式前面6大原则以及23种设计模式遵循的好，开闭原则自然遵守的好。对需求的变更保持前瞻性和预见性，就可以使抽象具有更广泛适用性，设计出的软件架构就能相对稳定。软件需求中易变的细节，通过从抽象派生出实现类来扩展。

• 里氏替换原则
  目的： 避免系统继承体系被破坏

  含义： 所有引用基类的地方必须能透明地使用其子类的对象。

  解决： 子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法；子类中可以增加自己特有的方法；当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。如果子类不能完整地实现父类的方法，或者父类的一些方法在子类中已经发生畸变，则建议断开继承关系，采用依赖，聚合，组合等关系代替继承。

• 依赖倒转原则
  目的： 避免需求变化导致过多的维护工作

  含义： 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

  解决： 面向接口编程，使用接口或者抽象类制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

• 接口隔离原则
  目的： 避免接口过于臃肿

  含义： 客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。

  解决： 适度细化接口，将臃肿的接口拆分为独立的几个接口。

• 合成复用原则
  目的： 防止类的体系庞大

  含义： 当要扩展类的功能时，优先考虑使用合成/聚合，而不是继承。

  解决： 当类与类之间的关系是"Is-A"时，用继承；当类与类之间的关系是"Has-A"时，用组合。

• 迪米特法则
  目的： 降低类与类之间的耦合

  含义： 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

  解决： 不发生依赖、关联、组合、聚合等耦合关系的陌生类不要作为局部变量的形式出现在类的内部。