设计模式01 七大原则

willA笔记更新ing
361 阅读17分钟

完整设计模式学习笔记请戳

设计模式概括

设计模式的提出

软件工程中，设计模式是对软件设计中普遍存在或反复出现的各种问题，所提出的解决方案。这个术语是由埃里希·伽马（Erich Gamma）等人在1990年代从建筑设计领域引入到计算机科学的。
设计模式是针对软件的 复用性、扩展性、维护性（可读性、规范性）、稳定性等

设计模式七大原则（很多书上写的是六种）

  • 单一职责原则
  • 接口隔离原则
  • 依赖倒转原则
  • 里式替换原则
  • 开闭原则 ocp
  • 迪米特法则
  • 合成复用原则（一般书上不包含这一点）

设计模式在软件中的哪里？

面向对象（oo）=>功能模块【设计模式+算法(数据结构)】=>框架【使用多种设计模式】=>架构【服务器集群】

设计模式的目的

编写软件过程中，程序员面临着来自耦合性、内聚性以及可维护性、可扩展性、重用性、灵活性等多方面的挑战，设计模式是为了让程序（软件）具有更好的

  • 代码重用性：相同功能的代码，不用多次编写
  • 可读性：即编程规范性，便于其他程序猿阅读和理解
  • 可扩展性（可维护性）：当需要增加新的功能时，非常方便
  • 可靠性：增加新的功能时，对原来的功能没有影响
  • 使程序呈现高内聚，低耦合的特性

分析金句
设计模式包含了面向对象的精髓,"懂了设计模式,你就懂了面向对象分析和设计（OOA/D）的精要"。Scott Mayers在其巨著《Effective C++》就曾经说过：C++老手和C++新手的区别就是前者手背上有很多伤疤

1.单一职责原则

对类来说，一个类应该只负责一项职责。如果A类负责两个不同职责：职责1，职责2.当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2

注意事项和细节

  • 降低类的复杂度，一个类只负责一项职责
  • 提高类的可读性，可维护性
  • 降低变更的风险
  • 通常情况下，应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有在类中的方法数量足够少，可以在方法级别保持单一职责原则
  • 如下代码即是在方法级别保持了单一职责原则：
public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.run("汽车");
        vehicle2.runAir("飞机");
        vehicle2.runWater("船");
    }
}
//方案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+"在水中跑...");
    }
}

2. 接口隔离原则

基本介绍：

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

例

  1. Interface1接口中有5个方法
  2. B和D实现了接口Interface1
  3. A类通过接口 Interface1 依赖B类，但是只会用到1，2，3方法
  4. C类通过接口 Interface1 依赖D类，但是只会用到1，4，5方法

不使用接口隔离原则

改进，使用接口隔离原则

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

代码实现

/**
 * @author DSH
 * @date 2020/5/11
 * @description 接口隔离原则
 */
public class Segregation2 {
    public static void main(String[] args) {
        A2 a = new A2();
        a.depend1(new B2());//A通过接口依赖B
        a.depend2(new B2());
        a.depend3(new B2());

        C2 c = new C2();
        c.depend1(new D2());
        c.depend4(new D2());
        c.depend5(new D2());
    }
}

interface Interface1{
    void operation1();
}

interface Interface2{
    void operation2();
    void operation3();
}

interface Interface3{
    void operation4();
    void operation5();
}

class B2 implements Interface1,Interface2{

    @Override
    public void operation1() {
        System.out.println("B operation1");
    }

    @Override
    public void operation2() {
        System.out.println("B operation2");
    }

    @Override
    public void operation3() {
        System.out.println("B operation3");
    }


}

class D2 implements Interface1,Interface3{

    @Override
    public void operation1() {
        System.out.println("D operation1");
    }

    @Override
    public void operation4() {
        System.out.println("D operation4");
    }

    @Override
    public void operation5() {
        System.out.println("D operation5");
    }
}

class A2 {
    //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 C2 {
    //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();
    }
}

3.依赖倒转原则

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

例

不使用依赖倒转原则 方案1

public class DependencyInversion {
    public static void main(String[] args) {
        //方案1
        Person person = new Person();
        person.receive(new Email());
        //方案2
        Person2 person2 = new Person2();
        person2.receive(new Email2());
        person2.receive(new Weixin2());
    }
}

//完成Person接收消息的功能
//方式1
// 1.简单 ，容易实现
// 2.如果我们获取的对象时微信、短信等等，则新增类，同时Person也要增加相应的接收方法
// 3. 解决思路，引入抽象的接口IReceiver，表示接收者，这样Person类与接口发生依赖
// 4. Email 微信 短信等都属于接收者的范围，他们各自实现IReceiver，这样就符合依赖倒转原则
class Person{
    public void receive(Email email){
        System.out.println(email.getInfo());
    }
}

class Email{
    public String getInfo(){
        return "email info ：hello girl!";
    }
}

使用依赖倒转原则 方案2

接口

public interface IReceiver {
    String getInfo();
}

实现类

public class Weixin2 implements IReceiver {
    @Override
    public String getInfo() {
        return "weixin info ：";
    }
}

public class Email2 implements IReceiver {
    @Override
    public String getInfo() {
        return "email info ：";
    }
}

接口接收对象

public class Person2 {
    public void receive(IReceiver email){
        System.out.println(email.getInfo());
    }
}

测试代码

    //方案2
    Person2 person2 = new Person2();
    person2.receive(new Email2());
    person2.receive(new Weixin2());

依赖关系传递的三种方式

  • 1）接口传递
  • 2）构造方法传递
  • 3）setter方式传递
/**
 * @author DSH
 * @date 2020/5/12
 * @description  依赖关系传递的三种方式
 */
public class DependencyPass {
    public static void main(String[] args) {
        AppleTV appleTV = new AppleTV();
        //1 接口依赖
        OpenAndClose openAndClose = new OpenAndClose();
        openAndClose.open(appleTV);
        //2 构造器依赖
        OpenAndClose2 openAndClose2 = new OpenAndClose2(appleTV);
        openAndClose2.open();
        // 3 setter方式依赖
        OpenAndClose3 openAndClose3 = new OpenAndClose3();
        openAndClose3.setTv(appleTV);
        openAndClose3.open();
    }
}


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

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

class OpenAndClose implements IOpenAndClose{

    @Override
    public void open(ITV tv) {
        tv.play();
    }
}

//方式2 通过构造方法传递依赖
interface IOpenAndClose2{
    void open();//抽象方法，接收接口
}

class OpenAndClose2 implements IOpenAndClose2{
    public ITV itv;//成员

    public OpenAndClose2(ITV tv) {
        this.itv =tv;
    }
    @Override
    public void open(){
        itv.play();
    }
}

//方式3  setter方式传递
//开关的接口
interface IOpenAndClose3{
    void open();//抽象方法，接收接口
    void setTv(ITV tv);
}

class OpenAndClose3  implements IOpenAndClose3{
    public ITV itv;//成员

    @Override
    public void open() {
        this.itv.play();
    }

    @Override
    public void setTv(ITV tv) {
        this.itv =tv;
    }
}

//ITV实现类
class AppleTV implements ITV{

    @Override
    public void play() {
        System.out.println("打开了Apple TV");
    }
}

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

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

4. 里式替换原则

OO中的继承性的思考和说明

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

里式替换原则基本介绍

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

例

以下代码中B类重写了A类方法，导致输出不符合期待

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));

        B b = new B();
        System.out.println("11-3="+b.func1(11,3));//B类重写了A类的方法
        System.out.println("1-8="+b.func1(1,8));
        System.out.println("11+3+9="+b.func2(11,3));
    }
}

class A{
    public int func1(int num1,int num2){
        return num1-num2;
    }
}

class B extends A{

    //开发人员可能无意间重写了A类的func1方法，导致测试代码输出与期待不符
    @Override
    public int func1(int a, int b) {
        return a+b;
    }

    public int func2(int a, int b) {
        return func1(a,b)+9;
    }
}

解决方式

  • 由于B类中无意重写了父类的方法，造成原有功能出现错误。在实际编程中，常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候
  • 通用的做法是，原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合灯关系替代

改进后

public class LiskovImprove {
    public static void main(String[] args) {
        A2 a = new A2();
        System.out.println("11-3="+a.func1(11,3));
        System.out.println("1-8="+a.func1(1,8));

        B2 b = new B2();
        //因为B类不再继承A类，因此调用者不会再任务func1是求减法，抵用完成功能就会很明确
        System.out.println("11+3="+b.func1(11,3));//B类重写了A类的方法
        System.out.println("1+8="+b.func1(1,8));
        System.out.println("11+3+9="+b.func2(11,3));

        //使用组合仍然可以使用A的方法
        System.out.println("11-3="+b.func3(11,3));
    }
}

class Base{

}

class A2 extends Base{
    public int func1(int num1,int num2){
        return num1-num2;
    }
}

class B2 extends Base{
    //如果B需要使用A类的方法，使用组合
    private A a = new 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);
    }

}

5.开闭原则

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

例

方式1

  • 这种方式比较好理解，简单易操作
  • 缺点是违反了设计模式的OCP原则，即对外扩展开放（提供方），对修改关闭（使用方），即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码
  • 比如需要增加一个新的图形的时候，修改的地方比较多
/**
 * @author DSH
 * @date 2020/5/12
 * @description 开闭原则
 */
public class OCP {
    public static void main(String[] args) {
        GraphicEditor editor = new GraphicEditor();
        editor.drawShape(new Circle());
        editor.drawShape(new Retangle());
        editor.drawShape(new Triangle());
    }
}

//绘图类(使用方)
class GraphicEditor{
    public void drawShape(Shape s){
        if (s.m_type==1){
            drawRetangle(s);
        }else if (s.m_type==2){
            drawCircle(s);
        }else if (s.m_type==3){
            drawTriangle(s);
        }
    }

    private void drawCircle(Shape s) {
        System.out.println("画一个圆形");
    }

    private void drawRetangle(Shape s) {
        System.out.println("画一个矩形");
    }

    private void drawTriangle(Shape s){
        System.out.println("画一个三角形");
    }

}

class Shape{
    int m_type;
}

class Retangle extends Shape{
    Retangle(){
        m_type = 1;
    }
}

class Circle extends Shape{
    Circle(){
        m_type = 2;
    }
}

class Triangle extends Shape{
    Triangle(){
        m_type = 3;
    }
}

方式2 OCP优化

把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可， 这样当需要新的图形种类时，只需要让新的图形种类继承Shape，并实现draw方法即可

public class OCP2 {
    public static void main(String[] args) {
        GraphicEditor2 editor = new GraphicEditor2();
        editor.drawShape(new Circle2());
        editor.drawShape(new Retangle2());
        editor.drawShape(new Triangle2());
    }
}

//绘图类(使用方)
class GraphicEditor2{
    public void drawShape(Shape2 s){
        s.draw();
    }
}

abstract class Shape2{
    abstract void draw();
}

class Retangle2 extends Shape2{
    @Override
    void draw() {
        System.out.println("画一个矩形");
    }
}

class Circle2 extends Shape2{
    @Override
    void draw() {
        System.out.println("画一个圆");
    }
}

class Triangle2 extends Shape2{
    @Override
    void draw() {
        System.out.println("画一个三角形");
    }
}

6. 迪米特法则

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

例

有一个学校，下属有各个学院和总部，现要求打印出学校总部员工ID和学院员工ID

不使用迪米特原则

分析如下代码：

  1. 对于SchoolManage而言，他的直接朋友是Employee ，CollegeManage
  2. CollegeEmployee不是SchoolManage的直接朋友
  3. CollegeEmployee是以局部变量的方式出现在SchoolManage
  4. 违反了迪米特原则
//客户端
public class Demeter1 {
    public static void main(String[] args) {
        CollegeManage manage = new CollegeManage();
        SchoolManage schoolManage = new SchoolManage();
        schoolManage.printAllEmployee(manage);
    }
}

//总部雇员
class Employee{
    private String id;

    public void setId(String id) {
        this.id = id;
    }

    public String getId() {
        return id;
    }
}

//分院雇员
class CollegeEmployee{
    private String id;

    public void setId(String id) {
        this.id = id;
    }

    public String getId() {
        return id;
    }
}

//学院员工管理类
class CollegeManage{
    public List<CollegeEmployee> getAllEmployee(){
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            CollegeEmployee employee = new CollegeEmployee();
            employee.setId("学院员工id="+i);
            list.add(employee);
        }
        return list;
    }
}

//学校管理类 总部员工
//直接朋友 Employee ，CollegeManage
//不是直接朋友 CollegeEmployee
class SchoolManage{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Employee employee = new Employee();
            employee.setId("学院总部员工id="+i);
            list.add(employee);
        }
        return list;
    }

    void printAllEmployee(CollegeManage sub){
        //1 CollegeEmployee不是SchoolManage的直接朋友
        //2 CollegeEmployee是以局部变量的方式出现在SchoolManage
        //3 违反了迪米特原则
        List<CollegeEmployee> collegeList = sub.getAllEmployee();
        System.out.println("----------分院员工---------");
        for (CollegeEmployee employee:collegeList){
            System.out.println(employee.getId());
        }
        List<Employee> schoolList = this.getAllEmployee();
        System.out.println("----------学校总部员工---------");
        for (Employee employee:schoolList){
            System.out.println(employee.getId());
        }
    }
}

使用迪米特原则优化代码

上面的代码问题在于SchoolManage中，CollegeEmployee类并不是SchoolManage的直接朋友，按照迪米特原则，应该避免类中出现这样非直接朋友关系的耦合

代码优化：
将输出学院员工的方法，封装到CollegeManage

//学院员工管理类
class CollegeManage2{
    public List<CollegeEmployee2> getAllEmployee(){
        List<CollegeEmployee2> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            CollegeEmployee2 employee = new CollegeEmployee2();
            employee.setId("学院员工id="+i);
            list.add(employee);
        }
        return list;
    }
    
    public void printEmplyee(){
        List<CollegeEmployee2> collegeList = this.getAllEmployee();
        System.out.println("----------分院员工---------");
        for (CollegeEmployee2 employee:collegeList){
            System.out.println(employee.getId());
        }
    }
}

//学校管理类 总部员工
//直接朋友 Employee ，CollegeManage
//不是直接朋友 CollegeEmployee
class SchoolManage2{
    public List<Employee2> getAllEmployee(){
        List<Employee2> list = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Employee2 employee = new Employee2();
            employee.setId("学院总部员工id="+i);
            list.add(employee);
        }
        return list;
    }

    void printAllEmployee(CollegeManage2 sub){
        sub.printEmplyee();
        List<Employee2> schoolList = this.getAllEmployee();
        System.out.println("----------学校总部员工---------");
        for (Employee2 employee:schoolList){
            System.out.println(employee.getId());
        }
    }
}

注意事项和细节

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

7.合成复用原则

合成复用原则（Composite Reuse Principle）：原则是尽量使用合成/聚合的方式，而不是使用继承

例

B使用A类的相关方法，有以下几种实现方式

  • 继承：B和A的耦合太强
  • 组合：符合合成复用原则
  • 聚合：符合合成复用原则

总结

设计模式的核心思想

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

独孤求败5重境界

  • 第一境界：利剑“凌厉刚猛，无坚不摧，弱冠前以之与河朔群雄争锋。
  • 第二境界：软剑，“紫薇软剑，三十岁前所用，误伤义士不祥，乃弃之深谷。
  • 第三境界：重剑，“重剑无锋，大巧坏工。四十岁前恃之横行天下。”
  • 第四境界：木剑，“四十岁后，不滞于物，草木竹石均可为剑。”
  • 第五境界：无剑，“自此精修，渐进于无剑胜有剑之境。”

设计模式分为三种类型，共23种

  • 1）创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。
  • 2）结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
  • 3）行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式（责任链模式）。

注意：不同的书籍上对分类和名称略有差别


设计模式学习代码及笔记）

【代码】
github.com/willShuhuan…
【笔记】
设计模式01 七大原则
设计模式02 类关系与UML类图
设计模式03 创建型模式1-单例+工厂
设计模式04 创建型模式2-原型+建造者
设计模式05 结构型模式1-适配器+桥接+装饰者
设计模式06 结构型模式2-组合+外观+享元+代理
设计模式07 行为型模式1-模板方法+命令+访问者
设计模式08 行为型模式2-迭代器+观察者+中介者
设计模式09 行为型模式3-备忘录+解释器+状态
设计模式10 行为型模式4-策略+职责链

avatar
文章
阅读
粉丝