面向对象六大原则

在学习设计模式之前，需要了解一下面向对象的六大原则，设计模式大多都遵循这些原则，写代码时心中时刻不要忘记六大原则，利用它们能写出更整洁、低耦合、高内聚的代码，更加清晰的逻辑

该文章由网上以及书籍上的资料整理而来 :)

• 六大原则
  • 单一职责原则
  • 里氏替换原则
  • 依赖倒置原则
  • 接口隔离原则
  • 迪米特法则
  • 开闭原则

单一职责原则

Single Responsibility Principle，简称SRP，对一个类而言，应该仅有一个引起它变化的原因，即一个类只负责一项职责

问题描述

当类 C 负责两个不同的职责：职责 M1，职责 M2，职责 M1 需求发生改变需要改变类 C 的时候，很有可能影响到原先的职责 M2 的功能

解决方案

一个类只负责一个职责，当需求改变时，不会影响到其他职责

里氏替换原则

Liskov Substitution Principle，简称LSP，所有引用基类的地方必须能透明地使用其子类的对象

问题描述

有一个功能 M，由类 C 完成，由于业务需要，需要拓展 M 功能 M1，此时需要由类 C 的子类 C1 完成拓展功能，当 C1 完成 M1 功能的同时，有可能导致原来 M 功能不可用

解决方案

当使用继承时，遵循里氏替换原则。类 M1 继承类 M 时，除添加新的方法完成 M1 的新增功能外，尽量不要重写父类 C 的方法，也尽量不要重载父类 C 的方法

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

依赖倒置原则

Dependence Inversion Principle，简称DIP

• 高层模块不应该依赖低层模块，高层模块是调用类，低层模块是实现类
• 二者都应该依赖其抽象，抽象指接口或抽象类
• 细节应该依赖抽象，细节指实现类

问题描述

有 B 和 C 两个实现类，类 A 直接依赖类 B，这种场景下，类 A 一般为高层模块，负责复杂业务逻辑，类 B 和类 C 是低层模块，负责原子操作，如果需要把类 A 改为依赖类 C，必须通过修改类 A 源代码，可能会引入不必要的风险

Tip：

• 原子操作：不可分割的，在执行完毕之前不会被任何其它任务或事件中断的操作

解决方案

将类 A 修改为依赖接口 I ，类 B 和类 C 各自实现接口 I ，类 A 通过接口 I 间接与类 B 或者类 C 发生联系，则会大大降低修改类A的几率

示例代码：

interface Animal{
    public String getFood();
}

class Cat implements Animal {
    
    @Override
    public String getFood() {
        return "鱼";
    }
}

class Dog implements Animal{
   
    @Override
    public String getFood() {
        return "骨头";
    }
}

class Master {
    // 依赖Animal接口
    public void feed(Animal animal) {
        String food = animal.getFood();
    }
}

接口隔离原则

Interface Segregation Principle，简称ISP，一个类对另一个类的依赖应该建立在最小的接口上

问题描述

类 A 通过接口 I 依赖类 B，类 C 通过接口 I 依赖类 D，如果接口 I 对于类 A 和类 B 来说不是最小接口，则类 B 和类 D 必须去实现他们不需要的方法

解决方案

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

迪米特法则

Law of Demeter，简称LoD，也称为最少知识原则（Principle of Least Knowledge）或得墨忒耳定律，一个对象应该对其他对象保持最少的了解

问题描述

类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大

解决方案

尽量降低类与类之间的耦合

开闭原则

Open Close Principle，简称OCP，对象应该对扩展开放，对修改关闭，开闭原则是面向对象设计中最基础的设计原则

问题描述

在软件的开发工程中，因为需求变化，升级，重构和维护等原因，需要修改源代码，这样很有可能引入错误

解决方案

当软件有变化时，尽量通过扩展的行为实现变化，而不是通过修改已有的代码实现变化