【总结记录】面向对象设计OOP三大特性（封装、继承、多态）、七大基本原则的理解（结合代码、现实实例理解）

拖了好久的总结= =。
对 OOP 的内容零散地看了一些，想了一些还是自己写一个总结来提升一下理解吧！
学好 OOP，也利于设计模式的学习～
一点自己的见解，疏漏错误的地方期待大佬在评论区指正～
文章定义、实例等参考了《大话设计模式》、什么是OOP、OOP七大原则等书籍、文章，感谢～

一. 三大特征的理解

（1）封装

• 定义：每个对象都包含它能进行操作所需要的所有信息。

• 好处：

  1. 减少耦合
  2. 类内部实现可以自由修改
  3. 类具有清晰的对外接口

• 例子：房子，用墙壁封装起来。

  1. 窗户、门口就是对外接口：设想一下，如果没有门窗（或者门窗是秘密暗道，不清晰），我们无法进入房子来使用里面的家具，那这个房子还有用吗？（清晰对外接口的必要性）
  2. 改变房间布局就是修改类内部：我的房子想怎么改就怎么改，不会给房外人带来困扰（自由修改内部的体现）
  3. 减少耦合：我想到的例子是合租；耦合度过高，相当于大家的房子都连在一起（没有墙壁封装），耦合度过高带来的问题，就是不必要的相互联系：比如我在家用着100寸电视打游戏，你家高三孩子无法避免地看到了，导致无心向学。而墙壁的封装就可以避免这个不必要的互相联系，也就是达到减小耦合度的效果。

  图源网络，侵删

（2）继承

• 定义：子类可以理解为对父类的特殊化，除了具备父类特性外，还具备自己的独立个性。
  1. 子类拥有父类非 private 的属性和功能
  2. 子类具有自己的属性和功能（拓展）
  3. 子类可以用自己的方式实现父类的功能（重写）
• 好处：
  1. 提高代码复用率
  2. 易拓展
• 缺点：父类变，则子类不得不变——继承会破坏（1）的封装性。
  可以看到（1）的好处2【自由修改】。显而易见，继承会威胁到这一效果：
  父类的自由修改，可能会导致子类出现问题（比如新增抽象函数）。
• 这也显示着，继承是一种类与类之间强耦合的关系

因此，有一项“组合优先于继承”的原则，可以到下面的原则（7）再看一下～

• 例子：虽然大家应该都对继承熟悉了，不过这边还是写一个吧～
  大凡是小凡的爹，因此小明和大明一样都是黄种人（父类特征）
  虽然是大凡不会rap，但是小凡会（子类拓展）
  大凡唱歌，唱高音；小凡唱歌，唱电音（方法重写）
  大凡改变肤色，变成黑人，小凡也得变成黑人（破坏封装性，不能自由修改内部）

  联动一下计网，URI和URL也可以看成继承关系噢～（URL 是对 URI 的特殊化）

（3）多态

• 定义：不同对象执行相同动作，但要通过对象自己的代码执行。
  1. 子类以父类身份出现（对象声明必须是父类）
  2. 子类以自己方式实现（无论对象是否转换成父类，都用的继承链末端方法）
  3. 子类特有属性和方法不可使用
• 优点：提高了代码的维护性、拓展性
• 例子：这里直接用《大话设计模式》里的例子，这个讲的挺好的：
  京剧艺术家大明，和子承父业的儿子小明。父亲表演当前生病了，小明代父表演：
  小明穿大明的戏服，以大明的身份进行表演（父类身份）
  小明还是以自己的理解进行表演（自己方式）
  小明虽然说学了一手Breaking，但是父亲不会，所以不能使用（特有属性方法不可用）
• 重载，算多态吗：按照上面的定义来看，应该不算。但是也有说算是静态多态的。总的来说应该是看具体定义，看成一种多态应该也是可以的。

（4）面向对象、面向过程的对比

各自相对优点：

• 面向过程：效率更高。（具体化、流程化，不用进行实例化过程）
• 面向对象：易维护、易复用、易扩展。（三大特性）

二. 七大基本原则的理解

诶，网上很多都是五大原则，为了全面点，我这边还是写七个的吧～

（1）单一职责原则

• 定义：一个类，应该有且只有一个引起它变化的原因
• 好处
  1. 耦合度低，变更引起的风险降低，提高可维护性。
  2. 类的职责明确，增加代码可读性。
• 例子：两种手机类，按照单一职责原则，手机应该只负责通话。
  过多的功能，会提高类的复杂度，同时提高了耦合度。
  （当然，显示中手机还是按照多种多样的来的，这里只是想表达一下）

class BadPhone {
    // 包括手电筒、相机、通话功能的手机类
    private int flashlightBrightness;
    private int cameraPixel;
    private int volume;

    public void flashlightFunctions() { }
    public void cameraFunctions() { }
    public void conversationFunctions() { }
}

class GoodPhone {
    // 包括通话功能的手机类
    private int volume;

    public void conversationFunctions() { }
}

（2）开放封闭原则（OOP 核心）

• 定义：软件实体，应该是可以拓展，但是不可修改。
• 理解：一个类提供的外部可用接口，如果由于新的需求进行了修改，可能会导致依赖这个接口的其他方法瘫痪。解决方法就是通过拓展新接口，而非修改旧接口来实现新需求。
• 好处：可维护、可拓展、可服用、灵活性好（全包！）
• 例子：getID() 返回 String，printID() 依赖 getID()。现在多了一个返回 int 型 ID 的需求。

class MyClass2 {
    public String getID() {
        return "ID";
    }

    // Bad
//    public int getID() {
//        return 123;
//    }

    // Good
    public int getIntID() {
        return 123;
    }

    public void printID() {
        // 如果修改 getID()，依赖 getID() 的 printID() 就会出错
        // 但是拓展 getIntID()，就没问题
        System.out.printf("%s", getID());
    }
}

（3）里氏替换原则（OOP 标志）

• 定义：子类型必须能够替换掉父类型。
• 优点：保证使用父类的模块在无需修改的情况下就能拓展，提升拓展性。
• 例子：举个开枪的例子吧～

class Gun {
    public void shoot() {
        System.out.println("fire!");
    }
}

class GoodGun extends Gun {
    @Override
    public void shoot() {
        System.out.println("fire! fire!");
    }
}

class BadGun extends Gun {
    @Override
    public void shoot() {
        System.out.println("sorry, I can't fire");
    }
}

class Man {
    public void fire() {
        new Gun().shoot();
        // new GoodGun().shoot(); 可以替换，能开枪
        // new BadGun().shoot(); 不能替换，不能开枪
    }
}

（4）依赖倒置原则

• 定义：抽象不应该依赖细节，细节应该依赖于抽象。
• 理解：针对接口，而非实现进行编程。
• 例子：写一个项目A，用到 Redis（高层模块项目A，依赖于低层模块 Redis）。如今由于机子太烂，日常宕机，因此打算换成 etcd 来避免数据丢失的问题。
  问题来了，由于项目A的代码绑定了 Redis，因此无法复用项目A的代码，这就问题很大～如何解决呢？如果项目A的代码依赖的不是Redis，而是抽象的 K-V 数据库，具有稳定的接口（也就是依赖于抽象），那就可以直接替换成 etcd 啦～

讲道理，我不会 Redis、etcd，这里的例子是大概举出来的，有误的话欢迎指出～

（5）接口分离原则

• 定义：客户端不应该依赖它不需要的接口。采用多个与特定客户类有关的接口，比采用一个通用的接口要好。
• 理解：相对于（1）单一职责原则（注重业务逻辑划分），这里要求的是接口的方法尽量少
• 好处：
  1. 避免接口污染
  2. 高内聚（一个软件模块是由相关性很强的代码），毕竟用多个合适接口啦～
  3. 灵活性
• 例子：实现老人机类，一个复杂的手机接口 VS 多个简单的功能接口

interface BadPhoneInterface {
    void fly();
    void swim();
    void watchTV();
    void buy();
    void talk();
    void sendMessage();
}

// 老人机：只希望能打电话、发短信就好
// 非接口分离：采用了具有多个方法的接口，并非高聚合
class OldPhone1 implements BadPhoneInterface {
    @Override
    public void fly() { }

    @Override
    public void swim() { }

    @Override
    public void watchTV() { }

    @Override
    public void buy() { }

    @Override
    public void talk() { }

    @Override
    public void sendMessage() { }
}

// 接口分离：高聚合，灵活，定制化～
interface Talker {
    void talk();
}

interface MessageSender {
    void sendMessage();
}

class OldPhone2 implements Talker, MessageSender {
    @Override
    public void talk() { }

    @Override
    public void sendMessage() { }
}

（6）迪米特原则（最少知识法则）

• 定义：如果两个类不必彼此直接通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法，可以通过第三者转发调用。
• 理解：根本思想是强调类之间的松耦合，促进了类的复用
• 例子：秋招时节～举一个求职例子吧！（当然，具体面试流程肯定没我瞎写的这么糙）
  小红想进大厂A，于是花了大功夫认识了面试官1投简历，希望面试官1过几天能面她。
  但是～还没来得及面，面试官1就跳槽了！那小红接下来该怎么办，继续花大时间来找面试官2、面试官3吗？这就是没有遵循迪米特原则了：
  小红和（具体）面试官之间，不应该有直接的联系，这样耦合太高了。而应该是找HR！让HR来充当这个转发“求面试调用”的第三者，这样耦合度低，而且不会发生像上面那样的事情了^ ^

（7）组合优先继承原则

• 定义：能用组合的地方就不要继承，以保证封装性。

  （6）(7）的代码有空再补了。。敲累了摆烂
  花了一下午我是没想到的= =
  希望这个总结能帮助读者有更多的OOP理解，感谢你能阅读到这里～