设计模式原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础，即设计模式为什么这样设计的依据。

设计模式常用的七大原则：

  • 单一职责原则
  • 接口隔离原则
  • 依赖倒转原则
  • 里氏替换原则
  • 开闭（OCP）原则
  • 迪米特法则
  • 合成复用原则

设计模式在软件的哪里使用？ 面向对象（OO）=> 功能模块[设计模式+算法(数据结构)] => 框架[使用到多种设计模式] => 架构[服务器集群]

设计模式就是为了让软件（程序）具有更好的：

  • 代码重用性（相同功能的代码，不用多次编写）
  • 可读性（编程规范，代码便于阅读理解）
  • 可扩展性（方便增加新功能，即可维护性）
  • 可靠性（增加新功能后，对原功能没有影响）
  • 使程序呈现高内聚、低耦合的特点

“设计模式包含了面向对象的精髓，懂了设计模式，就懂了面向对象分析和设计（OOA/D）的精要”

设计原则的核心思想：

  • 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码放在一起
  • 针对接口编程，而不是针对实现编程
  • 为了交互对象之间的松耦合设计而努力

单一职责原则

对类来说，一个类应该只负责一项职责。

  • 降低类的复杂度，一个类只负责一项职责
  • 提高类的可读性、可维护性
  • 降低变更引起的风险
  • 通常情况下，应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。

接口隔离原则

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

例如有接口InterfaceOne，类B实现了这个接口，类A需要调用接口的某几个方法。这样类A不会用到接口中的全部方法，但是类B却实现了接口的所有方法，这没有实现最小接口（因为接口中的fun3()与fun4()我们并不需要）。应当这样处理，将接口拆分为最小接口，然后写各个接口的实现类，A类再去调用各个实现类的方法。也就是采用了接口隔离原则。

  1. public static void main(String[] args) {
  2.     A a = new A();
  3.     a.funA1(new B());
  4.     a.funA2(new B());
  5. }
  7. public interface InterfaceOne{
  8.     void fun1();
  9.     void fun2();
  10.     void fun3();
  11.     void fun4();
  12. }
  14. public static class B implements InterfaceOne{
  15.     @Override
  16.     public void fun1(){
  17.         System.out.println("B实现了fun1()");
  18.     }
  19.     @Override
  20.     public void fun2(){
  21.         System.out.println("B实现了fun2()");
  22.     }
  23.     @Override
  24.     public void fun3(){
  25.         System.out.println("B实现了fun3()");
  26.     }
  27.     @Override
  28.     public void fun4(){
  29.         System.out.println("B实现了fun4()");
  30.     }
  31. }
  33. public static class A{
  34.     public void funA1(InterfaceOne i){
  35.         i.fun1();
  36.     }
  37.     public void funA2(InterfaceOne i){
  38.         i.fun2();
  39.     }
  40. }

依赖倒转原则

依赖倒转原则是指：

  • 高层模块不应该依赖低层模块，二者都应该依赖其抽象
  • 抽象不应该依赖其细节，细节应该依赖抽象
  • 依赖倒转的中心思想是面向接口编程
  • 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在Java中，抽象指的是接口或抽象类，细节就是具体的实现类。
  • 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

如下示例：

  1. public static void main(String[] args) {
  2.      Person person = new Person();
  3.      person.receive(new Email());
  4.      person.receive(new Weixin());
  5. }
  7. /**
  8. * 接口定义
  9. */
  10. public interface IReceiver{
  11.     String getInfo();
  12. }
  14. public static class Email implements IReceiver{
  15.     @Override
  16.     public String getInfo() {
  17.         return "电子邮件信息：hello world!";
  18.     }
  19. }
  21. public static class Weixin implements IReceiver{
  22.     @Override
  23.     public String getInfo() {
  24.         return "微信信息：hello world!";
  25.     }
  26. }
  28. public static class Person{
  29.     public void receive(IReceiver receiver){
  30.         System.out.println(receiver.getInfo());
  31.     }
  32. }

这样定义了一个接口IReceiver，通过两个类Email、Weixin来实现该接口。

依赖关系传递的三种方式：

  • 接口传递
  • 构造方法传递
  • setter方式传递

依赖倒转原则的注意事项和细节：

  • 低层模块尽量都要有抽象类和接口，或者两者都有，程序稳定性更好；
  • 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化；
  • 继承时遵循里氏替换原则。

里氏替换原则

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵守这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。 那么如何正确的使用继承？这就需要里氏替换原则！

基本介绍：

  • 里氏替换原则（Liskov Substitution Principle）提出于1988
  • 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象
  • 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
  • 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下可以通过聚合、组合、依赖来解决问题

代码示例如下：

  1. public static void main(String[] args) {
  2.     MyNumber myNumber = new MyNumber();
  3.     System.out.println(myNumber.fun1(1,2));
  4.     System.out.println(myNumber.fun2(1,2));
  5.     NormalNumber normalNumber = new NormalNumber();
  6.     System.out.println(normalNumber.fun1(1, 2));
  7. }
  9. public static class NormalNumber{
  10.     public int fun1(int num1,int num2){
  11.         return num1-num2;
  12.     }
  13. }
  15. public static class MyNumber extends NormalNumber{
  16.     @Override
  17.     public int fun1(int num1, int num2) {
  18.         return num1+num2;
  19.     }
  21.     public int fun2(int num1,int num2){
  22.         return fun1(num1,num2)+10;
  23.     }
  24. }

上述中MyNumber继承了NormalNumber，但是无意间重写了父类的fun1方法，在调用的时候不注意的话会出问题。

在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候。

通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系代替。

开闭原则

基本介绍：

  • 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
  • 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。用抽象构建框架，用实现扩展框架
  • 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化
  • 编程中遵循其他原则以及使用设计模式的目的就是遵循开闭原则

代码示例：

  1. public static void main(String[] args) {
  2.     Square square = new Square();
  3.     square.drawPicture();
  4.     Triangle triangle = new Triangle();
  5.     triangle.drawPicture();
  6. }
  8. public static abstract class Shape{
  9.     public void drawPicture(){
  10.         System.out.println("画一般图形");
  11.     }
  12. }
  14. public static class Square extends Shape{
  15.     @Override
  16.     public void drawPicture() {
  17.         System.out.println("画正方形");
  18.     }
  19. }
  21. public static class Triangle extends Shape{
  22.     @Override
  23.     public void drawPicture() {
  24.         System.out.println("画三角形");
  25.     }
  26. }

上述使用抽象类，其他类只要继承抽象并重写抽象类的方法。

迪米特法则

基本介绍：

  • 一个对象应该对其他对象保持最少的了解
  • 类与类关系越密切。耦合度越大
  • 迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法，只与直接的朋友通信
  • 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方法很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部

迪米特法则注意事项和细节： 1、迪米特法则的核心是降低类之间的耦合 2、但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间（对象间）的耦合关系，并不是要求完全没有依赖关系

合成复用原则

原则是尽量使用合成、聚合的方式，而不是使用继承。