// 方式1
// 1.在方式1的run方法中，违反了单一职责原则
// 2. 解决的方案非常的简单，根据交通工具运行方法不同，分解成不同类即可
class Vehicle {
    public void run(String vehicle)
        System.out.println(vehicle+"在公路上运行..");
    }
}

// 方案2的分析
// 1.遵守单- -职责原则
// 2.但是这样做的改动很大，即将类分解，同时修改客户端
// 改进:直接修改Vehicle类，改动的代码会比较少=>方案3
class WaterVelhjicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "水中运行");
    }
}

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


// 方式3
// 1.这种修改方法没有对原来的类做大的修改，只是增加方法
// 2. 这里虽然没有在类这个级别上遵守单一 职责原则，但是在方法级别上，仍然是遵守单一职责
class Vehicle2 {
    public void run(String vehicle) {
        //处理

        System.out.println(vehicle+"在公路上运行..");
    }

    public void runAir(String vehicle) {
        System.out.println(vehicle+"在天空上运行...");
    }
}

2.4 接口隔离原则

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

例子

下图是我们编码中遇到的常见问题：

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

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

class B implements Interface1 {
    void operation1() {
        System. out. println();
    }
    void operation2(){
        System. out. println();
    }
    void operation3(){
        System. out. println();
    }
    void operation4(){
        System. out. println();
    }
    void operation5() {
        System. out. println();
    }
}

class D implements Interface1 {
    void operation1() {
        System. out. println();
    }
    void operation2(){
        System. out. println();
    }
    void operation3(){
        System. out. println();
    }
    void operation4(){
        System. out. println();
    }
    void operation5() {
        System. out. println();
    }
}

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 D { //D 类通过接口Interface1依赖(使用) D类，但是只会用到1,4,5方法
    public void depend1(Interface1 i) {
        i. operation1();
    }
    public void depend2(Interface1 i) {
        i. operation4();
    }
    public void depend3(Interface1 i) {
        i. operation5();
    }
}

2.4.1 按隔离原则应当这样处理:

将接口Interface1 拆分为独立的几个接口，类A和类c分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

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

class A { 
    public void depend1(Interface1 i) {
        i.operation1();
    }
    public void depend2(Interface2 i) {
        i. operation2();
    }
    public void depend3(Interface2 i) {
        i. operation3();
    }
}

class C { 
    public void depend1(Interface1 i) {
        i . operation1();
    }
    public void depend4(Interface3 i) {
        i. operation4();
    }
    public void depend5(Interface3| i) {
        i. operation5();
    }
}

2.5 依赖倒转原则

基本介绍

依赖倒转原则(Dependence Inversion Principle)是指:

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

问题代码

这种代码的

好处：简单。
坏处：person不应该依赖email类，如果后期接收消息变成微信、短信，该怎么处理？
解决思路：引入抽象的接口IReceiver，表示接收者。使得person与IReceiver接口发生依赖。细节要依赖抽象，而不是抽象依赖细节。

修正代码：

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

1)接口传递

2)构造方法传递

3) setter方式传递

2.5.2 依赖倒转原则的注意细节

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

2.6 里氏替换原则

2.6.1 背景——OO中的继承性的思考和说明

1) 继承包含这样一层含义:

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

2) 继承在给程序设计带来便利的同时，也带来了弊端。

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

3 )问题提出:在编程中，如何正确的使用继承?

=>里氏替换原则

2.6.2 里氏替换原则

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

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

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

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

2.6.3 实际例子

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

2)通用的做法是

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

2.7 开闭原则

2.7.1 基本概念

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

2.7.2 例子

看一个画图形的功能。

问题代码

public class Test {
    public static void main(String[] args) {}
}

class GraphicEditor {
    public void drawShape(Shape s){
        if (s.m_ _type== 1)
            drawRectangle(s);
        elseif(s.m_ type== 2)
            drawCircle(s);
    }
    public void drawRectangle(Shape r) {
        System.out.println("矩形");}
    public void drawCircle(Shaper) {
        System.out.println("因形");
    }
}

class Shape {
    int m_ _type;
}

class Rectangle extends Shape {
    Rectangle(){
    super.m_ type = 1;
}}

class Circle extends Shape {
    Circle(){
        super.m_ type= 2;
    }
}