I - インターフェース分離原則 (ISP)

インターフェース分離原則(ISP)とは何ですか?

インターフェイス分離原則 (ISP) は、オブジェクト指向プログラミングにおける SOLID 原則の 1 つであり、クラスが必要のないメソッドの実装を強制されないようインターフェイスを設計することに重点を置いています。

簡単に言うと、ISP は、大規模ですべてを網羅するインターフェイスを作成する代わりに、より小さく、より焦点を絞ったインターフェイスを設計する必要があると提案しています。これにより、各クラスが実際に必要なメソッドのみを実装することが保証されます。

例えば：

大規模なインターフェイスに多くの関数が含まれているが、クラスがそれらの関数のすべてを必要としない場合、たとえ一部が不要であっても、クラスはすべての関数を実装する必要があります。 ISP は、このような大規模なインターフェイスをより小さく、より焦点を絞ったインターフェイスに分割する必要があると提案しています。このようにして、各クラスは実際に必要な関数のみを実装し、不要な関数の実装を回避できます。

このアプローチに従うことで、コードの複雑さが軽減され、理解と保守が容易になります。

ISP の主な目標は次のとおりです。

• 大規模で複雑なインターフェースをより小さく、より具体的なインターフェースに分割します。

• クラスが不必要な機能を実装する必要がないようにします。

• クラスに過度の責任を負わせることを回避し、よりクリーンで理解しやすいコードを実現します。

例えば：

インターフェイスに 10 個のメソッドがあるが、特定のクラスで必要なメソッドが 2 つだけの場合、ISP はこの大きなインターフェイスを分割することをお勧めします。このようにして、各クラスは、他のメソッドを実装することなく、必要なメソッドのみを実装できます。

例 1:

あらゆる種類のタスクに使用される Worker インターフェイスがあるとします。

Java コード:

interface Worker {
    void work();
    void eat();
}

現在、HumanWorker と RobotWorker の 2 つのクラスがあります。 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 はインターフェイス分離原則 (ISP) に準拠し、不要な Eat() メソッドを実装する必要がなくなりました。

例 1:

実行と充電の両方ができるマシン インターフェイスがあるとします。

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) に従います。

例 2:

印刷とスキャンの両方ができる 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) に準拠しており、各クラスが本当に必要なものだけを実装するようにします。

例 3:

運転と飛行の両方ができる Vehicle クラスがあるとします。

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 の重要性と実際のアプリケーション:

1. コードの保守性の向上: ISP は、クラスが必要なメソッドの実装のみを必要とすることを保証します。これにより、クラスが不要なメソッドで乱雑にならないため、コードの保守が容易になります。

2. 特定のインターフェイスの使用: 大規模で汎用的なインターフェイスの代わりに、より小規模で焦点を絞ったインターフェイスを使用することで、不必要な機能に対処する必要がなくなるため、開発がより効率的になります。

3. 現實解決方案：想像一下您正在使用不同類型的設備，例如印表機、掃描器和多功能設備。每個設備都有自己特定的任務集。使用 ISP，您可以為每個任務（例如列印、掃描）建立單獨的接口，以便每個設備僅實現其所需的功能。這使程式碼保持乾淨且組織良好。

何時使用 ISP：

• 當多個類別有不同的需求時，您應該將其分解為更小、更具體的接口，而不是使用大型的通用接口。

• 如果您發現某個類別被迫實現它不需要或不使用的方法，您可以應用 ISP 來確保該類別僅實現相關功能。

違反ISP造成的問題：

1. 不必要的方法實作：當一個類別實作了一個大介面但沒有使用所有方法時，它被迫實作不必要的方法。這會導致程式碼中出現不必要的無關方法。

2. 程式碼複雜度增加：大型介面可能會導致類別承擔過多的責任，從而使程式碼變得不必要的複雜。這種複雜性使得程式碼難以維護，並且引入新的變更可能會帶來風險。

3. 違反類別職責：當違反 ISP 時，類別可能必須實現與其核心功能不直接相關的方法。這也違反了單一職責原則 (SRP)，因為該類別參與了其主要角色之外的任務。

4. 維護和更新問題：對大型介面進行變更時，所有實作該介面的類別都必須調整以適應這些變更。如果使用較小的接口，則只有相關的類別需要更新，從而更容易保持一致性。與大型介面保持這種一致性可能會變得具有挑戰性。

5. 程式碼可重用性降低：大型介面強制所有類別實作所有方法，導致可重用性降低。每個類別最終可能包含不必要的程式碼，這會降低程式碼的整體可重複使用性。

例子：

假設你有一個名為 Worker 的大接口，其中包含 work() 和 eat() 方法。現在，對於機器人來說，不需要 eat() 方法，但仍然需要機器人類來實現它。這違反了 ISP 並導致與機器人功能無關的不必要的方法。

結論：

因此，違反 ISP 會導致程式碼複雜性增加、維護困難，並強制執行不必要的方法。

React 中的介面隔離原則（ISP）

介面隔離原則 (ISP) 只是指出，不應強迫物件或元件實現它不使用的方法。每個組件都應該被賦予與其特定需求相關的方法或道具。

ISP的核心思想是不應該提供客戶端不需要使用的介面或API。簡而言之，它建議將大型介面或類別分解為更小、更集中的介面或類別，允許客戶僅使用他們必需的部分。

這種方法透過確保每個元件僅與其所需的功能互動來促進更乾淨、更易於維護的程式碼，並增強系統的靈活性。

簡單範例：

想像一家餐廳有三類顧客：1）來吃米飯的人，2）來吃麵食的人，3）來吃沙拉的人。 如果我們提供它們都具有相同的選單，其中包含所有內容，許多項目與某些顧客無關。這會讓菜單變得不必要地複雜。

根據介面隔離原則（ISP），來吃米飯的顧客只能得到米飯菜單，吃麵食的顧客只能得到麵食菜單，而吃沙拉的顧客只能得到沙拉菜單。這樣，每個人的體驗都會簡化，讓每個客戶都能專注於他們真正想要的東西，而無需任何不必要的選擇。

這個類比說明了 ISP 如何鼓勵客製化介面以滿足特定需求，使互動更加簡單和高效。

ISP in React Simplified:

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:

1. Cleaner Code: Each component remains focused on its specific task, making the codebase easier to understand and maintain.

2. Improved Reusability: Smaller components can be reused in different contexts without carrying unnecessary props.

3. 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.

Example 1:

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>
);

Example 2:

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.

Example 3:

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.

Solution:

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.

Disadvantages of Interface Segregation Principle(ISP)

While the Interface Segregation Principle (ISP) has several advantages, it also comes with some limitations. Below are some disadvantages of ISP:

1. 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.

2. 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.

3. 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.

4. 複雑な依存関係管理: ISP を使用すると、コンポーネントやクラスがさまざまなインターフェイスに依存する可能性があります。複数のインターフェイスから複数の依存関係が発生し、それらを追跡することが困難になるため、依存関係の管理が複雑になる可能性があります。

まとめ

ISP を適用すると、過剰なインターフェイスの作成、コーディングの増加、管理上の課題などの問題が発生し、プロジェクトの複雑さが増大する可能性があります。

結論

インターフェイス分離原則 (ISP) は、プログラミングのモジュール性と柔軟性を維持するのに役立ちます。大きなインターフェイスやコンポーネントを小さな部分に分割することで、不必要な複雑さが排除されます。 ISP を使用すると、必要なメソッドまたはプロパティのみをコンポーネントに実装できるため、コードがよりシンプルになり、再利用しやすく、保守しやすくなります。場合によってはインターフェイスやコードの増加につながる可能性がありますが、正しく適用すると、ソフトウェア設計の構成と有効性を大幅に向上させることができます。したがって、ソフトウェア開発の品質向上と長期的な成功には、ISP の適切な実装が不可欠です。

以上がI - インターフェース分離原則 (ISP)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。