I – Interface-Segregations-Prinzip (ISP)

Was ist das Interface-Segregationsprinzip (ISP)?

Das Interface Segregation Principle (ISP) ist eines der SOLID-Prinzipien in der objektorientierten Programmierung, das sich auf die Gestaltung von Schnittstellen konzentriert, sodass keine Klasse gezwungen ist, Methoden zu implementieren, die sie nicht benötigt.

Einfach ausgedrückt schlägt ISP vor, statt große, allumfassende Schnittstellen zu erstellen, kleinere, fokussiertere zu entwerfen. Dadurch wird sichergestellt, dass jede Klasse nur die Methoden implementiert, die sie tatsächlich benötigt.

Zum Beispiel:

Wenn eine große Schnittstelle viele Funktionen enthält, eine Klasse aber nicht alle dieser Funktionen benötigt, müsste sie dennoch alle implementieren – auch wenn einige unnötig sind. Der ISP schlägt vor, dass wir solch große Schnittstellen in kleinere, fokussiertere aufteilen sollten. Auf diese Weise kann jede Klasse nur die Funktionen implementieren, die sie tatsächlich benötigt, und die Implementierung unnötiger Funktionen vermeiden.

Durch die Befolgung dieses Ansatzes wird die Komplexität des Codes reduziert, wodurch er einfacher zu verstehen und zu warten ist.

Die Hauptziele von ISP sind:

• Aufteilung großer und komplexer Schnittstellen in kleinere, spezifischere.

• Sicherstellen, dass eine Klasse keine unnötigen Funktionen implementieren muss.

• vermeiden, eine unangemessene Verantwortung für eine Klasse zu setzen, was zu sauberer und verständlicheren Code führt.

Zum Beispiel:

Wenn eine Schnittstelle 10 Methoden hat, eine bestimmte Klasse nur 2 von ihnen benötigt, empfiehlt ISP, diese große Schnittstelle zu teilen. Auf diese Weise kann jede Klasse nur die Methoden implementieren, die sie benötigt, ohne die anderen implementieren zu müssen.

Beispiel 1:

Nehmen wir an, wir haben eine Arbeiteroberfläche, die für alle Arten von Aufgaben verwendet wird:

Java-Code:

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

Jetzt gibt es zwei Klassen: Humanworker und Roboter. HumanWorker kann sowohl essen als auch arbeiten, RobotWorker jedoch nicht. Dennoch muss RobotWorker die Methode eat() implementieren, die gegen ISP:

verstößt

Java-Code:

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
    }
}

Wir können dieses Problem mit ISP lösen, indem wir separate Schnittstellen für das Arbeitsabbau und das Essen zu essen:

erstellen:

Java-Code:

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

Jetzt muss RobotWorker nicht mehr die unnötige eat()-Methode implementieren und hält sich an das Interface Segregation Principle (ISP).

Beispiel 1:

Nehmen wir an, es gibt eine Maschinenschnittstelle, die sowohl laufen als auch aufgeladen werden kann:

JavaScript-Code:

class Machine {
  run() {
    console.log("Machine is running");
  }

  recharge() {
    console.log("Machine is recharging");
  }
}

Einige Maschinen können jedoch nur laufen, aber nicht aufgeladen werden. Laut ISP sollten wir die Verantwortung für das Aufladen auf eine andere Schnittstelle verteilen:

JavaScript-Code:

class RunnableMachine {
  run() {
    console.log("Machine is running");
  }
}

class RechargeableMachine {
  recharge() {
    console.log("Machine is recharging");
  }
}

Jetzt implementieren Maschinen, die nicht aufgeladen werden müssen, nur die run()-Methode, während wiederaufladbare Maschinen die recharge()-Methode implementieren. Diese Trennung folgt dem Interface Segregation Principle (ISP).

Beispiel 2:

Nehmen wir an, es gibt eine Druckerklasse, die sowohl drucken als auch scannen kann:

JavaScript-Code:

class Printer {
  print() {
    console.log("Printing...");
  }

  scan() {
    console.log("Scanning...");
  }
}

Allerdings verfügen nicht alle Drucker über die Fähigkeit zum Scannen. In diesem Fall können wir die notwendigen Methoden in verschiedene Schnittstellen aufteilen:

JavaScript-Code:

class PrintOnly {
  print() {
    console.log("Printing...");
  }
}

class ScanAndPrint {
  print() {
    console.log("Printing...");
  }

  scan() {
    console.log("Scanning...");
  }
}

Jetzt implementieren Drucker, die nur die Druckfunktionalität benötigen, die PrintOnly-Klasse, während Drucker, die sowohl Drucken als auch Scannen erfordern, die ScanAndPrint-Klasse implementieren. Dieses Design folgt dem Interface Segregation Principle (ISP) und stellt sicher, dass jede Klasse nur das implementiert, was sie wirklich benötigt.

Beispiel 3:

Nehmen wir an, wir haben eine Fahrzeugklasse, die sowohl fahren als auch fliegen kann:

JavaScript-Code:

class Vehicle {
  drive() {
    console.log("Driving...");
  }

  fly() {
    console.log("Flying...");
  }
}

Allerdings können nicht alle Fahrzeuge fliegen. Um dieses Problem zu lösen, können wir separate Schnittstellen erstellen:

JavaScript-Code:

class DriveOnly {
  drive() {
    console.log("Driving...");
  }
}

class FlyAndDrive {
  drive() {
    console.log("Driving...");
  }

  fly() {
    console.log("Flying...");
  }
}

Jetzt implementieren Fahrzeuge, die nur fahren können, die DriveOnly-Klasse, während Fahrzeuge, die sowohl fahren als auch fliegen können, die FlyAndDrive-Klasse implementieren. Diese Lösung folgt dem Interface Segregation Principle (ISP) und stellt sicher, dass Klassen nur die Funktionalität implementieren, die sie benötigen.

Bedeutung und reale Anwendungen von ISP:

1. Verbessert die Wartbarkeit des Codes:

   ISP stellt sicher, dass Klassen nur zum Implementieren der Methoden erforderlich sind, die sie benötigen. Dies erleichtert die Wartung des Codes, da die Klassen nicht mit unnötigen Methoden überladen sind.

2. Verwendung spezifischer Schnittstellen:

   Durch die Verwendung kleinerer, fokussierterer Schnittstellen anstelle großer, allgemeiner Schnittstellen wird die Entwicklung effizienter, da keine Notwendigkeit besteht, sich mit unnötigen Funktionen auseinanderzusetzen.

3. Real-Life-Lösung: Stellen Sie sich vor, Sie arbeiten mit verschiedenen Gerätetypen wie Druckern, Scannern und Multifunktionsgeräten. Jedes Gerät hat seine eigenen spezifischen Aufgaben. Mit ISP können Sie für jede Aufgabe (z. B. Drucken, Scannen) separate Schnittstellen erstellen, sodass jedes Gerät nur die Funktionalitäten implementiert, die es benötigt. Dadurch bleibt der Code sauber und gut organisiert.

Wann Sie ISP verwenden sollten:

• Wenn mehrere Klassen unterschiedliche Anforderungen haben, sollten Sie, anstatt eine große, verallgemeinerte Schnittstelle zu verwenden, diese in kleinere, spezifischere Schnittstellen aufteilen.

• Wenn Sie feststellen, dass eine Klasse gezwungen ist, Methoden zu implementieren, die sie nicht benötigt oder verwendet, können Sie ISP anwenden, um sicherzustellen, dass die Klasse nur relevante Funktionen implementiert.

Probleme, die durch einen Verstoß gegen den ISP verursacht werden:

1. Unnötige Methodenimplementierung: Wenn eine Klasse eine große Schnittstelle implementiert, aber nicht alle Methoden verwendet, ist sie gezwungen, unnötige Methoden zu implementieren. Dies führt zu überflüssigen Methoden im Code, die nicht benötigt werden.

2. Erhöhte Codekomplexität: Große Schnittstellen können zu übermäßigen Verantwortlichkeiten für Klassen führen, wodurch der Code unnötig komplex wird. Diese Komplexität erschwert die Wartung des Codes und die Einführung neuer Änderungen kann riskant sein.

3. Verletzung der Klassenverantwortung: Wenn ISP verletzt wird, muss eine Klasse möglicherweise Methoden implementieren, die nicht direkt mit ihrer Kernfunktionalität zusammenhängen. Dies verstößt auch gegen das Single-Responsibility-Prinzip (SRP), da die Klasse in Aufgaben außerhalb ihrer Hauptrolle verwickelt wird.

4. Wartungs- und Aktualisierungsprobleme: Wenn Änderungen an einer großen Schnittstelle vorgenommen werden, müssen sich alle Klassen, die diese Schnittstelle implementieren, an diese Änderungen anpassen. Wenn kleinere Schnittstellen verwendet würden, müssten nur die relevanten Klassen aktualisiert werden, was die Aufrechterhaltung der Konsistenz erleichtert. Die Aufrechterhaltung einer solchen Konsistenz bei großen Schnittstellen kann eine Herausforderung darstellen.

5. Verringerte Wiederverwendbarkeit von Code: Große Schnittstellen zwingen alle Klassen, alle Methoden zu implementieren, was zu einer verringerten Wiederverwendbarkeit führt. Jede Klasse enthält möglicherweise unnötigen Code, was die allgemeine Wiederverwendbarkeit des Codes verringert.

Beispiel:

Angenommen, Sie haben eine große Schnittstelle namens Worker, die die Methoden work() und eat() enthält. Für einen Roboter ist die Methode eat() nicht erforderlich, die Roboterklasse ist jedoch weiterhin erforderlich, um sie zu implementieren. Dies verstößt gegen den ISP und führt zu unnötigen Methoden, die für die Funktionalität des Roboters irrelevant sind.

Abschluss:

Daher führt ein Verstoß gegen den ISP zu einer erhöhten Codekomplexität, erschwert die Wartung und erzwingt unnötige Methodenimplementierungen.

Schnittstellentrennungsprinzip (ISP) in React

Das Interface Segregation Principle (ISP) besagt einfach, dass ein Objekt oder eine Komponente nicht gezwungen werden sollte, Methoden zu implementieren, die es nicht verwendet. Jeder Komponente sollten Methoden oder Requisiten zugewiesen werden, die für ihre spezifischen Anforderungen relevant sind.

Die Kernidee von ISP besteht darin, dass Kunden keine Schnittstellen oder APIs zur Verfügung gestellt werden sollten, die sie nicht verwenden müssen. Einfacher ausgedrückt schlägt es vor, große Schnittstellen oder Klassen in kleinere, fokussiertere zu zerlegen, damit Clients nur die Teile verwenden können, die für sie notwendig sind.

Dieser Ansatz fördert saubereren, wartbareren Code und erhöht die Flexibilität des Systems, indem sichergestellt wird, dass jede Komponente nur mit den Funktionen interagiert, die sie benötigt.

Einfaches Beispiel:

Stellen Sie sich ein Restaurant vor, das drei Arten von Kunden hat: 1) diejenigen, die kommen, um Reis zu essen, 2) diejenigen, die kommen, um Pasta zu essen, und 3) diejenigen, die kommen, um Salat zu essen. Wenn wir versorgen Wenn sie alle das gleiche Menü haben, das alles zusammen enthält, werden viele Artikel für einige Kunden irrelevant sein. Dies würde die Speisekarte für sie unnötig kompliziert machen.

Gemäß dem Interface Segregation Principle (ISP) sollte der Kunde, der Reis bestellt, nur das Reismenü erhalten, der Pastaesser sollte nur das Pastamenü erhalten und der Salatesser sollte nur das Salatmenü erhalten. Auf diese Weise wird das Erlebnis für alle vereinfacht, sodass sich jeder Kunde ohne unnötige Optionen auf das konzentrieren kann, was er tatsächlich möchte.

Diese Analogie veranschaulicht, wie ISP die Anpassung von Schnittstellen an spezifische Anforderungen fördert und so Interaktionen einfacher und effizienter macht.

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. Komplexes Abhängigkeitsmanagement: Durch die Verwendung von ISP können Komponenten oder Klassen von verschiedenen Schnittstellen abhängig gemacht werden. Dies kann das Abhängigkeitsmanagement erschweren, da mehrere Abhängigkeiten von mehreren Schnittstellen ausgehen und es schwierig ist, den Überblick zu behalten.

Zusammenfassung

Bei der Anwendung von ISP können Probleme wie die Erstellung übermäßiger Schnittstellen, erhöhte Codierung und Verwaltungsherausforderungen auftreten, die die Komplexität des Projekts erhöhen können.

Abschluss

Das Interface Segregation Principle (ISP) trägt dazu bei, Modularität und Flexibilität bei der Programmierung aufrechtzuerhalten. Durch die Zerlegung großer Schnittstellen oder Komponenten in kleinere Teile wird unnötige Komplexität vermieden. Durch die Verwendung von ISP können wir nur die erforderlichen Methoden oder Requisiten in einer Komponente implementieren, wodurch der Code einfacher, wiederverwendbarer und wartbarer wird. Obwohl es manchmal zu einer Zunahme von Schnittstellen und Code führen kann, kann es bei korrekter Anwendung die Organisation und Effektivität des Software-Designs erheblich verbessern. Daher ist die ordnungsgemäße Implementierung von ISP für eine verbesserte Qualität und einen langfristigen Erfolg in der Softwareentwicklung von entscheidender Bedeutung.

Das obige ist der detaillierte Inhalt vonI – Interface-Segregations-Prinzip (ISP). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!