0Pricing
Clean Architecture & Design Patterns in Practice · 课时

实践接口隔离

应用接口隔离原则创建精简且专用的接口,避免使用臃肿接口迫使客户端依赖其不使用的方法。

实践接口隔离 是 CoddyKit 上的免费 Clean Architecture & Design Patterns in Practice 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Clean Architecture & Design Patterns in Practice 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Clean Architecture & Design Patterns in Practice 课程共包含 4 节课。

本课时的部分内容尚未翻译,以英文显示。

What is ISP?

Welcome to the Interface Segregation Principle (ISP)! This principle is one of the five SOLID principles of object-oriented design.

At its core, ISP states that clients should not be forced to depend on interfaces they do not use. In simpler terms, don't make classes implement methods they don't need.

The Problem: Fat Interfaces

A 'fat interface' is an interface that contains too many methods, some of which are irrelevant to certain classes that implement it.

When a class implements a fat interface, it's forced to provide implementations for all methods, even those it doesn't use. This often leads to empty or placeholder method bodies, which is a code smell.

Fat Interface Example

Consider a general IWorker interface. While a human worker might perform all these actions, a robot worker might not eat or sleep. Let's see how this creates issues.

interface IWorker {
  void work();
  void eat();
  void sleep();
  void manageTeam();
}

class Robot implements IWorker {
  @Override
  public void work() {
    System.out.println("Robot working...");
  }
  @Override
  public void eat() {
    // Robots don't eat, forced to implement
    System.out.println("Robot can't eat.");
  }
  @Override
  public void sleep() {
    // Robots don't sleep, forced to implement
    System.out.println("Robot can't sleep.");
  }
  @Override
  public void manageTeam() {
    // Not all robots manage teams
    System.out.println("Robot can't manage team.");
  }
}

public class Main {
  public static void main(String[] args) {
    Robot robot = new Robot();
    robot.work();
    robot.eat(); // This call is meaningless for a robot
  }
}

Consequences of Fat Interfaces

As seen with the Robot example, implementing a fat interface leads to several problems:

  • Code Smells: Empty or placeholder method implementations.
  • Brittle Code: Changes to an interface (e.g., adding a new method) might force unrelated clients to update their code.
  • Reduced Cohesion: The interface has too many responsibilities, making it less focused.
  • Increased Coupling: Clients are coupled to methods they don't use, making the system harder to maintain and test.

Solution: Segregating Interfaces

The Interface Segregation Principle proposes splitting large, 'fat' interfaces into smaller, more specific ones.

Each client (class) then only implements the interfaces that are relevant to its specific responsibilities. This ensures clients are not forced to depend on methods they don't need.

ISP in Action: Refactored Code

Let's refactor our IWorker example by creating smaller, role-specific interfaces. Now, each worker type can implement only what it truly needs.

interface IWorkable {
  void work();
}

interface IEatable {
  void eat();
}

interface ISleepable {
  void sleep();
}

interface IManager extends IWorkable { // Managers also work
  void manageTeam();
}

class HumanWorker implements IManager, IEatable, ISleepable {
  @Override
  public void work() { System.out.println("Human working..."); }
  @Override
  public void eat() { System.out.println("Human eating..."); }
  @Override
  public void sleep() { System.out.println("Human sleeping..."); }
  @Override
  public void manageTeam() { System.out.println("Human managing team..."); }
}

class RobotWorker implements IWorkable { // Only works
  @Override
  public void work() { System.out.println("Robot working..."); }
}

public class Main {
  public static void main(String[] args) {
    HumanWorker human = new HumanWorker();
    human.work();
    RobotWorker robot = new RobotWorker();
    robot.work();
    // robot.eat(); // This would now be a compile error, as expected!
  }
}

Benefits of Using ISP

Applying ISP brings significant advantages to your software design:

  • Improved Cohesion: Interfaces become more focused and represent a single, clear responsibility.
  • Reduced Coupling: Clients depend only on the specific methods they require, leading to looser coupling.
  • Easier Maintenance: Changes to one interface don't impact clients that don't implement it.
  • Better Testability: Smaller, focused interfaces are easier to mock and test in isolation.
  • Flexibility: New functionalities can be added by creating new interfaces or extending existing small ones without affecting existing clients.

ISP in Practice

ISP is particularly useful in systems with diverse client types or complex functionalities:

  • Role-Based Systems: Different user roles (e.g., Administrator, Editor, Viewer) might interact with different parts of a system, each needing a specific interface.
  • API Design: When designing APIs, provide specific endpoints or interfaces for different client applications (e.g., mobile apps vs. web apps).
  • Plugin Architectures: Plugins can implement only the specific interfaces that define the functionalities they provide to the main application.

ISP vs. SRP: A Quick Look

While both ISP and the Single Responsibility Principle (SRP) promote focused design, they operate at different levels:

  • SRP (Single Responsibility Principle): Focuses on classes, stating a class should have only one reason to change.
  • ISP (Interface Segregation Principle): Focuses on interfaces and clients, ensuring clients aren't forced to depend on methods they don't use.

They often work hand-in-hand. Applying SRP to classes might naturally lead to clearer interfaces, and applying ISP can help classes better adhere to SRP by only implementing what's truly relevant to their single responsibility.

Check Your Understanding

Given an interface IDocumentProcessor with methods printDocument(), scanDocument(), faxDocument(), and copyDocument(), which of the following are good ways to apply the Interface Segregation Principle?

Lesson Summary

Great job! You've learned about the Interface Segregation Principle:

  • Clients should not be forced to depend on interfaces they do not use.
  • 'Fat interfaces' lead to irrelevant method implementations and brittle code.
  • ISP solves this by splitting large interfaces into smaller, client-specific ones.
  • This improves cohesion, reduces coupling, and makes code more maintainable and testable.

Keep these principles in mind to design more robust and flexible software!

常见问题解答

「实践接口隔离」课时是免费的吗?

是的 — 「实践接口隔离」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Clean Architecture & Design Patterns in Practice 课程的其余内容,请升级到 CoddyKit PRO。 Clean Architecture & Design Patterns in Practice 课程共包含 4 节课。

「实践接口隔离」这节课中我会学到什么?

应用接口隔离原则创建精简且专用的接口,避免使用臃肿接口迫使客户端依赖其不使用的方法。 你通过在浏览器中直接运行的动手代码来练习 Clean Architecture & Design Patterns in Practice,全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Clean Architecture & Design Patterns in Practice 需要有经验吗?

无需任何先前经验。CoddyKit 上的 Clean Architecture & Design Patterns in Practice 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。

「实践接口隔离」课时需要多长时间?

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。

我能在这节 Clean Architecture & Design Patterns in Practice 课中编写并运行代码吗?

能。每节 Clean Architecture & Design Patterns in Practice 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 深入理解依赖倒置
  2. 实践接口隔离
  3. 使用设计模式重构
  4. 单一职责与开闭原则精通
← 返回 Clean Architecture & Design Patterns in Practice