Unterschied zwischen Kohäsion und Kopplung

Question

Was ist der Unterschied zwischen Kohäsion und Kopplung?

Wie können Kopplung und Kohäsion zu einer guten oder schlechten Softwaregestaltung führen?

Was sind einige Beispiele, die den Unterschied zwischen den beiden und ihre Auswirkungen auf die Gesamtqualität des Codes verdeutlichen?

Answer 1

Zusammenhalt bezieht sich darauf, was die Klasse (oder das Modul) tun kann. Ein niedriger Zusammenhalt würde bedeuten, dass die Klasse eine große Vielfalt von Aktionen ausführt - sie ist breit gefächert, nicht darauf fokussiert, was sie tun sollte. Ein hoher Zusammenhalt bedeutet, dass die Klasse darauf fokussiert ist, was sie tun sollte, d.h. nur Methoden, die sich auf die Absicht der Klasse beziehen.

Beispiel für niedrigen Zusammenhalt:

-------------------
| Personal         |
-------------------
| checkEmail()     |
| sendEmail()      |
| emailValidieren()|
| BriefDrucken()   |
-------------------

Beispiel für hohen Zusammenhalt:

----------------------------
| Personal                |
----------------------------
| -Gehalt                 |
| -EmailAdresse           |
----------------------------
| setGehalt(neuesGehalt)  |
| getGehalt()             |
| setEmailAdresse(neueEmail)|
| getEmailAdresse()       |
----------------------------

Was Kopplung betrifft, bezieht es sich darauf, wie verbunden oder abhängig zwei Klassen/Module voneinander sind. Bei schwach gekoppelten Klassen sollte eine wesentliche Änderung in einer Klasse die andere nicht beeinflussen. Hohe Kopplung würde es schwierig machen, Ihren Code zu ändern und zu pflegen; da die Klassen eng miteinander verbunden sind, könnte eine Änderung eine komplette Überarbeitung des Systems erfordern.

Gute Softwareentwürfe haben hohen Zusammenhalt und geringe Kopplung.

Answer 2

Hohe Kohäsion innerhalb von Modulen und geringe Kopplung zwischen Modulen werden oft als mit hoher Qualität in OO-Programmiersprachen verbunden angesehen.

Zum Beispiel muss der Code innerhalb jeder Java-Klasse eine hohe interne Kohäsion aufweisen, aber so locker wie möglich mit dem Code in anderen Java-Klassen gekoppelt sein.

Kapitel 3 von Meyers Objektorientierte Softwarekonstruktion (2. Auflage) beschreibt diese Themen ausgezeichnet.

Answer 3

Kohäsion ist ein Hinweis darauf, wie verwandt und fokussiert die Verantwortlichkeiten eines Software-Elements sind.

Kopplung bezieht sich darauf, wie stark ein Software-Element mit anderen Elementen verbunden ist.

Das Software-Element könnte eine Klasse, ein Paket, eine Komponente, ein Subsystem oder ein System sein. Und beim Entwerfen der Systeme wird empfohlen, Software-Elemente mit hoher Kohäsion und geringer Kopplung zu haben.

Niedrige Kohäsion führt zu monolithischen Klassen, die schwer zu pflegen, zu verstehen sind und die Wiederverwendbarkeit verringern. Ähnlich führt hohe Kopplung zu Klassen, die eng miteinander verbunden sind, Änderungen sind nicht lokal durchführbar, schwer zu ändern und die Wiederverwendung verringert sich.

Wir können uns ein hypothetisches Szenario vorstellen, bei dem wir einen typischen überwachbaren ConnectionPool mit den folgenden Anforderungen entwerfen. Beachten Sie, dass dies vielleicht zu viel aussieht für eine einfache Klasse wie ConnectionPool, aber die Grundintention besteht nur darin, eine geringe Kopplung und hohe Kohäsion anhand eines einfachen Beispiels zu demonstrieren, was hoffentlich hilfreich ist.

1. Unterstützung beim Verbindungsaufbau
2. Verbindung freigeben
3. Statistiken über Verbindung vs. Nutzungsanzahl abrufen
4. Statistiken über Verbindung vs. Zeit abrufen
5. Die Verbindungsabruf- und Freigabeinformationen in einer Datenbank speichern, um sie später für Berichte zu verwenden.

Mit geringer Kohäsion könnten wir eine ConnectionPool-Klasse entwerfen, indem wir alle diese Funktionalitäten/Verantwortlichkeiten gewaltsam in eine einzige Klasse stecken, wie unten gezeigt. Wir können sehen, dass diese einzelne Klasse für die Verwaltung der Verbindung, die Interaktion mit der Datenbank sowie für die Beibehaltung von Verbindungsstatistiken verantwortlich ist.

Mit hoher Kohäsion können wir diese Verantwortlichkeiten auf die Klassen verteilen und sie wartbarer und wiederverwendbarer gestalten.

Um geringe Kopplung zu demonstrieren, werden wir mit dem Diagramm für die hohe Kohäsion des ConnectionPool oben fortfahren. Wenn wir uns das obige Diagramm ansehen, obwohl es hohe Kohäsion unterstützt, ist der ConnectionPool eng mit der Klasse ConnectionStatistics und dem PersistentStore gekoppelt, mit denen er direkt interagiert. Um die Kopplung zu reduzieren, könnten wir eine Schnittstelle ConnectionListener einführen und diese beiden Klassen die Schnittstelle implementieren lassen und sie bei der Klasse ConnectionPool registrieren lassen. Der ConnectionPool wird dann durch diese Zuhörer iterieren und sie über die Ereignisse des Verbindungsaufbaus und der -freigabe informieren und damit die Kopplung verringern.

Hinweis/Wort der Vorsicht: Für dieses einfache Szenario mag es übertrieben erscheinen, aber wenn wir uns ein Echtzeitszenario vorstellen, in dem unsere Anwendung mit mehreren Drittanbieterdiensten interagieren muss, um eine Transaktion abzuschließen: Das direkte Koppeln unseres Codes mit den Drittanbieterdiensten bedeutet, dass Änderungen an den Drittanbieterdiensten dazu führen könnten, dass unser Code an mehreren Stellen geändert werden muss, anstatt könnten wir eine Facade haben, die intern mit diesen verschiedenen Diensten interagiert und Änderungen an den Diensten werden lokal für die Facade und erzwingen eine geringe Kopplung mit den Drittanbieterdiensten.

Answer 4

Einfach ausgedrückt repräsentiert Kohäsion den Grad, in dem ein Teil einer Code-Basis eine logisch einzige, atomare Einheit bildet. Koppelung hingegen repräsentiert den Grad, in dem eine einzelne Einheit von anderen abhängig ist. Mit anderen Worten ist es die Anzahl der Verbindungen zwischen zwei oder mehr Einheiten. Je weniger Verbindungen vorhanden sind, desto geringer ist die Koppelung.

Im Wesentlichen bedeutet hohe Kohäsion, Teile einer Code-Basis, die miteinander zusammenhängen, an einem einzigen Ort zu belassen. Gleichzeitig bedeutet geringe Koppelung, nicht zusammenhängende Teile der Code-Basis so weit wie möglich zu trennen.

Arten von Code aus Kohäsions- und Koppelungsperspektive:

Ideal ist der Code, der den Richtlinien folgt. Er ist locker gekoppelt und hoch kohäsiv. Wir können einen solchen Code mit diesem Bild veranschaulichen:

Gott-Objekt ist das Ergebnis von hoher Kohäsion und hoher Koppelung. Es ist ein Anti-Muster und steht im Grunde für ein einziges Stück Code, das alles auf einmal erledigt: Schlecht ausgewählt tritt auf, wenn die Grenzen zwischen verschiedenen Klassen oder Modulen schlecht gewählt sind

Zerstörerische Entkopplung ist die interessanteste. Manchmal tritt sie auf, wenn ein Programmierer versucht, eine Code-Basis so stark zu entkoppeln, dass der Code seinen Fokus komplett verliert:

mehr dazu hier

Answer 5

Erhöhte Kohäsion und verringerte Kopplung führen zu gutem Software-Design.

Kohäsion unterteilt Ihre Funktionalität so, dass sie präzise und am nächsten an den relevanten Daten ist, während die Entkopplung sicherstellt, dass die funktionale Implementierung vom Rest des Systems isoliert ist.

Entkopplung ermöglicht es Ihnen, die Implementierung zu ändern, ohne andere Teile Ihrer Software zu beeinträchtigen.

Kohäsion stellt sicher, dass die Implementierung funktionaler und gleichzeitig einfacher zu pflegen ist.

Die effektivste Methode zur Verringerung der Kopplung und zur Steigerung der Kohäsion ist Design per Interface.

Das bedeutet, dass Hauptfunktionsobjekte sich nur über die von ihnen implementierten Schnittstellen kennen sollten. Die Implementierung einer Schnittstelle führt als natürliche Konsequenz zu Kohäsion.

Obwohl es in einigen Szenarien nicht realistisch ist, sollte es ein Designziel sein, danach zu arbeiten.

Beispiel (sehr rudimentär):

public interface IStackoverFlowQuestion
      void SetAnswered(IUserProfile user);
      void VoteUp(IUserProfile user);
      void VoteDown(IUserProfile user);
}

public class NormalQuestion implements IStackoverflowQuestion {
      protected Integer vote_ = new Integer(0);
      protected IUserProfile user_ = null;
      protected IUserProfile answered_ = null;

      public void VoteUp(IUserProfile user) {
           vote_++;
           // code to ... add to user profile
      }

      public void VoteDown(IUserProfile user) {
          decrement and update profile
      }

      public SetAnswered(IUserProfile answer) {
           answered_ = answer
           // update u
      }
}

public class CommunityWikiQuestion implements IStackoverflowQuestion {
     public void VoteUp(IUserProfile user) { // do not update profile }
     public void VoteDown(IUserProfile user) { // do not update profile }
     public void SetAnswered(IUserProfile user) { // do not update profile }
}

Irgendwo anders in Ihrem Code könnten Sie ein Modul haben, das Fragen unabhängig von ihrem Typ verarbeitet:

public class OtherModuleProcessor {
    public void Process(List questions) {
       ... bearbeiten Sie jede Frage.
    }
}