接口隔离原则：王语嫣懂天下武学，却不属于任何门派

接口隔离原则强调客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。她知晓天下各派武学理论，能够辨别不同门派的独特功夫，这相当于她拥有访问众多“接口”的能力。虽然精通武林各派理论，但她并不依赖某一门派的功夫，其角色核心在于理论和知识的掌握，并指导他人使用恰当的武功。

客户端不该依赖用不到的方法

接口隔离原则强调：客户端不应该被迫依赖于它不需要的接口。意思是，接口应该尽量小化，使得类只依赖于它们用到的方法。

示例：工作和吃饭接口

通过定义多个小接口，使得实现类可以选择实现自己真正需要的接口，而不是实现不必要的方法。这个原则帮助我们避免臃肿的接口，提供更细粒度的接口定义。

拆成两个小接口

// 接口：工作接口
interface Workable {
  work(): void;
}

// 接口：可吃饭接口
interface Eatable {
  eat(): void;
}

// 类：人类，实现工作接口和可吃饭接口
class Human implements Workable, Eatable {
  work(): void {
    console.log("Human is working");
  }

  eat(): void {
    console.log("Human is eating");
  }
}

// 类：机器人，只实现工作接口
class Robot implements Workable {
  work(): void {
    console.log("Robot is working");
  }
}

换一个只用 work 的实现

const human: Human = new Human();
human.work(); // 输出: Human is working
human.eat(); // 输出: Human is eating

const robot: Robot = new Robot();
robot.work(); // 输出: Robot is working

类图

体现接口隔离原则的设计模式

1. 策略模式（Strategy Pattern）：通过定义一系列的算法，把它们一一封装起来，并使它们可以相互替换。此模式体现了接口隔离原则，因为客户端可以选择用哪种策略而不必关心策略的内部实现，不同策略的实现被隔离在各自的类中。
2. 命令模式（Command Pattern）：命令模式将请求封装为一个对象，从而允许我们根据不同的请求将客户端参数化和传递可调用的方法，并将操作排队或记录操作日志。因为每个命令对应一个执行操作，遵循了接口隔离原则，易于扩展。
3. 适配器模式（Adapter Pattern）：通过包装一个已有的类提供一个新的接口，使原本接口不兼容的类可以一起工作。这里的“新的接口”遵循接口隔离原则，专门为某个客户端服务。

组件化开发里的接口最小化

1. 组件化开发：在React、Vue等现代前端框架中，组件化是核心概念之一。每个组件都应该有一个明确、专一的接口，通过Props（React）或Props/Events（Vue）与外界交互，这样做避免了组件依赖于它们不需要的属性或方法。
2. 服务层设计：在复杂的前端应用中，通常会有一个服务层用于处理数据获取、存储等逻辑。这个服务层会暴露出多个服务，每个服务负责一个单一的职责，而不是创建一个巨大的API类使其变得臃肿不堪。
3. 插件和中间件机制：在前端框架中使用插件和中间件允许开发者扩展框架的功能。每个插件或中间件只关心它需要实现的功能，而不需要了解系统的其他部分。

Lodash：按功能分层的实用库

1. Lodash：作为一个JavaScript的实用工具库，Lodash提供了许多功能性API，这些API分门别类，每个函数负责一个单一的功能，开发者可以根据需要引入使用，而不是加载整个库。
2. Redux Middleware：Redux是一个用于JavaScript应用的状态容器，它的中间件系统允许开发者插入自定义逻辑来处理actions或对dispatch的调用，每个中间件负责处理它关心的逻辑部分。

---

六大原则总览与其余各篇：总览、单一职责、开闭、里氏替换、依赖倒置、迪米特法则。