wat ‘laag in koppeling en hoog in cohesie’ betekent

Ik heb problemen met het begrijpen van de verklaring low in coupling and high in cohesion. Ik heb googled en lees hierover veel over, maar vind het nog steeds moeilijk te begrijpen.

Naar wat ik begrijp, is High cohesionbetekent, dat we lessen moeten hebben die gespecialiseerd zijn om een ​​bepaalde functie uit te voeren. Hoop dat dit correct is? Zoals een creditcardvalideklasse, die gespecialiseerd is om alleen creditcards te valideren.

en begrijp nog steeds niet wat lage koppelmiddelen betekent?


1, Autoriteit 100%

Wat ik geloof is dit:

Cohesie verwijst naar de mate waarin de elementen van een module / klas bij elkaar horen, het wordt gesuggereerd dat de gerelateerde code dicht bij elkaar moet zijn, dus we moeten streven naar hoge cohesie en verbinden alle gerelateerde code samen zo dichtbij mogelijk. Het heeft te maken met de elementen binnen de module / klasse.

Koppeling verwijst naar de mate waarin de verschillende modules / klassen van elkaar afhangen, het wordt gesuggereerd dat alle modules zo ver mogelijk onafhankelijk moeten zijn, daarom lage koppeling. Het heeft te maken met de elementen onder verschillende modules / klassen.

Om de hele foto te visualiseren, is behulpzaam:

De screenshot is gemaakt van Coursera .


2, Autoriteit 17%

Samenhangin software-engineering, zoals in het echte leven, is in hoeverre de elementen die een geheel vormen (in ons geval laten we zeggen een klasse) kunnen worden gezegd dat ze daadwerkelijk bij elkaar horen. Het is dus een maatstaf voor hoe sterk elk stukje functionaliteit dat door de broncode van een softwaremodule wordt uitgedrukt, is gerelateerd.

Een manier om naar cohesie te kijken in termen van OO is als de methoden in de klasse een van de private attributen gebruiken.

Nu is de discussie groter dan dit, maar Hoge Cohesie(of het beste type van de cohesie – de functionele cohesie) is wanneer delen van een module worden gegroepeerd omdat ze allemaal bijdragen aan een enkele goed gedefinieerde taak van de module.

Koppelingin eenvoudige bewoordingen, is hoeveel een component (nogmaals, stel je een klasse voor, hoewel niet noodzakelijkerwijs) weet over de innerlijke werking of innerlijke elementen van een andere, dwz hoeveel kennis het heeft van het andere onderdeel.

Losse koppelingis een methode om de componenten in een systeem of netwerk met elkaar te verbinden, zodat die componenten zo min mogelijk van elkaar afhankelijk zijn…

Ik heb hier een blogpost over geschreven. Het bespreekt dit alles in detail, met voorbeelden enz. Het legt ook de voordelen uit waarom u deze principes zou moeten volgen.


Antwoord 3, autoriteit 12%

In softwareontwerp betekent hoge cohesiedat de klas één ding heel goed moet doen. Hoge cohesie hangt nauw samen met het principe van één verantwoordelijkheid.

Lage koppelingsuggereert dat klasse zo min mogelijk afhankelijkheden zou moeten hebben. Afhankelijkheden die moeten bestaan, moeten ook zwakke afhankelijkheden zijn – geef de voorkeur aan afhankelijkheid van interface in plaats van afhankelijkheid van concrete klasse, of geef de voorkeur aan compositie boven overerving.

Hoge cohesie en lage koppeling geven ons een beter ontworpen code die gemakkelijker te onderhouden is.


Antwoord 4, autoriteit 8%

Kort en duidelijk antwoord

  • Hoge cohesie: elementen binnen één klasse/module moeten functioneel bij elkaar horen en één bepaald ding doen.
  • Losse koppeling: tussen verschillende klassen/modules moet een minimale afhankelijkheid zijn.

Antwoord 5, autoriteit 3%

Lage koppeling is in de context van twee of veel modules. Als een wijziging in de ene module veel wijzigingen in een andere module tot gevolg heeft, dan zijn ze sterk gekoppeld. Dit is waar interface-gebaseerd programmeren helpt. Elke wijziging binnen de module heeft geen invloed op de andere module, aangezien de interface (het gemiddelde van de interactie) ertussen niet is veranderd.

Hoge cohesie- Zet de vergelijkbare dingen bij elkaar. Dus een klas moet een methode of gedrag hebben om gerelateerd werk te doen. Om een overdreven slecht voorbeeld te geven: een implementatie van de List-interface mag geen bewerking hebben die verband houdt met String. De klasse String zou methoden moeten hebben, velden die relevant zijn voor String en op dezelfde manier zou de implementatie van List overeenkomstige dingen moeten hebben.

Hopelijk helpt dat.


Antwoord 6, autoriteit 2%

Lang verhaal kort, lage koppeling, zoals ik begreep, betekende dat componenten kunnen worden verwisseld zonder de goede werking van een systeem te beïnvloeden. Moduleer uw systeem in principe in werkende componenten die afzonderlijk kunnen worden bijgewerkt zonder het systeem te breken


Antwoord 7, autoriteit 2%

Cohesie – Hoe nauw verwant is alles met elkaar.
Koppeling – Hoe alles met elkaar is aangesloten.

Laten we een voorbeeld nemen – we willen een zelfrijdende auto ontwerpen.

(1) We hebben de motor nodig om goed te draaien.

(2) We hebben de auto nodig om op zichzelf te rijden.

Alle klassen en functies in (1) het starten van de motor en het laten werken goed werken, maar help de auto niet. Dus plaatsen we die klassen achter een motorcontroller.

Alle klassen en functies in (2) werken geweldig om de auto-stuur, versnellen en remmen te maken. Ze helpen de auto niet starten of sturen benzine naar de zuigers. Dus plaatsen we deze lessen achter zijn eigen rij-controller.

Deze controllers worden gebruikt om te communiceren met alle klassen en functies die beschikbaar zijn. De controllers communiceren vervolgens alleen met elkaar. Dit betekent dat ik geen functie in de klas van de zuiger kan bellen van de gaspedaalklasse om de auto sneller te laten gaan.

De pedaalklasse moet de rij-controller vragen om met de motorcontroller te praten die vervolgens de klas van de zuiger sneller gaat. Dit stelt Amerikaanse programmeurs in staat om problemen te vinden en stelt ons in staat om grote programma’s te combineren zonder zich zorgen te maken. Dit komt omdat de code allemaal achter de controller werkte.


8

Heb je een slimme telefoon? Is er een grote app of veel kleintjes? Antwoordt één app op een andere? Kun je één app gebruiken tijdens het installeren, updaten en / of het verwijderen van een andere? Dat elke app op zichzelf staand is, is hoge cohesie. Dat elke app onafhankelijk is van de anderen is een lage koppeling. DevOP’s gunnen deze architectuur omdat het betekent dat je discrete continue implementatie kunt doen zonder het systeem volledig te verstoren.


9

Overerving of generalisatie is een voorbeeld van hoge koppeling (d.w.z. hoge onderlinge afhankelijkheid). Wat ik hiermee bedoelde, is dat bij overerving de bovenliggende klasse vaak basisfunctionaliteiten definieert die door de onderliggende klasse worden gebruikt en dat veranderingen in de methoden van de bovenliggende klasse rechtstreeks van invloed zijn op de onderliggende klassen. Daarom kunnen we zeggen dat er een grotere mate van onderlinge afhankelijkheid tussen klassen is.

Realisatie of gebruik van interface is een voorbeeld van hoge cohesie (d.w.z. lage onderlinge afhankelijkheid). Wat dit betekent is dat een interface een contract voorstelt voor elke klasse die het implementeert, maar elke klasse heeft het recht om op zijn eigen manier in de interface gedeclareerde methoden te implementeren en wijzigingen in de in één klasse gedeclareerde methode hebben geen invloed op een andere klasse.


Antwoord 10

Lage koppeling en hoge cohesie is een aanbevolen fenomeen.

Koppeling betekent in hoeverre verschillende modules van elkaar afhankelijk zijn en hoe de andere modules worden beïnvloed bij het wijzigen van bepaalde/aanzienlijke functionaliteit van een module. Lage koppeling wordt benadrukt omdat de afhankelijkheid laag moet worden gehouden, zodat er zo min mogelijk/verwaarloosbare wijzigingen worden aangebracht in andere modules.


Antwoord 11

Een voorbeeld kan nuttig zijn. Stel je een systeem voor dat gegevens genereert en in een gegevensopslag plaatst, ofwel een bestand op schijf of een database.

Hoge samenhang kan worden bereikt door de gegevensopslagcode te scheiden van de gegevensproductiecode. (en in feite de schijfopslag scheiden van de databaseopslag).

Lage koppeling kan worden bereikt door ervoor te zorgen dat de gegevensproductie geen onnodige kennis heeft van de gegevensopslag (bijv. vraagt de gegevensopslag niet naar bestandsnamen of db-verbindingen).


Antwoord 12

Hier is een antwoord vanuit een ietwat abstracte, grafiektheoretische hoek:

Laten we het probleem vereenvoudigen door alleen naar (gerichte) afhankelijkheidsgrafieken tussen stateful-objecten te kijken.

Een uiterst eenvoudig antwoord kan worden geïllustreerd aan de hand van twee beperkingsgevallenvan afhankelijkheidsgrafieken:

Het eerste beperkende geval: een clustergrafieken.

Een clustergrafiek is de meest perfecte realisatie van een afhankelijkheidsgrafiek met hoge cohesie en lage koppeling (gezien een reeks clustergroottes).

De afhankelijkheid tussen clusters is maximaal (volledig verbonden) en de afhankelijkheid tussen clusters is minimaal (nul).

Dit is een abstracte illustratie van het antwoord in een van de beperkingsgevallen.

Het 2e limietgevalis een volledig verbonden grafiek, waarin alles van alles afhangt.

De werkelijkheid zit ergens tussenin, hoe dichter bij de clustergrafiek, hoe beter, naar mijn bescheiden mening.

Vanuit een ander gezichtspunt: als je naar een gerichte afhankelijkheidsgrafiek kijkt, zou deze idealiter acyclisch moeten zijn, zo niet, dan vormen cycli de kleinste clusters/componenten.

Eén stap omhoog/omlaag in de hiërarchie komt overeen met “één instantie” van losse koppeling, strakke cohesie in een software, maar het is mogelijk om dit principe van losse koppeling/strakke cohesie te zien als een zich herhalend fenomeen op verschillende diepten van een acyclische gerichte grafiek (of op een van zijn opspannende bomen).

Een dergelijke decompositie van een systeem in een hiërarchie helpt de exponentiële complexiteit te verslaan (stel dat elk cluster 10 elementen heeft). Dan zijn het bij 6 lagen al 1 miljoen objecten:

10 Clusters Formulier 1 Supercluster, 10 Superclusters vormen 1 Hypercluster enzovoort … Zonder het concept van strakke cohesie, losse koppeling, zou een dergelijke hiërarchische architectuur niet mogelijk zijn.

Dus dit is misschien het echte belang van het verhaal en niet alleen de hoge cohesie lage koppeling binnen twee lagen alleen. Het echte belang wordt duidelijk bij het overwegen van abstracties van hogere niveau en hun interacties.


13

Ik denk dat je rood hebt zoveel definities, maar in het geval dat je nog steeds twijfelt of als je nieuw bent om te programmeren en diep in te gaan, dan zal ik u voorstellen om deze video te bekijken,
https://youtu.be/hpjtgw9awx0
Het is gewoon verwijzing naar meer info over polymorfisme …
Ik hoop dat je hier beter kunt begrijpen


14

Laagkoppeling: –
Zal het heel eenvoudig houden.
Als u van uw module wijzigt, heeft deze invloed op andere modules.

Voorbeeld: –
Als uw service API wordt blootgesteld als pot, zal elke wijziging in de handtekening van de methode breken bellen API (hoge / strakke koppeling).

Als uw module en andere module communiceren via Async-berichten. Zolang u berichten krijgt, is uw methodewijziging van de handtekening lokaal voor uw module (lage koppeling).

Off-course Als er in het berichtformaat wordt gewijzigd, moet de oproepclient een wijziging aanbrengen.

Other episodes