设计模式初始介绍

设计模式

1、设计模式七大原则：

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

2、设计模式的重要性

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

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

​ 可扩展性、维护性[可读性、规范性]

• 代码重用性（相同功能得代码，不用多次编写）
• 可读性（编程规范性，便于其他程序员得阅读和理解）
• 可扩展性（当增加新的功能后，对原来得功能没有影响）
• 可靠性（当我们增加新的功能后，对原来的功能没有影响）
• 使程序呈现高内聚、低耦合得特性

七大原则介绍

单一职责原则

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

案例1

package com.lch.principle.singleresponsibility;

/**
 * @author lch
 * @version v1.0
 * @description:
 * @date 2022/5/18 15:20
 * @change [修改时间] [修改者]@[版本号] [修改内容说明]
 */
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+" 在路上运行。。。");
    }
}

案列2

遵循单一职责原则，改动很大，类被分解，同时修改客户端

package com.lch.principle.singleresponsibility;

/**
 * @author lch
 * @version v1.0
 * @description:
 * @date 2022/5/18 15:20
 * @change [修改时间] [修改者]@[版本号] [修改内容说明]
 */
public class SingleResponsibility2 {

    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("汽车");
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飞机");
        WaterVehicle waterVehicle = new WaterVehicle();
        waterVehicle.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+" 在水里运行。。。");
    }
}

案例3

这种修改类中的方法，对原来的类没有做出大的改变，只是增加了方法。

虽然在类的级别没有遵守单一职责，但是在方法级别上遵守了单一职责原则。

package com.lch.principle.singleresponsibility;

/**
 * @author lch
 * @version v1.0
 * @description:
 * @date 2022/5/18 15:20
 * @change [修改时间] [修改者]@[版本号] [修改内容说明]
 */
public class SingleResponsibility3 {

    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.roadRun("汽车");
        vehicle2.airRun("飞机");
        vehicle2.waterRun("轮船");
    }
}

class Vehicle2{

    public void roadRun(String vehicle){
        System.out.println(vehicle+" 在路上运行。。。");
    }
    public void airRun(String vehicle){
        System.out.println(vehicle+" 在天空运行。。。");
    }
    public void waterRun(String vehicle){
        System.out.println(vehicle+" 在水里运行。。。");
    }
}

单一职责原则注意事项和细节

​ 1）降低类得复杂度，一个类只负责一项职责

​ 2）提高类的可读性，可维护性

​ 3）降低变更引起得风险

​ 4）通常情况下，我们应当遵守单一职责原则，只要逻辑足够简单，才可以违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一原则

接口隔离原则（Interface Segregation Principle）

​ 基本介绍

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

​ 2）类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口，那么类B和类D必须实现他们不需要的方法。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eChrhn7g-1659083513540)(image/5b116bad949443557cc5cfd4e88b1a6c.png)]

• 按隔离原则应当这样处理：

将接口Interface1拆分成独立的几个接口**（这里我们拆分成3个接口）**，类A和类C分别与他们需要的接口简历依赖关系。也就是采用接口隔离原则。

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OdAJ54IP-1659083513541)(image/1653978906309.png)]

案例1，未使用接口隔离原则

类A通过接口Interface1依赖类B，类C通过Interface1依赖类D。

//接口，且拥有5个方法
interface Interface1 {
    void method1();
    void method2();
    void method3();
    void method4();
    void method5();
}

//A类通过Interface1接口依赖(使用) B类，但只用到1,2,3方法
class A{
    public void depend1(Interface1 interface1){
         interface1.method1();
    }
    public void depend2(Interface1 interface1){
        interface1.method2();
    }
    public void depend3(Interface1 interface1){
        interface1.method3();
    }
}

//B类实现Interface1
class B implements Interface1 {
    @Override
    public void method1() {
        System.out.println("B 实现method1");
    }
    @Override
    public void method2() {
        System.out.println("B 实现method2");
    }
    @Override
    public void method3() {
        System.out.println("B 实现method3");
    }
    @Override
    public void method4() {
        System.out.println("B 实现method4");
    }
    @Override
    public void method5() {
        System.out.println("B 实现method5");
    }
}

//C类通过Interface1接口依赖(使用) D类，但只用到1,4,5方法
class C{
    public void depend1(Interface1 interface1){
        interface1.method1();
    }
    public void depend4(Interface1 interface1){
        interface1.method4();
    }
    public void depend5(Interface1 interface1){
        interface1.method5();
    }
}

//D类实现Interface1
class D implements Interface1{
    @Override
    public void method1() {
        System.out.println("D 实现method1");
    }
    @Override
    public void method2() {
        System.out.println("D 实现method2");
    }
    @Override
    public void method3() {
        System.out.println("D 实现method3");
    }
    @Override
    public void method4() {
        System.out.println("D 实现method4");
    }
    @Override
    public void method5() {
        System.out.println("D 实现method5");
    }
}

案例2：使用接口隔离原则

类A通过接口Interface1和接口Interface2依赖类B，类C通过接口Interface1和接口Interface3依赖类D，只实现了需要的方法，遵守了接口隔离原则

package com.lch.principle.segregation;

/**
 * @author lch
 * @version v1.0
 * @description: 接口隔离原则
 * @date 2022/5/31 14:37
 * @change [修改时间] [修改者]@[版本号] [修改内容说明]
 */
public class Segregation1 {
    public static void main(String[] args) {
        A a = new A();
        B b = new B();
        a.operation1(b);
        a.operation2(b);
        a.operation3(b);
        C c = new C();
        D d = new D();
        c.operation1(d);
        c.operation4(d);
        c.operation5(d);
    }
}

interface Interface1{
    void operation1();
}

interface Interface2{
    void operation2();
    void operation3();
}
interface Interface3{
    void operation4();
    void operation5();
}

class B implements Interface1,Interface2{
    @Override
    public void operation1() {
        System.out.println("operation1");
    }

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

    @Override
    public void operation3() {
        System.out.println("operation3");
    }
}
class D implements Interface1,Interface3{
    @Override
    public void operation1() {
        System.out.println("operation1");
    }

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

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

class A{
    public void operation1(Interface1 interface1){
        interface1.operation1();
    }
    public void operation2(Interface2 interface2){
        interface2.operation2();
    }
    public void operation3(Interface2 interface2){
        interface2.operation3();
    }
}

class C{
    public void operation1(Interface1 interface1){
        interface1.operation1();
    }
    public void operation4(Interface3 interface3){
        interface3.operation4();
    }
    public void operation5(Interface3 interface3){
        interface3.operation5();
    }
}

依赖倒转原则

基本介绍

依赖倒转原则（Dependence Inversion Principle）是指：

1）高层模块不应该依赖低层模块，二者都应该依赖其抽象

2）抽象不应该依赖细节，细节应该依赖抽象

3）依赖倒转（倒置）的中心思想是面向接口编程

4）依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。再Java中，抽象指的是接口或抽象类，细节就是具体的实现类

5）使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展示细节的任务交给他们的实现类(子类)完成

依赖关系传递的三种方式和应用案例

1）接口传递 2）构造方法传递 3）setter方式传递

案例1：传统写法 当前使用的是电子邮件类，但如果接收的方式修改为微信、短信等方式，则Person类中就要添加新的接收方法。（缺点：难以扩展，会造成代码冗余）

//测试
public class DependecyInversion {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

class Email{
    public String getInfo(){
        return "电子信息：hello!你好";
    }
}

class Person{
    public void receive(Email email){
        System.out.println(email.getInfo());
    }
}

解决方案:

引入一个抽象的接口IReceiver，表示接收者，这样Person类依赖IReceiver，因为Email、微信、短信等都属于接收范围，则他们都可以实现IReceiver接口，这样就符合依赖倒转原则

案例2—符合依赖倒转原则

package com.lch.principle.inversion;

/**
 * @author lch
 * @version v1.0
 * @description:
 * @date 2022/6/14 14:59
 * @change [修改时间] [修改者]@[版本号] [修改内容说明]
 */
public class DependecyInversion2 {

    public static void main(String[] args) {
        new Person().receive(new Wexin());
    }
}

//人
class Person{

    /**
     * 接收消息
     * 不依赖某一个具体的消息，依赖于接收这个范围，符合依赖倒置原则
     */
    public void receive(IReceiver iReceiver){
        System.out.println(iReceiver.getInfo());
    }
}

//接收者
interface IReceiver{

     String getInfo();
}

//邮箱类
class Email implements IReceiver{
    @Override
    public String getInfo() {
        return "接收邮箱信息";
    }
}

class Wexin implements IReceiver{
    @Override
    public String getInfo() {
        return "接收微信信息";
    }
}

class ShortMessage implements IReceiver{
    @Override
    public String getInfo() {
        return "接收短信信息";
    }
}

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

1）底层模块尽量都要有抽象类和接口，或者两者都有，程序稳定性更好。

2）变量的声明类型尽量是抽象类或者接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化。

3）继承时遵循里氏替换原则

里氏替换原则

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

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

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

3）问题提出：在编程中如何正确的使用继承？ => 里氏替换原则

基本介绍

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

2）如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序p的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类地对象。

3）在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类地方法。

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

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

3）问题提出：在编程中如何正确的使用继承？ => 里氏替换原则

基本介绍

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

2）如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序p的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类地对象。

3）在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类地方法。

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