设计模式(一)六大设计原则

一、单一职责原则

  • 定义:应该有且仅有一个原因引起类的变更。
  • 解释:一个接口或类只有一个职责。实际操作中,接口设计尽量满足本原则,类则不必细分,否则认为增加类的数量。

二、 里氏替换原则

  • 定义:所有应用基类的地方必须能透明地使用其子类的对象。
  • 解释:只要父类能出现的地方子类就可以出现,而且替换成子类后不会出现任何异常。
    该原则包含的四层含义:

    1.子类必须完全实现父类的方法。
    父类最好是接口或抽象类,不要把具体类作为父类。子类如果不能完全实现父类的方法,这个“子类”就不应该继承这个“父类”。委托是继承之外的另一种对类的行为功能进行复用扩展的方法。
    能使用委托实现的就不使用继承。两个类有明显示的层级关系时使用继承,没有明显的层级关系,仅仅是为了在一个类中使用另一个类的方法时应该使用委托。
    委托(也叫代理)参考:http://www.uml.org.cn/j2ee/200411036.htm
    http://www.cnblogs.com/cenyu/p/6289209.html
    2.子类有父类不具备的特性。
    子类可以胜任父类的职位,父类不一定能胜任子类的工作。
    3.复写或实现父类方法时,输入参数范围可以被扩大。
    子类的参数必须比父类的范围更大或相同。在重载时,输入小范围参数永远是运行父类的方法。想要运行子类的方法,复写父类方法。
    4.复写或实现父类方法时,输出参数范围可以被缩小。

三、依赖倒置原则

  • 定义:
    ①模块间的依赖通过抽象(抽象类、接口)发生,实现类之间不能有依赖。
    ②实现类依赖抽象,抽象不能依赖实现类。
  • 解释:依赖倒置原则的本质就是通过抽象(接口或抽象类) 使各个类或模块的实现彼此独立,不互相影响, 实现模块间的松耦合, 我们在项目中使用这个规则遵循以下的几个规则

    1.每个类尽量都有接口或抽象类, 或者抽象类和接口两者都具备
    这是依赖倒置的基本要求, 接口和抽象类都是属于抽象的, 有了抽象才可能依赖倒置。
    2.变量的表面类型尽量是接口或者是抽象类
    很多书上说变量的类型一定要是接口或者是抽象类, 这个有点绝对化了, 比如一个工具
    类, xxxUtils一般是不需要接口或是抽象类的。 还有, 如果你要使用类的clone方法, 就必须
    使用实现类, 这个是JDK提供的一个规范。
    3.任何类都不应该从具体类派生
    如果一个项目处于开发状态, 确实不应该有从具体类派生出子类的情况, 但这也不是绝
    对的, 因为人都是会犯错误的, 有时设计缺陷是在所难免的, 因此只要不超过两层的继承都
    是可以忍受的。
    4.尽量不要覆写基类的方法
    如果基类是一个抽象类, 而且这个方法已经实现了, 子类尽量不要覆写。 类间依赖的是
    抽象, 覆写了抽象方法, 对依赖的稳定性会产生一定的影响。
    5 结合里氏替换原则使用

  • 本质:面向接口编程

四、接口隔离原则

  • 定义:

  • 解释:接口应该细化,不要聚集过多的方法

  • 两种接口:实例接口(实例的类型就是实例的接口)、类接口(常见interface接口)。

  • 接口隔离:
    ①逻辑不应依赖它不需要的接口
    ②类间的依赖关系应建立在最小的接口上

五、迪米特法则

  • 定义:一个类应该对自己需要耦合或调用的类知道得最少。
  • 迪米特法则对类的低耦合提出了明确的要求, 其包含以下4层含义。

1.只和朋友交流;
2.朋友间也是有距离的;
3.是自己的就是自己的,如果一个方法放在本类中, 既不增加类间关系, 也对本类不产生负面影响, 那就放置在本类中。
4.谨慎使用Serializable;

  • 如果一个类跳转两次以上才能访问到另一个类,就需要想办法重构了。
  • 本质:类与类之间降低耦合,提高类的复用率。

六、开闭原则

  • 解释:一个软件实体(类、接口、函数等)应该对修改关闭,对扩展开放。需求的变化通过扩展子类而不是修改源码来实现。
发布了55 篇原创文章 · 获赞 23 · 访问量 1万+

猜你喜欢

转载自blog.csdn.net/Z_Vivian/article/details/100060783