面向对象思想（CS-Notes）

public class Person {

    private String name;
    private int gender;
    private int age;

    public String getName() {
        return name;
    }

    public String getGender() {
        return gender == 0 ? "man" : "woman";
    }

    public void work() {
        if (18 <= age && age <= 50) {
            System.out.println(name + " is working very hard!");
        } else {
            System.out.println(name + " can't work any more!");
        }
    }
}

1.2 继承

继承实现了 IS-A 关系，例如 Cat 和 Animal 就是一种 IS-A 关系，因此 Cat 可以继承自 Animal，从而获得 Animal 非 private 的属性和方法。

继承应该遵循里氏替换原则，子类对象必须能够替换掉所有父类对象。

Cat 可以当做 Animal 来使用，也就是说可以使用 Animal 引用 Cat 对象。父类引用指向子类对象称为 向上转型 。

子类能当做父类来用

Animal animal = new Cat();

1.3 多态

多态分为 编译时多态 和 运行时多态：

编译时多态主要指 方法的重载
运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定

运行时多态有三个条件：

继承
覆盖（重写）
向上转型

下面的代码中，乐器类（Instrument）有两个子类：Wind 和 Percussion，它们都覆盖了父类的 play() 方法，并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时，会执行实际引用对象所在类的 play() 方法，而不是 Instrument 类的方法。

public class Instrument {

    public void play() {
        System.out.println("Instument is playing...");
    }
}

public class Wind extends Instrument {

    public void play() {
        System.out.println("Wind is playing...");
    }
}

public class Percussion extends Instrument {

    public void play() {
        System.out.println("Percussion is playing...");
    }
}

public class Music {

    public static void main(String[] args) {
        List<Instrument> instruments = new ArrayList<>();
        instruments.add(new Wind());
        instruments.add(new Percussion());
        for(Instrument instrument : instruments) {
            instrument.play();
        }
    }
}

运行结果：

Wind is playing...
Percussion is playing...

我的理解：

父类父类引用 = new 子类();

父类引用可以指向子类对象。但是拿这个父类引用去调用父类和子类中都有的方法时，会执行 子类对象的方法，而不是执行父类的方法。

2 类图

以下类图使用 PlantUML 绘制，更多语法及使用请参考：http://plantuml.com/ 。

2.1 泛化关系 (Generalization)

用来描述继承关系，在 Java 中使用 extends 关键字。

@startuml

title Generalization

class Vihical
class Car
class Trunck

Vihical <|-- Car
Vihical <|-- Trunck

@enduml

2.2 实现关系 (Realization)

用来实现一个接口，在 Java 中使用 implements 关键字。

@startuml

title Realization

interface MoveBehavior
class Fly
class Run

MoveBehavior <|.. Fly
MoveBehavior <|.. Run

@enduml

2.3 聚合关系 (Aggregation)

表示整体由部分组成，但是整体和部分不是强依赖的。整体不存在了，部分还是会存在。

@startuml

title Aggregation

class Computer
class Keyboard
class Mouse
class Screen

Computer o-- Keyboard
Computer o-- Mouse
Computer o-- Screen

@enduml

2.4 组合关系 (Composition)

和聚合不同，组合中整体和部分是强依赖的。整体不存在了，部分也不存在了。比如公司和部门，公司没了部门就不存在了。但是公司和员工就属于聚合关系了，因为公司没了员工还在。

@startuml

title Composition

class Company
class DepartmentA
class DepartmentB

Company *-- DepartmentA
Company *-- DepartmentB

@enduml

2.5 关联关系 (Association)

表示不同类对象之间有关联，这是一种静态关系，与运行过程的状态无关，在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系，一个学校可以有很多学生，但是一个学生只属于一个学校，因此这是一种多对一的关系，在运行开始之前就可以确定。

@startuml

title Association

class School
class Student

School "1" - "n" Student

@enduml

2.6 依赖关系 (Dependency)

假设A类的变化引起了B类的变化，则B类依赖于A类。

和关联关系不同的是，依赖关系是在运行过程中起作用的。A 类和 B 类是依赖关系主要有三种形式：

A 类是 B 类方法的局部变量；
A 类是 B 类方法当中的一个参数；
A 类向 B 类发送消息，从而影响 B 类发生变化。

@startuml

title Dependency

class Vihicle {
    move(MoveBehavior)
}

interface MoveBehavior {
    move()
}

note "MoveBehavior.move()" as N

Vihicle ..> MoveBehavior

Vihicle .. N

@enduml

扩展学习：https://blog.csdn.net/wang15061955806/article/details/50551385

3 设计原则

3.1 S.O.L.I.D

简写	全拼	中文翻译
SRP	The Single Responsibility Principle	单一责任原则
OCP	The Open Closed Principle	开放封闭原则
LSP	The Liskov Substitution Principle	里氏替换原则
ISP	The Interface Segregation Principle	接口分离原则
DIP	The Dependency Inversion Principle	依赖倒置原则

1. 单一责任原则

修改一个类的原因应该只有一个。

换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。

2. 开放封闭原则

类应该对扩展开放，对修改关闭。

扩展就是添加新功能的意思，因此该原则要求在添加新功能时不需要修改代码。

符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。

3. 里氏替换原则

子类对象必须能够替换掉所有父类对象。

继承是一种 IS-A 关系，子类需要能够当成父类来使用，并且需要比父类更特殊。

如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。

4. 接口分离原则

不应该强迫客户依赖于它们不用的方法。

因此，使用 多个专门的接口 比使用 单一的总接口 要好。

5. 依赖倒置原则

高层模块不应该依赖于低层模块，二者都应该依赖于抽象；
抽象不应该依赖于细节，细节应该依赖于抽象。

高层模块包含一个应用程序中重要的策略选择和业务模块。如果高层模块依赖于低层模块，那么低层模块的改动就会直接影响到高层模块，从而迫使高层模块也需要改动。

依赖于抽象，意味着：

任何变量都不应该持有 一个指向具体类的指针或者引用；
任何类都不应该从具体类派生；
任何方法都不应该覆写 它的任何基类中的已经实现的方法。

3.2 其他常见原则

除了上述的经典原则，在实际开发中还有下面这些常见的设计原则。

简写	全拼	中文翻译
LOD	The Law of Demeter	迪米特法则
CRP	The Composite Reuse Principle	合成复用原则
CCP	The Common Closure Principle	共同封闭原则
SAP	The Stable Abstractions Principle	稳定抽象原则
SDP	The Stable Dependencies Principle	稳定依赖原则