Wat is het verschil tussen cohesie en koppeling?

Hoe kunnen koppeling en samenhang leiden tot een goed of slecht softwareontwerp?

Wat zijn enkele voorbeelden die het verschil tussen de twee schetsen en hun impact op de algehele codekwaliteit?

Antwoord 1, autoriteit 100%

Samenhangverwijst naar wat de klas (of module) kan doen. Lage cohesie zou betekenen dat de klas een grote verscheidenheid aan acties doet – het is breed, niet gericht op wat het zou moeten doen. Hoge cohesie betekent dat de klas gefocust is op wat ze zou moeten doen, d.w.z. alleen methoden die betrekking hebben op de bedoeling van de klas.

Voorbeeld van lage cohesie:

-------------------
| Staff           |
-------------------
| checkEmail()    |
| sendEmail()     |
| emailValidate() |
| PrintLetter()   |
-------------------

Voorbeeld van hoge cohesie:

----------------------------
| Staff                   |
----------------------------
| -salary                 |
| -emailAddr              |
----------------------------
| setSalary(newSalary)    |
| getSalary()             |
| setEmailAddr(newEmail)  |
| getEmailAddr()          |
----------------------------

Wat betreft koppeling, het verwijst naar hoe verwant of afhankelijk twee klassen/modules ten opzichte van elkaar zijn. Voor laaggekoppelde klassen mag het veranderen van iets belangrijks in de ene klasse geen invloed hebben op de andere. Hoge koppeling zou het moeilijk maken om uw code te wijzigen en te onderhouden; aangezien klassen nauw met elkaar verweven zijn, kan het maken van een wijziging een volledige vernieuwing van het systeem vereisen.

Een goed softwareontwerp heeft hoge cohesieen lage koppeling.

Antwoord 2, autoriteit 10%

Hoge cohesie binnenmodules en lage koppeling tussenmodules worden vaak beschouwd als gerelateerd aan hoge kwaliteit in OO-programmeertalen.

De code binnen elke Java-klasse moet bijvoorbeeld een hoge interne cohesie hebben, maar zo los mogelijk zijn gekoppeld aan de code in andere Java-klassen.

Hoofdstuk 3 van Meyer’s Object-Oriented Software Construction (2e editie)is een goede beschrijving van deze problemen.

Antwoord 3, autoriteit 8%

Samenhangis een indicatie van hoe gerelateerd en gericht de verantwoordelijkheden van een software-element zijn.

Koppelingverwijst naar hoe sterk een software-element is verbonden met andere elementen.

Het software-element kan een klasse, pakket, component, subsysteem of een systeem zijn. En bij het ontwerpen van de systemen wordt aanbevolen om software-elementen te gebruiken die Hoge cohesiehebben en Lage koppelingondersteunen.

Lage cohesieresulteert in monolithische klassen die moeilijk te onderhouden en te begrijpen zijn en die herbruikbaarheid verminderen. Evenzo resulteert High Couplingin klassen die nauw aan elkaar zijn gekoppeld en veranderingen zijn meestal niet niet-lokaal, moeilijk te veranderen en verminderen het hergebruik.

We kunnen een hypothetisch scenario nemen waarin we een typische monitorbare ConnectionPoolontwerpen met de volgende vereisten. Merk op dat het misschien te veel lijkt voor een eenvoudige klasse zoals ConnectionPool, maar de basisbedoeling is om lage koppelingen hoge cohesiete demonstreren met enkele eenvoudig voorbeeld en ik denk dat het zou moeten helpen.

1. ondersteuning voor het verkrijgen van een verbinding
2. een verbinding losmaken
3. statistieken krijgen over verbinding versus gebruiksaantallen
4. statistieken krijgen over verbinding versus tijd
5. Sla het ophalen van de verbinding op en geef informatie vrij in een database om later te rapporteren.

Met lage cohesiezouden we een ConnectionPoolklasse kunnen ontwerpen door al deze functionaliteit/verantwoordelijkheden krachtig in één enkele klasse te stoppen, zoals hieronder. We kunnen zien dat deze enkele klasse verantwoordelijk is voor verbindingsbeheer, interactie met de database en het bijhouden van verbindingsstatistieken.

Met hoge cohesiekunnen we deze verantwoordelijkheid over de klassen verdelen en deze beter onderhoudbaar en herbruikbaar maken.

Om Lage koppelingte demonstreren, gaan we verder met het bovenstaande ConnectionPool-diagram met hoge cohesie. Als we naar het bovenstaande diagram kijken, hoewel het een hoge cohesie ondersteunt, is de ConnectionPoolnauw gekoppeld aan de klasse ConnectionStatisticsen PersistentStorewerkt er rechtstreeks mee samen. In plaats daarvan zouden we, om de koppeling te verminderen, een ConnectionListener-interface kunnen introduceren en deze twee klassen de interface laten implementeren en ze laten registreren bij de ConnectionPool-klasse. En de ConnectionPoolzal deze listeners doorlopen en hen op de hoogte stellen van gebeurtenissen voor het ophalen en vrijgeven van verbindingen en staat minder koppeling toe.

Note / Word of Let op: Voor dit eenvoudige scenario kan het eruit zien als een overkill, maar als we ons een real-time scenario voorstellen waar onze applicatie moet communiceren met meerdere diensten van derden om een ​​transactie te voltooien om een ​​transactie te voltooien : Direct de koppeling van onze code met de externe services zou betekenen dat eventuele wijzigingen in de Derde Partij-service kunnen leiden tot wijzigingen in onze code op meerdere plaatsen, in plaats daarvan kunnen we FacadeIntern toegankelijk hebben met deze meerdere diensten En eventuele wijzigingen in de Services worden lokaal voor de Facadeen afdwingen Low Coupling met de Diensten van derden.

4, Autoriteit 4%

Verhoogde cohesie en verminderde koppeling leiden tot goed softwareontwerp.

Cohesie-partities Uw functionaliteit, zodat het beknopt is en het dichtst bij de gegevens die eraan relevant is, terwijl ontkoppeling ervoor zorgt dat de functionele implementatie wordt geïsoleerd uit de rest van het systeem.

Ontkoppeling Hiermee kunt u de implementatie wijzigen zonder andere delen van uw software te beïnvloeden.

Cohesie zorgt ervoor dat de implementatie die specifieker is voor functionaliteit en tegelijkertijd gemakkelijker te onderhouden.

De meest effectieve methode van afnemende koppeling en toenemende cohesie is ontwerp per interface .

Dat zijn belangrijke functionele objecten mogen alleen elkaar “kennen” via de interface (s) die ze implementeren. De implementatie van een interface introduceert de cohesie als een natuurlijk gevolg.

Hoewel het niet realistisch is in sommige Senarios, moet het een ontwerpdoel zijn om langs te werken.

Voorbeeld (zeer schetsmatig):

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

Ergens anders in je codebase zou je een module kunnen hebben die vragen verwerkt, ongeacht wat ze zijn:

public class OtherModuleProcessor {
    public void Process(List<IStackoverflowQuestion> questions) {
       ... process each question.
    }
}

Antwoord 5, autoriteit 4%

beste uitleg van Cohesiekomt uit Uncle Bob’s Clean Code:

Klassen moeten een klein aantal instantievariabelen hebben. Elk van de methoden van een klasse moet een of meer van die variabelen manipuleren. In het algemeen geldt dat hoe meer variabelen een methode manipuleert, hoe meer samenhang die methode heeft met zijn klasse. Een klasse waarin elke variabele door elke methode wordt gebruikt, is maximaal samenhangend.

Over het algemeen is het niet aan te raden en ook niet mogelijk om zulke maximaal samenhangende klassen te creëren; aan de andere kant, we willen dat de cohesie hoog is. Wanneer de cohesie hoog is, betekent dit dat de methoden en variabelen van de klasse co-afhankelijk zijn en als een logisch geheel bij elkaar horen.

De strategie om functies klein te houden en parameterlijsten kort te houden, kan soms leiden tot een wildgroei aan instantievariabelen die door een subset van methoden worden gebruikt. Wanneer dit gebeurt, betekent dit bijna altijd dat er minstens één andere klas is die probeert uit de grotere klas te komen. Probeer de variabelen en methoden in twee of meer klassen te scheiden, zodat de nieuwe klassen meer samenhangend zijn.

6, Autoriteit 2%

Cohesie In Software Engineering is de mate waarin de elementen van een bepaalde module bij elkaar horen. Het is dus een maat voor hoe sterk gerelateerd is, elk stuk van functionaliteit uitgedrukt door de broncode van een softwaremodule is.

Koppeling In eenvoudige woorden, is hoeveel één component (nogmaals, een klasse voorstelt, hoewel niet noodzakelijk) weet van de innerlijke werking of innerlijke elementen van een andere, dwz hoeveel kennis het heeft de andere component.

Ik schreef een blogpost over deze , als u wilt lezen In een beetje meer details met voorbeelden en tekeningen. Ik denk dat het de meeste van uw vragen beantwoordt.

7

cohesie heeft alles te maken met hoe een enkele klasse is ontworpen. Cohesie is het objectgeoriënteerde principe dat het nauwst wordt geassocieerd met ervoor zorgen dat een klas is ontworpen met een enkel, goed gefocust doel.
Hoe meer gefocust een klas is, de samenhang van die klas is meer. De voordelen van hoge cohesie zijn dat dergelijke klassen veel gemakkelijker te onderhouden zijn (en minder vaak worden gewijzigd) dan klassen met lage cohesie. Een ander voordeel van hoge cohesie is dat klassen met een goed gefocust doel over het algemeen meer herbruikbaar zijn dan andere klassen.

In de bovenstaande afbeelding kunnen we zien dat in lage cohesie slechts één klasse verantwoordelijk is voor het uitvoeren van veel taken die niet gemeenschappelijk zijn, wat de kans op herbruikbaarheid en onderhoud verkleint. Maar bij hoge cohesie is er een aparte klasse voor alle taken om een specifieke taak uit te voeren, wat resulteert in een betere bruikbaarheid en onderhoud.

Antwoord 8

Cohesie(Co-hesion) : Cowat samenbetekent, hesionwat betekent naar stok. Het systeem van aan elkaar plakken van deeltjes van verschillende stoffen.

Voor een realistisch voorbeeld:

img met dank

Het geheel is groter dan de som van de delen – Aristoteles.

• Cohesieis een ordinaal type meting en wordt meestal beschreven als ‘hoge cohesie’ of ‘lage cohesie’. Modules met een hoge cohesie hebben meestal de voorkeur, omdat een hoge cohesie wordt geassocieerd met verschillende gewenste eigenschappen van software, waaronder robuustheid, betrouwbaarheid, herbruikbaarheid en begrijpelijkheid. Daarentegen wordt lage cohesie geassocieerd met ongewenste eigenschappen, zoals moeilijk te onderhouden, te testen, opnieuw te gebruiken of zelfs te begrijpen. wiki

• Koppelingwordt meestal gecontrasteerd met cohesie. Lage koppeling correleert vaak met hoge cohesie en vice versa. Lage koppeling is vaak een teken van een goed gestructureerd computersysteem en een goed ontwerp, en in combinatie met een hoge cohesie ondersteunt het de algemene doelen van hoge leesbaarheid en onderhoudbaarheid. wiki

Antwoord 9

Ik denk dat de verschillen als volgt kunnen worden samengevat:

• Cohesie vertegenwoordigt de mate waarin een deel van een codebasis een logisch enkele, atomaire eenheid vormt.
• Koppeling vertegenwoordigt de mate waarin een enkele eenheid onafhankelijk is van anderen.
• Het is onmogelijk om volledige ontkoppeling te archiveren zonder de samenhang te beschadigen, en vice versa.

In deze blogpostschrijf ik er meer over .

Antwoord 10

De term cohesieis inderdaad een beetje contra-intuïtief voor wat het betekent in softwareontwerp.

Cohesie gemeenschappelijke betekenis is dat iets dat goed bij elkaar blijft, is United, die wordt gekenmerkt door een sterke bandachtige moleculaire aantrekkingskracht. In softwareontwerp betekent het echter het streven naar een klasse die idealiter slechts één ding doet, dus meerdere submodules zijn niet eens betrokken.

Misschien kunnen we deze op deze manier bedenken. Een deel heeft de meeste cohesie wanneer het het enige deel is (is slechts één ding en kan niet verder worden afgebroken). Dit is wat gewenst is in softwareontwerp. Cohesie is eenvoudigweg een andere naam voor “enkele verantwoordelijkheid” of “scheiding van zorgen”.

De term Koppeling op de hand is vrij intuïtief, wat betekent wanneer een module niet afhankelijk is van te veel andere modules en die waarmee het verbindt, kan eenvoudig worden vervangen, bijvoorbeeld gehoorzamen Liskov substitutiebeginsel .

11

Cohesie is een indicatie van de relatieve functionele sterkte van een module.

• Een samenhangende module voert één taak uit, wat weinig vereist
  interactie met andere componenten in andere delen van een programma. Vermeld
  Eenvoudig, een cohesieve module moet (idealiter) slechts één ding doen.

• Conventional View:

  de “single-mindedness” van een module

• OO weergave:

  Cohesie impliceert dat een component of klasse alleen inkapseltattributen en -bewerkingen die nauw verband houden met elkaar en aan de klas of component zelf

• Lievels van cohesie

  functioneel

  Laag

  Communicational

   Vervolgens

   Procuruur

  temporaal

  Tility

Koppeling is een indicatie van de relatieve onderlinge afhankelijkheid bij modules.

• Koppeling hangt af van de complexiteit van de interface tussen modules, de
  punt waarop een module wordt ingevoerd of naar een module wordt verwezen, en welke gegevens
  passeren de interface.

• Conventionele weergave:
  De mate waarin een component verbonden is met andere componenten en met de buitenwereld

• OO view: een kwalitatieve maatstaf voor de mate waarin klassen met elkaar verbonden zijn

• Niveau van koppeling

  Inhoud

  Algemeen

  Besturing

  Stempel

  Gegevens

  Routinegesprek

  Type gebruik

  Opnemen of importeren

  Extern #

Antwoord 12

Koppeling= interactie / relatie tussen twee modules…
Cohesie= interactie tussen twee elementen binnen een module.

Een software bestaat uit vele modules. Module bestaat uit elementen. Bedenk dat een module een programma is. Een functie binnen een programma is een element.

Tijdens runtime wordt de uitvoer van een programma gebruikt als invoer voor een ander programma. Dit wordt module-naar-module-interactie of proces-naar-procescommunicatie genoemd. Dit wordt ook wel Koppeling genoemd.

Binnen een enkel programma wordt de uitvoer van een functie doorgegeven aan een andere functie. Dit wordt interactie van elementen binnen een module genoemd. Dit wordt ook wel Cohesie genoemd.

Voorbeeld:

Koppeling= communicatie tussen 2 verschillende families…
Samenhang= communicatie tussen vader-moeder-kind binnen een gezin.

Antwoord 13

Simpel gezegd, cohesiebetekent dat een klasse een enkel concept moet vertegenwoordigen.

De openbare interface van een klasse is samenhangend als alle klassekenmerken gerelateerd zijn aan het concept dat de klasse vertegenwoordigt.
In plaats van bijvoorbeeld de CashRegister-klasse te hebben, maakt de samenhang van de CashRegister- en Coin-functies het tot 2 klassen – CashRegister en Coin-klasse.

In couplingis de ene klasse afhankelijk van de andere omdat deze de objecten van de klasse gebruikt.

Het probleem met een hoge koppeling is dat het bijwerkingen kan veroorzaken. Een wijziging in de ene klasse kan een onverwachte fout veroorzaken in de andere klasse en kan de hele code breken.

Over het algemeen worden hoge cohesie en lage koppeling beschouwd als OOP van hoge kwaliteit.

Antwoord 14

Theorieverschil

Samenhang

• Cohesie is een indicatie van de relatieve functionele sterkte van een module.
• Een samenhangende module voert een enkele taak uit en vereist weinig interactie met andere
  componenten in andere delen van het programma.
• Een module met een hoge cohesie en een lage koppeling wordt functioneel onafhankelijk genoemd
  van een andere module.

Classificatie van cohesie

1. Toevallig 2. Logisch 3. Tijdelijk 4. Procedureel 5. Communicatie 6. Opeenvolgend 7. Functioneel

Koppeling

• Koppeling is een indicatie van relatieve onderlinge afhankelijkheid tussen modules.
• De mate van koppeling tussen twee modules hangt af van de complexiteit van de interface.