Was ist der Unterschied zwischen Kohäsion und Kopplung?
Wie können Kopplung und Kohäsion zu einem guten oder schlechten Softwaredesign führen?
Welche Beispiele zeigen den Unterschied zwischen den beiden und deren Auswirkungen auf die Codequalität insgesamt?
Kohäsion bezieht sich darauf, was die Klasse (oder das Modul) tun kann. Ein niedriger Zusammenhalt würde bedeuten, dass die Klasse eine Vielzahl von Aktionen ausführt - sie ist breit gefächert und nicht auf das ausgerichtet, was sie tun soll. Hohe Kohäsion bedeutet, dass sich die Klasse auf das konzentriert, was sie tun soll, d. H. Nur Methoden, die sich auf die Absicht der Klasse beziehen.
Beispiel für niedrige Kohäsion:
-------------------
| Staff |
-------------------
| checkEmail() |
| sendEmail() |
| emailValidate() |
| PrintLetter() |
-------------------
Beispiel für hohe Kohäsion:
----------------------------
| Staff |
----------------------------
| -salary |
| -emailAddr |
----------------------------
| setSalary(newSalary) |
| getSalary() |
| setEmailAddr(newEmail) |
| getEmailAddr() |
----------------------------
In Bezug auf Kopplung bezieht es sich darauf, wie verwandt oder abhängig zwei Klassen/Module aufeinander bezogen sind. Bei niedrig gekoppelten Klassen sollte die Änderung einer Major-Klasse die andere nicht beeinflussen. Eine hohe Kopplung würde es schwierig machen, Ihren Code zu ändern und zu pflegen. Da die Klassen eng miteinander verbunden sind, kann eine Änderung des gesamten Systems erforderlich sein, um Änderungen vorzunehmen.
Gutes Softwaredesign hat hohe Kohäsion und geringe Kopplung .
In -Modulen mit hoher Kohäsion und zwischen -Modulen mit niedriger Kopplung werden oft als mit hoher Qualität in OO - Programmiersprachen in Beziehung gesetzt.
Beispielsweise muss der Code in jeder Java-Klasse eine hohe interne Kohäsion aufweisen, jedoch möglichst lose mit dem Code in anderen Java-Klassen gekoppelt sein.
Kapitel 3 von Meyers objektorientierte Softwarekonstruktion (2. Ausgabe) ist eine großartige Beschreibung dieser Probleme.
Kohäsion gibt an, wie verwandt und fokussiert die Verantwortlichkeiten eines Softwareelements sind.
Coupling bezieht sich darauf, wie stark ein Softwareelement mit anderen Elementen verbunden ist.
Das Softwareelement kann eine Klasse, ein Paket, eine Komponente, ein Subsystem oder ein System sein. Während des Entwurfs der Systeme wird empfohlen, Softwareelemente zu verwenden, die Hohe Kohäsion haben und Niedrige Kopplung unterstützen.
Niedrige Kohäsion führt zu monolithischen Klassen, die schwer zu verwalten, zu verstehen sind und die Wiederverwendbarkeit reduzieren. In ähnlicher Weise ergibt High Coupling Klassen, die eng miteinander gekoppelt sind und Änderungen nicht in der Regel nicht lokal sind, sich nur schwer ändern lassen und die Wiederverwendung reduzieren.
Wir können ein hypothetisches Szenario annehmen, in dem wir einen typischen überwachbaren ConnectionPool
mit den folgenden Anforderungen entwerfen. Beachten Sie, dass es für eine einfache Klasse wie ConnectionPool
möglicherweise zu viel aussieht. Die grundlegende Absicht ist jedoch, low Kopplung und high cohesion anhand eines einfachen Beispiels zu demonstrieren, und ich denke, es sollte helfen.
Mit low cohesion könnten wir eine ConnectionPool
-Klasse entwerfen, indem wir all diese Funktionalität/Verantwortlichkeiten zwangsweise in eine einzige Klasse stecken. Wir können sehen, dass diese einzelne Klasse für das Verbindungsmanagement verantwortlich ist, mit der Datenbank interagiert und die Verbindungsstatistiken verwaltet.
Mit high cohesion können wir diese Verantwortung über alle Klassen hinweg zuordnen und sie pflegen und wiederverwenden.
Um die Low-Kopplung zu demonstrieren, fahren wir mit dem oben gezeigten Diagramm der hohen Kohäsion ConnectionPool
fort. Wenn Sie sich das obige Diagramm anschauen, obwohl es eine hohe Kohäsion unterstützt, ist ConnectionPool
eng mit ConnectionStatistics
class verbunden und PersistentStore
interagiert direkt mit ihnen. Anstatt die Kopplung zu reduzieren, können Sie eine ConnectionListener
- Schnittstelle einführen und diese beiden Klassen die Schnittstelle implementieren lassen und sich bei der Klasse ConnectionPool
registrieren lassen. Das ConnectionPool
durchläuft diese Listener und benachrichtigt sie über Verbindungsereignisse und -freigaben und ermöglicht weniger Kopplung.
Note/Word oder Vorsicht: Für dieses einfache Szenario kann es wie ein Overkill aussehen. Wenn wir uns jedoch ein Echtzeitszenario vorstellen, in dem unsere Anwendung mit mehreren Drittanbieterdiensten interagieren muss, um eine Transaktion abzuschließen: Direktes Koppeln unseres Codes mit Die Drittanbieter-Services würden bedeuten, dass Änderungen am Drittanbieter-Service an mehreren Stellen zu Änderungen an unserem Code führen könnten, stattdessen könnten wir Facade
haben, die intern mit diesen mehreren Services interagieren, und Änderungen an den Services werden lokal die Facade
und erzwingen eine niedrige Kopplung mit den Diensten Dritter.
Kohäsion ist die Angabe der Beziehung innerhalb eines Moduls.
Coupling ist die Angabe der Beziehungen zwischen -Modulen.
Kohäsion
Kopplung
check this link
Erhöhte Kohäsion und verminderte Kopplung führen zu einem guten Softwaredesign.
Kohäsion partitioniert Ihre Funktionalität so, dass sie präzise und den für sie relevanten Daten am nächsten kommt, während die Entkopplung gewährleistet, dass die funktionale Implementierung vom Rest des Systems isoliert ist.
Decoupling ermöglicht es Ihnen, die Implementierung zu ändern, ohne andere Teile Ihrer Software zu beeinflussen.
Cohesion stellt sicher, dass die Implementierung funktionaler ist und gleichzeitig einfacher zu warten ist.
Die effektivste Methode, die Kopplung zu verringern und die Kohäsion zu erhöhen, ist Design by interface .
Das heißt, wichtige Funktionsobjekte sollten sich nur über die von ihnen implementierten Schnittstellen "kennen". Die Implementierung einer Schnittstelle führt zu einer natürlichen Konsequenz.
Obwohl dies in manchen Szenarien nicht realistisch ist, sollte es ein Entwurfsziel sein, nach dem zu arbeiten.
Beispiel (sehr skizzenhaft):
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 }
}
An anderen Stellen in Ihrer Codebasis könnten Sie ein Modul haben, das Fragen verarbeitet, unabhängig davon, was sie sind:
public class OtherModuleProcessor {
public void Process(List<IStackoverflowQuestion> questions) {
... process each question.
}
}
beste Erklärung für Kohäsion kommt von Uncle Bobs Clean Code:
Klassen sollten eine kleine Anzahl von Instanzvariablen haben. Jede der Methoden einer Klasse sollte eine oder mehrere dieser Variablen bearbeiten. Im Allgemeinen gilt: Je mehr Variablen eine Methode manipuliert, desto kohärenter ist diese Methode mit ihrer Klasse . Eine Klasse, in der jede Variable von jeder Methode verwendet wird, ist maximal kohäsiv.
Im Allgemeinen ist es weder ratsam noch möglich, solche maximal zusammenhängenden Klassen zu schaffen; Andererseits - wir möchten, dass der Zusammenhalt hoch ist . Wenn die Kohäsion hoch ist, bedeutet dies, dass die Methoden und Variablen der Klasse voneinander abhängig sind und als logisches Ganzes zusammenhängen.
Die Strategie, Funktionen klein zu halten und Parameterlisten kurz zu halten, kann manchmal zu einer Zunahme von Instanzvariablen führen, die von einer Teilmenge von Methoden verwendet werden. In diesem Fall bedeutet es fast immer, dass mindestens eine andere Klasse versucht, aus der größeren Klasse auszusteigen. Sie sollten versuchen, die Variablen und Methoden in zwei oder mehr Klassen aufzuteilen, so dass die neuen Klassen kohärenter sind.
Kohäsion im Software-Engineering ist der Grad, zu dem die Elemente eines bestimmten Moduls zusammengehören. Somit ist es ein Maß dafür, wie stark die einzelnen Funktionen des Quellcodes eines Softwaremoduls zusammenhängen.
Coupling in einfachen Worten ist, wie viel eine Komponente (wiederum eine Klasse, wenn auch nicht notwendigerweise) über die inneren Funktionen oder inneren Elemente einer anderen Komponente weiß, d. H. Wie viel Wissen sie über die andere Komponente hat.
Ich habe einen Blogbeitrag darüber geschrieben , wenn Sie etwas mehr Details mit Beispielen und Zeichnungen nachlesen möchten. Ich denke, es beantwortet die meisten Ihrer Fragen.
kohäsion bezieht sich auf die Gestaltung einer einzelnen Klasse. Kohäsion ist das objektorientierte Prinzip, das am engsten damit verbunden ist, sicherzustellen, dass eine Klasse mit einem einzigen, gut fokussierten Zweck entworfen wurde. Je fokussierter eine Klasse ist, desto mehr ist der Zusammenhalt dieser Klasse. Der Vorteil einer hohen Kohäsion besteht darin, dass solche Klassen viel einfacher zu pflegen (und seltener zu wechseln) sind als Klassen mit geringer Kohäsion. Ein weiterer Vorteil der hohen Kohäsion besteht darin, dass Klassen mit einem gut fokussierten Zweck in der Regel wiederverwendbarer sind als andere Klassen.
Im obigen Bild können wir sehen, dass bei geringer Kohäsion nur eine Klasse für die Ausführung vieler nicht gemeinsamer Arbeiten verantwortlich ist, was die Wahrscheinlichkeit der Wiederverwendbarkeit und Wartung verringert. Bei hoher Kohäsion gibt es jedoch eine separate Klasse für alle Jobs, um einen bestimmten Job auszuführen, was zu einer besseren Benutzerfreundlichkeit und Wartung führt.
Kohäsion (Co-hesion): Co was zusammen bedeutet, hesion was bedeutet, zu bleiben. Das System des Zusammenklebens von Partikeln verschiedener Substanzen.
Für ein reales Beispiel:
img Courtesy
Das Ganze ist größer als die Summe der Teile - Aristoteles.
Kohäsion ist eine ordinale Art der Messung und wird üblicherweise als „hohe Kohäsion“ oder „niedrige Kohäsion“ bezeichnet. Module mit hoher Kohäsion sind in der Regel vorzuziehen, da eine hohe Kohäsion mit mehreren wünschenswerten Eigenschaften von Software verbunden ist, einschließlich Robustheit, Zuverlässigkeit, Wiederverwendbarkeit und Verständlichkeit. Im Gegensatz dazu ist eine niedrige Kohäsion mit unerwünschten Merkmalen verbunden, wie zum Beispiel schwierig zu warten, zu testen, wiederzuverwenden oder sogar zu verstehen. wiki
Kopplung wird normalerweise Kohäsion gegenübergestellt. Niedrige Kopplung korreliert oft mit hoher Kohäsion und umgekehrt. Niedrige Kopplung ist oft ein Zeichen für ein gut strukturiertes Computersystem und ein gutes Design. In Kombination mit hoher Kohäsion werden die allgemeinen Ziele einer hohen Lesbarkeit und Wartbarkeit unterstützt. wiki
Ich denke, die Unterschiede können wie folgt ausgedrückt werden:
In diesem Blogbeitrag schreibe ich ausführlicher darüber.
Cohesion repräsentiert einfach den Grad, zu dem ein Teil einer Codebasis eine logisch einzelne, atomare Einheit bildet. Coupling dagegen repräsentiert den Grad, in dem eine einzelne Einheit unabhängig von anderen ist. Mit anderen Worten, es ist die Anzahl der Verbindungen zwischen zwei oder mehreren Einheiten. Je geringer die Anzahl ist, desto niedriger ist die Kopplung.
Im Wesentlichen bedeutet hohe Kohäsion, dass Teile einer Codebasis, die miteinander in Beziehung stehen, an einem einzigen Ort gehalten werden. Bei niedriger Kopplung geht es gleichzeitig darum, nicht zusammenhängende Teile der Codebasis so weit wie möglich zu trennen.
Codetypen aus Kohäsions- und Kopplungssicht:
Ideal ist der Code, der der Richtlinie folgt. Es ist lose gekoppelt und stark zusammenhaltend. Wir können diesen Code mit diesem Bild veranschaulichen:
God Object ist das Ergebnis der Einführung einer hohen Kohäsion und einer hohen Kopplung. Es ist ein Anti-Pattern und steht im Wesentlichen für einen einzelnen Code, der die gesamte Arbeit auf einmal erledigt: schlecht ausgewählt findet statt, wenn die Grenzen zwischen verschiedenen Klassen oder Modulen schlecht gewählt werden
Die destruktive Entkopplung ist am interessantesten. Es tritt manchmal auf, wenn ein Programmierer versucht, eine Codebasis so stark zu entkoppeln, dass der Code den Fokus vollständig verliert:
lesen Sie mehr hier
Kopplung = Interaktion/Beziehung zwischen zwei Modulen ... Kohäsion = Interaktion zwischen zwei Elementen in einem Modul.
Eine Software besteht aus vielen Modulen. Modul besteht aus Elementen. Betrachten Sie ein Modul als Programm. Eine Funktion innerhalb eines Programms ist ein Element.
Zur Laufzeit wird die Ausgabe eines Programms als Eingabe für ein anderes Programm verwendet. Dies wird als Modul-zu-Modul-Interaktion oder als Prozess zur Verarbeitung der Kommunikation bezeichnet. Dies wird auch als Kopplung bezeichnet.
Innerhalb eines einzelnen Programms wird die Ausgabe einer Funktion an eine andere Funktion übergeben. Dies wird als Interaktion von Elementen innerhalb eines Moduls bezeichnet. Dies wird auch als Kohäsion bezeichnet.
Beispiel:
Kopplung = Kommunikation zwischen zwei verschiedenen Familien ... Kohäsion = Kommunikation zwischen Vater-Mutter-Kind innerhalb einer Familie.
Kohäsion ist ein Hinweis auf die relative Funktionsstärke eines Moduls.
Konventionelle Sicht:
die "Zielstrebigkeit" eines Moduls
OO Ansicht:
"Kohäsion" impliziert, dass eine Komponente oder Klasse nur Attribute und Operationen enthält, die eng miteinander und mit der Klasse oder Komponente selbst verwandt sind
Kohäsionsebenen
Funktional
Layer
Kommunikation
Sequivalent
Procedural
Temporal
Utilität
Kopplung ist ein Hinweis auf die relative Abhängigkeit zwischen Modulen.
Die Kopplung hängt von der Komplexität der Schnittstelle zwischen den Modulen ab, dem Punkt, an dem der Eintrag oder der Bezug zu einem Modul gemacht wird, und den Daten, die die Schnittstelle passieren.
Konventionelle Ansicht: Der Grad, zu dem eine Komponente mit anderen Komponenten und der Außenwelt verbunden ist
OO-Sicht: Ein qualitatives Maß für die Verbindung der Klassen untereinander
Kopplungsgrad
Inhalt
Gemeinsam
Kontrolle
Stempel
Daten
Routine-Anruf
Typ verwenden
Einschluss oder Import
Externe #
Der Begriff Kohäsion ist in der Tat ein wenig kontraintuitiv für das, was er im Software-Design bedeutet.
Kohäsion Gemeine Bedeutung ist, dass etwas, das gut zusammenhält, vereint ist, die sich durch starke bindungsähnliche molekulare Anziehungskraft auszeichnen. Im Software-Design bedeutet dies jedoch, eine Klasse anzustreben, die im Idealfall nur eines tut, sodass nicht einmal mehrere Submodule beteiligt sind.
Vielleicht können wir uns das so vorstellen. Ein Teil hat den größten Zusammenhalt, wenn es der einzige Teil ist (macht nur eine Sache und kann nicht weiter zerlegt werden). Dies ist das, was im Software-Design gewünscht wird. Kohäsion ist einfach eine andere Bezeichnung für "Einzelverantwortung" oder "Trennung von Anliegen".
Der Begriff Kopplung ist auf der Hand ziemlich intuitiv, was bedeutet, dass ein Modul nicht von zu vielen anderen Modulen abhängt und die, mit denen es verbunden ist, leicht sein können ersetzt zum Beispiel unter Beachtung Liskov-Substitutionsprinzip .
Vereinfacht ausgedrückt bedeutet Kohäsion , dass eine Klasse ein einzelnes Konzept darstellen soll.
Die öffentliche Schnittstelle einer Klasse ist zusammenhängend, wenn alle Klassenmerkmale mit dem von der Klasse repräsentierten Konzept in Beziehung stehen Anstelle der Klasse CashRegister können die Funktionen CashRegister und Coin in zwei Klassen aufgeteilt werden - CashRegister und Coin Klasse.
In Kopplung hängt eine Klasse von einer anderen ab, da sie die Objekte der Klasse verwendet.
Das Problem bei hoher Kopplung ist, dass es Nebenwirkungen verursachen kann. Eine Änderung in einer Klasse kann zu einem unerwarteten Fehler in der anderen Klasse führen und den gesamten Code beschädigen.
Im Allgemeinen werden hohe Kohäsion und niedrige Kopplung als qualitativ hochwertige OOP betrachtet.