【设计模式——学习笔记】设计模式简介+七大设计原则介绍（上）-阿里云开发者社区

设计模式介绍

简介

设计模式是对软件设计中普遍存在(反复出现) 的各种问题，所提出的解决方案。

为什么学习设计模式

软件要做大，要先进行设计，才能保证其有高的稳定性、扩展性（容易按照新的需求添加功能）、复用性（相同功能的代码，不用多次编写）、规范性、可读性（其他程序员更容易看懂项目的代码）、可维护性、内聚性、灵活性、可靠性（添加新的功能后，对原来的功能没有影响），降低耦合性

工作招聘要求越来越高（问你概念，在项目中用过哪些设计模式，怎么用的）

如果想要成为合格的软件工程师，学习设计模式很有必要

合理使用设计模式，写出来的代码不但结构清晰，有时候效率也会更高

在网站开发中，框架的源码会使用设计模式实现，在写业务代码实现功能的时候，也需要使用到设计模式

设计模式是一种思想，不局限于某种语言，Java、PHP、C#、C++都可以用

七大设计原则介绍

单一职责原则(Single Responsibility Principle)

介绍

一个类只负责一项职责（一项职责并非一个职责，如订单的所有操作叫一项职责；关于商品的操作又是另外一项职责），不然修改其中一项的代码，有可能影响其他的职责

作用

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

案例

原始实现

package com.atguigu.principle.singleresponsibility;
public class SingleResponsibility1 {
   public static void main(String[] args) {
      Vehicle vehicle = new Vehicle();
      vehicle.run("摩托车");
      vehicle.run("汽车");
      vehicle.run("飞机");
   }
}

// 交通工具类
class Vehicle {
   public void run(String vehicle) {
      System.out.println(vehicle + " 在公路上运行....");
   }
}

【运行结果】

摩托车 在公路上运行....
汽车 在公路上运行....
飞机 在公路上运行....
Process finished with exit code 0

【分析】 1. 在Vehicle的run方法中，违反了单一职责原则，飞机不应该在公路上跑 2. 解决的方案非常的简单，根据交通工具运行方法不同，分解成不同类即可

改进一

package com.atguigu.principle.singleresponsibility;
public class SingleResponsibility2 {
   public static void main(String[] args) {
      RoadVehicle roadVehicle = new RoadVehicle();
      roadVehicle.run("摩托车");
      roadVehicle.run("汽车");
      AirVehicle airVehicle = new AirVehicle();
      airVehicle.run("飞机");
   }
}

class RoadVehicle {
   public void run(String vehicle) {
      System.out.println(vehicle + "公路运行");
   }
}

class AirVehicle {
   public void run(String vehicle) {
      System.out.println(vehicle + "天空运行");
   }
}

class WaterVehicle {
   public void run(String vehicle) {
      System.out.println(vehicle + "水中运行");
   }
}

【分析】

遵守单一职责原则
但是这样做的改动很大，即将类分解，同时修改客户端（方法调用端）

【改进】

直接修改Vehicle 类，改动的代码会比较少

改进二

package com.atguigu.principle.singleresponsibility;
public class SingleResponsibility3 {
   public static void main(String[] args) {
      Vehicle2 vehicle2  = new Vehicle2();
      vehicle2.run("汽车");
      vehicle2.runWater("轮船");
      vehicle2.runAir("飞机");
   }
}

//方式3的分析
//1. 这种修改方法没有对原来的类做大的修改，只是增加方法
//2. 这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责
class Vehicle2 {
   public void run(String vehicle) {
      //可以增加其他处理，不影响其他方法
      System.out.println(vehicle + " 在公路上运行....");
   }
   public void runAir(String vehicle) {
      System.out.println(vehicle + " 在天空上运行....");
   }
   public void runWater(String vehicle) {
      System.out.println(vehicle + " 在水中行....");
   }
}

【分析】

这种修改方法没有对原来的类做大的修改，只是增加方法
这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责（只有类中方法数量足够少，可以在方法级别保持单一职责原则，如果方法多了，建议还是拆分成多个类）

接口隔离原则(Interface Segregation Principle)

介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口（拆到最小，依赖的时候每个方法都用得上）上

案例

原始实现

B、D是实现类，A、C使用B、D实现的方法

package com.atguigu.principle.segregation;
public class Segregation1 {
    public static void main(String[] args) {
    }
}

//接口
interface Interface1 {
    void operation1();
    void operation2();
    void operation3();
    void operation4();
    void operation5();
}

class B implements Interface1 {
    public void operation1() {
        System.out.println("B 实现了 operation1");
    }
    public void operation2() {
        System.out.println("B 实现了 operation2");
    }
    public void operation3() {
        System.out.println("B 实现了 operation3");
    }
    public void operation4() {
        System.out.println("B 实现了 operation4");
    }
    public void operation5() {
        System.out.println("B 实现了 operation5");
    }
}

class D implements Interface1 {
    public void operation1() {
        System.out.println("D 实现了 operation1");
    }
    public void operation2() {
        System.out.println("D 实现了 operation2");
    }
    public void operation3() {
        System.out.println("D 实现了 operation3");
    }
    public void operation4() {
        System.out.println("D 实现了 operation4");
    }
    public void operation5() {
        System.out.println("D 实现了 operation5");
    }
}

class A { //A 类通过接口Interface1 依赖(使用) B类，但是只会用到1,2,3方法
    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend2(Interface1 i) {
        i.operation2();
    }
    public void depend3(Interface1 i) {
        i.operation3();
    }
}

class C { //C 类通过接口Interface1 依赖(使用) D类，但是只会用到1,4,5方法
    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend4(Interface1 i) {
        i.operation4();
    }
    public void depend5(Interface1 i) {
        i.operation5();
    }
}

【分析】

类A通过接口Interface1依赖类B，类c通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法
将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

接口interface1中出现的方法，根据实际情况拆分为三个接口

改进

package com.atguigu.principle.segregation.improve;
public class Segregation1 {
    public static void main(String[] args) {
        // 使用一把
        A a = new A();
        a.depend1(new B()); // A类通过接口去依赖B类
        a.depend2(new B());
        a.depend3(new B());
        C c = new C();
        c.depend1(new D()); // C类通过接口去依赖(使用)D类
        c.depend4(new D());
        c.depend5(new D());
    }
}

// 接口1
interface Interface1 {
    void operation1();
}

// 接口2
interface Interface2 {
    void operation2();
    void operation3();
}

// 接口3
interface Interface3 {
    void operation4();
    void operation5();
}

class B implements Interface1, Interface2 {
    public void operation1() {
        System.out.println("B 实现了 operation1");
    }
    public void operation2() {
        System.out.println("B 实现了 operation2");
    }
    public void operation3() {
        System.out.println("B 实现了 operation3");
    }
}

class D implements Interface1, Interface3 {
    public void operation1() {
        System.out.println("D 实现了 operation1");
    }
    public void operation4() {
        System.out.println("D 实现了 operation4");
    }
    public void operation5() {
        System.out.println("D 实现了 operation5");
    }
}

class A { // A 类通过接口Interface1,Interface2 依赖(使用) B类，但是只会用到1,2,3方法
    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend2(Interface2 i) {
        i.operation2();
    }
    public void depend3(Interface2 i) {
        i.operation3();
    }
}

class C { // C 类通过接口Interface1,Interface3 依赖(使用) D类，但是只会用到1,4,5方法
    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend4(Interface3 i) {
        i.operation4();
    }
    public void depend5(Interface3 i) {
        i.operation5();
    }
}

依赖倒转(倒置)原则(Dependence Inversion Principle)

介绍

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

案例

原始实现

package com.atguigu.principle.inversion;
public class DependecyInversion {
   public static void main(String[] args) {
      Person person = new Person();
      person.receive(new Email());
   }
}

class Email {
   public String getInfo() {
      return "电子邮件信息: hello,world";
   }
}

//完成Person接收消息的功能
class Person {
   // 直接依赖具体的类
   public void receive(Email email) {
      System.out.println(email.getInfo());
   }
}

【分析】

优点：简单，比较容易想到
缺点：如果我们获取的对象是微信，短信等等，则需要新增类，同时Person也要增加相应的接收方法

【改进】

引入一个抽象的接口IRecceiver, 表示接收者, 这样Person类与接口IReceiver发生依赖因为Email, WeiXin 等等属于接收的范围，他们各自实现IReceiver 接口就ok, 这样我们就符合依赖倒转原则

改进

package com.atguigu.principle.inversion.improve;
public class DependecyInversion {
   public static void main(String[] args) {
      //客户端无需改变
      Person person = new Person();
      person.receive(new Email());
      person.receive(new WeiXin());
   }
}

//定义接口
interface IReceiver {
   public String getInfo();
}

class Email implements IReceiver {
   public String getInfo() {
      return "电子邮件信息: hello,world";
   }
}

//增加微信
class WeiXin implements IReceiver {
   public String getInfo() {
      return "微信信息: hello,ok";
   }
}

//方式2
class Person {
   //改成依赖接口
   public void receive(IReceiver receiver ) {
      System.out.println(receiver.getInfo());
   }
}

依赖传递的三种方式

package com.atguigu.principle.inversion.improve;
public class DependencyPass {
    public static void main(String[] args) {
      ChangHong changHong = new ChangHong();
      OpenAndClose openAndClose = new OpenAndClose();
      openAndClose.open(changHong);
    }
}

// 方式1： 通过接口传递实现依赖
//     开关的接口
interface IOpenAndClose {
   public void open(ITV tv); //抽象方法,接收接口
}

interface ITV { //ITV接口
   public void play();
}

class ChangHong implements ITV {
   @Override
   public void play() {
      System.out.println("长虹电视机，打开");
   }
}

// 实现接口
class OpenAndClose implements IOpenAndClose {
   public void open(ITV tv) {
      tv.play();
   }
}

package com.atguigu.principle.inversion.improve;
public class DependencyPass {
    public static void main(String[] args) {
      ChangHong changHong = new ChangHong();
      //通过构造器进行依赖传递
      OpenAndClose openAndClose = new OpenAndClose(changHong);
      openAndClose.open();
    }
}

// 方式2:通过构造方法依赖传递
interface IOpenAndClose {
    public void open(); //抽象方法
}

interface ITV { //ITV接口
    public void play();
}

class OpenAndClose implements IOpenAndClose {
    public ITV tv; //成员
    public OpenAndClose(ITV tv) { //构造器
        this.tv = tv;
    }
    public void open() {
        this.tv.play();
    }
}

class ChangHong implements ITV {
    @Override
    public void play() {
        System.out.println("长虹电视机，打开");
    }
}

package com.atguigu.principle.inversion.improve;
public class DependencyPass {
    public static void main(String[] args) {
        ChangHong changHong = new ChangHong();
        //通过setter方法进行依赖传递
        OpenAndClose openAndClose = new OpenAndClose();
        openAndClose.setTv(changHong);
        openAndClose.open();
    }
}

// 方式3,通过setter方法传递
interface IOpenAndClose {
    public void open(); // 抽象方法
    public void setTv(ITV tv);
}

interface ITV { // ITV接口
    public void play();
}

class OpenAndClose implements IOpenAndClose {
    private ITV tv;
    public void setTv(ITV tv) {
        this.tv = tv;
    }
    public void open() {
        this.tv.play();
    }
}

class ChangHong implements ITV {
    @Override
    public void play() {
        System.out.println("长虹电视机，打开");
    }
}

总结

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

这句话的意思是，使用抽象类或接口作为变量类型，可以降低代码的耦合度。通过引入抽象层，将具体的实现细节与变量引用分离开来。这样一来，当需要拓展或修改程序时，只需要修改具体实现类，而无需修改引用该变量的其他代码。 A obj1=new B(); 或者 A obj2=new C(); 
此外，还可以增强代码的扩展性。如果需要添加新的功能或实现，只需要实现相应的接口或继承相应的抽象类，并将其赋值给变量引用即可，无需修改原有代码。
最后，还可以方便地进行性能优化。通过更换具体实现类，可以根据实际需求选择不同的实现方式，从而达到最佳性能。
以下是一个具体的例子：
假设我们有一个形状类 Shape，它有一个抽象方法 getArea()，需要子类来实现具体的计算面积的方法，如圆形类 Circle 和矩形类 Rectangle。
如果我们要写一个计算图形面积的程序，可以这样声明变量：
Shape[] shapes = new Shape[2];
shapes[0] = new Circle(5); // 半径为 5 的圆形
shapes[1] = new Rectangle(3, 4); // 长为 3，宽为 4 的矩形
这里我们采用了 Shape 类作为变量类型，而不是具体的 Circle 或 Rectangle 类。这样做有以下好处：
降低代码耦合度：其他代码引用 shapes 数组时只需要知道它是 Shape 类型，不需要知道具体是哪个子类实现了它。
增强程序扩展性：如果我们要添加新的形状，只需要实现 Shape 的方法即可，而不需要修改其他代码。
方便性能优化：如果程序更偏向于计算圆形面积，我们可以使用更高效的圆形实现类来替换原有的 Circle 类，只需要修改创建 Circle 实例的代码即可，其他代码不需要做任何修改。

继承时遵循里氏替换原则

里氏替换原则

介绍

告诉我们继承需要注意什么问题

【使用继承会带来的问题】

继承包含这样一层含义:父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约（子类可以重写父类已经实现的方法），但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏

继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性（如果一个类被其他的类所继承则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障）

如何正确的使用继承？答：需要遵守里氏替换原则

【里氏替换原则】

里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院的以为姓里的女士提出的

如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类（父类）的地方必须能透明地使用其子类的对象(使用基类对象的任何地方，都可以替换为子类对象而不会影响代码的正确性。换句话说，基类对象的行为和子类对象的行为应该是一致的，不应该有任何差别。)

在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法(如果重写了，就不再透明，调用子类的方法和调用父类的方法不同)

里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题

案例

原始实现

package com.atguigu.principle.liskov;
public class Liskov {
   public static void main(String[] args) {
      A a = new A();
      System.out.println("11-3=" + a.func1(11, 3));
      System.out.println("1-8=" + a.func1(1, 8));
      System.out.println("-----------------------");
      B b = new B();
      //这里程序员的本意是求出11-3，忘记父类的方法被重写了
      System.out.println("11-3=" + b.func1(11, 3));
      System.out.println("1-8=" + b.func1(1, 8));// 1-8
      System.out.println("11+3+9=" + b.func2(11, 3));
   }
}

// A类
class A {
   // 返回两个数的差
   public int func1(int num1, int num2) {
      return num1 - num2;
   }
}

// B类继承了A
// 增加了一个新功能：完成两个数相加,然后和9求和
class B extends A {
   //这里，重写了A类的方法, 可能是无意识
   public int func1(int a, int b) {
      return a + b;
   }
   public int func2(int a, int b) {
      return func1(a, b) + 9;
   }
}

【分析】

我们发现原来运行正常的相减功能发生了错误。原因就是类B无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候

【改进】

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

改进

组合：B类还需要使用到A类的方法

package com.atguigu.principle.liskov.improve;
public class Liskov {
   public static void main(String[] args) {
      // TODO Auto-generated method stub
      A a = new A();
      System.out.println("11-3=" + a.func1(11, 3));
      System.out.println("1-8=" + a.func1(1, 8));
      System.out.println("-----------------------");
      B b = new B();
      System.out.println("11+3=" + b.func1(11, 3));//这里本意是求出11+3
      System.out.println("1+8=" + b.func1(1, 8));// 1+8
      System.out.println("11+3+9=" + b.func2(11, 3));
      //使用组合仍然可以使用到A类相关方法
      System.out.println("11-3=" + b.func3(11, 3));// 这里本意是求出11-3
   }
}

//创建一个更加基础的基类
class Base {
   //把更加基础的方法和成员写到Base类
}

// A类
class A extends Base {
   // 返回两个数的差
   public int func1(int num1, int num2) {
      return num1 - num2;
   }
}

// B类继承了A
// 增加了一个新功能：完成两个数相加,然后和9求和
class B extends Base {
   //如果B需要使用A类的方法,使用组合关系
   private A a = new A();
   //这里，重写了A类的方法, 可能是无意识
   public int func1(int a, int b) {
      return a + b;
   }
   public int func2(int a, int b) {
      return func1(a, b) + 9;
   }
   //我们仍然想使用A的方法
   public int func3(int a, int b) {
      return this.a.func1(a, b);
   }
}

【分析】

使用这种方式，降低了A和B之间的耦合度
因为B类不再继承A类，因此调用者，不会再认为func1是求减法，调用完成的功能就会很明确

【设计模式——学习笔记】设计模式简介+七大设计原则介绍（上）

设计模式介绍

简介

为什么学习设计模式

七大设计原则介绍

单一职责原则(Single Responsibility Principle)

介绍

作用

案例

原始实现

改进一

改进二

接口隔离原则(Interface Segregation Principle)

介绍

案例

原始实现

改进

依赖倒转(倒置)原则(Dependence Inversion Principle)

介绍

案例

原始实现

改进

依赖传递的三种方式

总结

里氏替换原则

介绍

案例

原始实现

改进

热门文章

最新文章

相关课程

相关电子书