接口隔离原则 (ISP) 是面向对象编程中的 SOLID 原则之一，它专注于设计接口，以便没有类被迫实现它不需要的方法。
简单来说，ISP 建议我们不要创建大型的、包罗万象的界面，而应该设计更小、更集中的界面。这确保每个类只实现它实际需要的方法。
如果一个大接口包含许多函数，但一个类不需要所有这些函数，它仍然必须实现所有这些函数 - 即使有些是不必要的。 ISP 建议我们应该将如此大的接口拆分为更小、更集中的接口。这样每个类就可以只实现自己实际需要的功能，避免实现不必要的功能。
通过遵循这种方法，可以降低代码复杂性，使其更易于理解和维护。
将大型且复杂的界面分解为更小、更具体的界面。
确保类不需要实现不必要的功能。
避免对类施加不适当的责任，从而产生更清晰、更易于理解的代码。
如果一个接口有10个方法，但一个特定的类只需要其中2个，ISP建议拆分这个大接口。这样，每个类就可以只实现它需要的方法，而不必实现其他的。
假设我们有一个用于所有类型任务的 Worker 接口：
Java 代码：
interface Worker {
void work();
void eat();
}
现在有两个类：HumanWorker 和 RobotWorker。 HumanWorker 既可以吃饭又可以工作，但 RobotWorker 不能吃饭。尽管如此，RobotWorker 仍必须实现 eat() 方法，这违反了 ISP：
Java 代码：
class HumanWorker implements Worker {
public void work() {
System.out.println("Human is working");
}
public void eat() {
System.out.println("Human is eating");
}
}
class RobotWorker implements Worker {
public void work() {
System.out.println("Robot is working");
}
public void eat() {
// Robot can't eat, but still needs to implement this method
}
}
我们可以使用 ISP 来解决这个问题，通过为工作 Workable 和吃 Eatable 创建单独的接口：
Java 代码：
interface Workable {
void work();
}
interface Eatable {
void eat();
}
class HumanWorker implements Workable, Eatable {
public void work() {
System.out.println("Human is working");
}
public void eat() {
System.out.println("Human is eating");
}
}
class RobotWorker implements Workable {
public void work() {
System.out.println("Robot is working");
}
}
现在，RobotWorker 不再需要实现不必要的 eat() 方法，遵循接口隔离原则 (ISP)。
假设有一个既可以运行又可以充电的机器界面：
JavaScript 代码：
class Machine {
run() {
console.log("Machine is running");
}
recharge() {
console.log("Machine is recharging");
}
}
但是，有些机器只能运行，不能充电。根据 ISP 的说法，我们应该将充电的职责分离到不同的接口中：
JavaScript 代码：
class RunnableMachine {
run() {
console.log("Machine is running");
}
}
class RechargeableMachine {
recharge() {
console.log("Machine is recharging");
}
}
现在不需要充值的机器只实现run()方法，而可充值的机器则实现recharge()方法。这种分离遵循接口隔离原则 (ISP)。
假设有一个可以打印和扫描的 Printer 类：
JavaScript 代码：
class Printer {
print() {
console.log("Printing...");
}
scan() {
console.log("Scanning...");
}
}
但是，并非所有打印机都具有扫描功能。在这种情况下，我们可以将必要的方法分离到不同的接口中：
JavaScript 代码：
class PrintOnly {
print() {
console.log("Printing...");
}
}
class ScanAndPrint {
print() {
console.log("Printing...");
}
scan() {
console.log("Scanning...");
}
}
现在，只需要打印功能的打印机将实现 PrintOnly 类，而同时需要打印和扫描功能的打印机将实现 ScanAndPrint 类。此设计遵循接口隔离原则 (ISP)，确保每个类仅实现其真正需要的内容。
假设我们有一个既可以驾驶又可以飞行的车辆类：
JavaScript 代码：
class Vehicle {
drive() {
console.log("Driving...");
}
fly() {
console.log("Flying...");
}
}
但是，并非所有车辆都可以飞行。为了解决这个问题，我们可以创建单独的接口：
JavaScript 代码：
class DriveOnly {
drive() {
console.log("Driving...");
}
}
class FlyAndDrive {
drive() {
console.log("Driving...");
}
fly() {
console.log("Flying...");
}
}
现在，只能驾驶的车辆将实现 DriveOnly 类，而既能驾驶又能飞行的车辆将实现 FlyAndDrive 类。该解决方案遵循接口隔离原则 (ISP)，确保类仅实现它们所需的功能。
提高代码可维护性： ISP 确保类只需要实现它们需要的方法。这使得代码更容易维护，因为类不会被不必要的方法弄乱。
特定接口的使用：通过使用更小、更集中的接口而不是大的、通用的接口，开发变得更加高效，因为不需要处理不必要的功能。
现实解决方案：想象一下您正在使用不同类型的设备，例如打印机、扫描仪和多功能设备。每个设备都有其自己特定的任务集。使用 ISP，您可以为每个任务（例如打印、扫描）创建单独的接口，以便每个设备仅实现其所需的功能。这使代码保持干净且组织良好。
当多个类有不同的需求时，您应该将其分解为更小、更具体的接口，而不是使用大型的通用接口。
如果您发现某个类被迫实现它不需要或不使用的方法，您可以应用 ISP 来确保该类仅实现相关功能。
不必要的方法实现：当一个类实现了一个大接口但没有使用所有方法时，它被迫实现不必要的方法。这会导致代码中出现不需要的无关方法。
代码复杂性增加：大型接口可能会导致类承担过多的责任，从而使代码变得不必要的复杂。这种复杂性使得代码难以维护，并且引入新的更改可能会带来风险。
违反类职责：当违反 ISP 时，类可能必须实现与其核心功能不直接相关的方法。这也违反了单一职责原则 (SRP)，因为该类参与了其主要角色之外的任务。
维护和更新问题：对大型接口进行更改时，所有实现该接口的类都必须调整以适应这些更改。如果使用较小的接口，则只有相关的类需要更新，从而更容易保持一致性。与大型接口保持这种一致性可能会变得具有挑战性。
代码可重用性降低：大型接口强制所有类实现所有方法，导致可重用性降低。每个类最终可能会包含不必要的代码，这会降低代码的整体可重用性。
假设你有一个名为 Worker 的大接口，其中包含 work() 和 eat() 方法。现在，对于机器人来说，不需要 eat() 方法，但仍然需要机器人类来实现它。这违反了 ISP 并导致与机器人功能无关的不必要的方法。
因此，违反 ISP 会导致代码复杂性增加、维护困难，并强制执行不必要的方法。
接口隔离原则 (ISP) 只是指出，不应强迫对象或组件实现它不使用的方法。每个组件都应该被赋予与其特定需求相关的方法或道具。
ISP的核心思想是不应该向客户端提供他们不需要使用的接口或API。简而言之，它建议将大型接口或类分解为更小、更集中的接口或类，允许客户仅使用他们必需的部分。
这种方法通过确保每个组件仅与其所需的功能交互来促进更干净、更易于维护的代码，并增强系统的灵活性。
想象一家餐厅有三类顾客：1）来吃米饭的人，2）来吃面食的人，3）来吃沙拉的人。如果我们提供它们都具有相同的菜单，其中包含所有内容，许多项目与某些顾客无关。这会让菜单变得不必要地复杂。
根据界面隔离原则（ISP），来吃米饭的顾客只能得到米饭菜单，吃面食的顾客只能得到面食菜单，而吃沙拉的顾客只能得到沙拉菜单。这样，每个人的体验都会得到简化，让每个客户都能专注于他们真正想要的东西，而无需任何不必要的选择。
这个类比说明了 ISP 如何鼓励定制界面以满足特定需求，使交互更加简单和高效。
In React, we often create large components that contain many props or methods. However, it's common for a component not to need all of those props. According to the Interface Segregation Principle (ISP), components should be broken down into smaller parts so that each component only receives the props and methods that are necessary for its functionality.
By following this principle, you can achieve:
Cleaner Code: Each component remains focused on its specific task, making the codebase easier to understand and maintain.
Improved Reusability: Smaller components can be reused in different contexts without carrying unnecessary props.
Better Performance: Since components only receive what they need, rendering becomes more efficient.
For example, instead of a large UserProfile component that handles both user information and user settings, you could create two separate components: UserInfo and UserSettings. Each component would only receive the relevant props, following the ISP and resulting in a more modular and maintainable structure.
Imagine we have created a large Button component that can perform various actions such as onClick, onHover, onFocus, and more. However, in some cases, we might only need the onClick functionality, but the other functions also come with the component, which we don’t need.
According to the Interface Segregation Principle (ISP), we can break down this large Button component into smaller, more focused components. For example:
JSX code:
const ClickableButton = ({ onClick }) => (
<button onClick={onClick}>Click Me</button>
);
const HoverableButton = ({ onHover }) => (
<button onMouseOver={onHover}>Hover Over Me</button>
);
Imagine we have a large Form component that contains multiple fields (name, address, email, password). However, sometimes we only need the email and password fields, not the entire form component.
According to the Interface Segregation Principle (ISP), we can break down the form into smaller parts. For example:
JSX code:
const EmailField = ({ email, onChange }) => (
<input type="email" value={email} onChange={onChange} />
);
const PasswordField = ({ password, onChange }) => (
<input type="password" value={password} onChange={onChange} />
);
Now, when we only need the email and password, we can use just those specific components instead of the entire form component. This approach allows us to create a more focused and modular structure, adhering to ISP principles.
Imagine we have a large Dashboard component that includes various user information, graphs, and settings. However, there might be a page where we only need the user settings, yet we are using the entire Dashboard component.
According to the Interface Segregation Principle (ISP), we should break down the large Dashboard component into smaller, more focused parts. For example:
JSX code:
const UserInfo = ({ name, email }) => (
<div>
<p>{name}</p>
<p>{email}</p>
</div>
);
const UserSettings = ({ settings }) => (
<div>
<h3>Settings</h3>
{/* Code to display the settings */}
</div>
);
Now, we can utilize these separate parts wherever necessary, allowing us to display only the relevant sections needed for that specific page. This approach ensures that our components are lightweight and tailored to their intended functionality.
Following the Interface Segregation Principle (ISP), React components should be designed as separate, small interfaces or props tailored for specific tasks. This approach allows components to be easier to manage and used only as needed, promoting a more efficient and clean codebase.
By breaking down components into smaller, focused parts, we ensure that each component does one thing well, enhancing maintainability and making it easier to adapt or extend functionality in the future. This method also facilitates better reusability, as developers can select only the components that fit their requirements without carrying unnecessary baggage.
While the Interface Segregation Principle (ISP) has several advantages, it also comes with some limitations. Below are some disadvantages of ISP:
Need for More Interfaces: Following ISP often requires breaking large interfaces into smaller ones. This can lead to the creation of a large number of interfaces, making code management somewhat complex.
Increased Coding and Maintenance: With many interfaces, each one requires a separate implementation. This increases the workload for developers and can take more time. Additionally, making changes later might necessitate updates in multiple places, complicating maintenance.
Risk of Over-Engineering: ISP can sometimes introduce excessive complexity, especially when too many small interfaces are created. This approach may lead to over-engineering, resulting in unnecessary complexity for the project.
复杂的依赖管理：使用ISP可以使组件或类依赖于各种接口。这可能会使依赖关系管理变得复杂，因为多个接口会产生多个依赖关系，从而很难跟踪它们。
应用 ISP 时，可能会出现创建过多接口、增加编码和管理挑战等问题，这可能会加剧项目复杂性。
接口隔离原则（ISP）有助于保持编程的模块化和灵活性。通过将大型接口或组件分解为更小的部分，可以消除不必要的复杂性。使用 ISP 允许我们在组件中只实现必要的方法或 props，从而使代码更简单、更可重用和可维护。虽然它有时会导致接口和代码的增加，但如果应用得当，它可以大大增强软件设计的组织性和有效性。因此，正确实施 ISP 对于提高软件开发的质量和长期成功至关重要。
The above is the detailed content of I - Interface Segregation Principle (ISP). For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
