Wat is de betekenis van ' hoge cohesie '?

Een manier om cohesie te zien in termen van OO is als de methoden in de klas gebruikt een van de privéattributen. Met behulp van statistieken zoals LCOM4 (Gebrek aan samenhangende methoden), zoals aangegeven door gnat in dit antwoord hier , kunt u klassen identificeren die kunnen worden geherstructureerd. De reden dat u methoden of klassen wilt herstructureren om meer samenhang te geven, is dat het het codeontwerp eenvoudiger maakt voor anderen om het te gebruiken . Geloof me; de meeste technische leads en onderhoudsprogrammeurs zullen van je houden als je deze problemen oplost.

Je kunt tools gebruiken in je bouwproces zoals Sonar om identificeer lage cohesie in de codebasis. Er zijn een paar veel voorkomende gevallen die ik kan bedenken waarbij methoden weinig “cohesie” hebben:

Geval 1: Methode is helemaal niet gerelateerd aan de klasse

Beschouw het volgende voorbeeld:

 public class Food { private int _foodValue = 10; public void Eat() { _foodValue -= 1; } public void Replenish() { _foodValue += 1; } public void Discharge() { Console.WriteLine("Nnngghhh!"); } }  

Een van de methoden , Discharge(), mist samenhang omdat het “geen van de privéleden van de klas raakt”. In dit geval is er maar één privélid: _foodValue. Als het niets met de internals van de klas doet, hoort het daar dan echt thuis? De methode zou naar een andere klasse kunnen worden verplaatst die bijvoorbeeld FoodDischarger zou kunnen heten.

 // Non-cohesive function extracted to another class, which can // be potentially reused in other contexts public FoodDischarger { public void Discharge() { Console.WriteLine("Nnngghhh!"); } }  

Als je het in Javascript doet, aangezien functies eersteklas objecten zijn, kan een gratis functie zijn:

 function Food() { this._foodValue = 10; } Food.prototype.eat = function() { this._foodValue -= 1; }; Food.prototype.replenish = function() { this._foodValue += 1; }; // This Food.prototype.discharge = function() { console.log("Nnngghhh!"); }; // can easily be refactored to: var discharge = function() { console.log("Nnngghhh!"); }; // making it easily reusable without creating a class  

Case 2: Utility Class

Dit is eigenlijk een veelvoorkomend geval dat de samenhang verbreekt. Iedereen houdt van utility-klassen, maar deze duiden meestal op ontwerpfouten en maken de codebase meestal moeilijker te onderhouden (vanwege de grote afhankelijkheid die geassocieerd wordt met utility-klassen). Beschouw de volgende klassen:

 public class Food { public int FoodValue { get; set; } } public static class FoodHelper { public static void EatFood(Food food) { food.FoodValue -= 1; } public static void ReplenishFood(Food food) { food.FoodValue += 1; } }  

Hier kunnen we zien dat de utility-klasse om toegang te krijgen tot een eigenschap in de klasse Food. De methoden in de utility-klasse hebben in dit geval helemaal geen samenhang omdat het externe bronnen nodig heeft om het werk te doen. Zou het in dit geval niet beter zijn om de methoden in de klasse waarmee ze zelf werken te hebben ( net zoals in het eerste geval)?

Geval 2b: Verborgen objecten in Utility Classes

Er is een ander geval van utility classes waar er niet-gerealiseerde domeinobjecten zijn. een programmeur moet bij het programmeren van stringmanipulatie er een utility class voor schrijven.Zoals degene hier die een aantal veelvoorkomende stringvoorstellingen valideert:

 public static class StringUtils { public static bool ValidateZipCode(string zipcode) { // validation logic } public static bool ValidatePhoneNumber(string phoneNumber) { // validation logic } }  

Wat de meesten beseffen hier niet dat een postcode, een telefoonnummer of een andere tekenreeksrepresentatie zelf een object kan zijn:

 public class ZipCode { private string _zipCode; public bool Validates() { // validation logic for _zipCode } } public class PhoneNumber { private string _phoneNumber; public bool Validates() { // validation logic for _phoneNumber } }  

Het idee dat je strings niet rechtstreeks” moet behandelen “wordt gedetailleerd in deze blogpost door @codemonkeyism , maar hangt nauw samen met cohesie, omdat de manier waarop programmeurs strings gebruiken door logica in utility-klassen te plaatsen.

Opmerkingen

• Als we nu maar onze ORMs konden krijgen om onze aangepaste ZipCode- en PhoneNumber-klassen correct af te handelen: |
• +1 goede voorbeelden. Zie voor het laatste punt ook sourcemaking.com/refactoring/primitive-obsession
• @Pete Uw ORM zal het afhandelen als u conversie levert operators van string naar uw gedefinieerde type (postcode, telefoonnummer): msdn.microsoft.com/en-us/library/85w54y0a.aspx

Hoge cohesie betekent soortgelijke en gerelateerde dingen bij elkaar houden, onderdelen koppelen of samensmelten die inhoud, functionaliteit delen, reden of doel . Met andere woorden, lage cohesie zou bijvoorbeeld een functie / klasse / code-entiteit kunnen betekenen die meerdere doelen dient in plaats van “ to the point ” te zijn. Een van de belangrijkste ideeën is om één ding te doen en het goed te doen . Andere kunnen het voor de hand liggende feit bevatten dat u op veel plaatsen geen vergelijkbare functionaliteit repliceert. Dit verbetert ook de lokaliteit van de codebasis; bepaalde soorten dingen worden op een bepaalde plaats gevonden (bestand, klasse, set functies, …) in plaats van verspreid te zijn.

Beschouw als voorbeeld een klasse die twee of drie doelen dient: laadt / slaat bronnen op (bijvoorbeeld een bestand) en analyseert en toont vervolgens de inhoud. Zon klasse heeft lage cohesie omdat ze ten minste twee afzonderlijke taken beheert die helemaal niet gerelateerd zijn (bestands-I / O, analyse en weergave). Een ontwerp met hoge cohesie zou verschillende klassen kunnen gebruiken voor het laden en opslaan van de bron, deze te analyseren en vervolgens weer te geven.

Aan de andere kant is een lage koppeling bedoeld om verschillende dingen gescheiden te houden, zodat ze met elkaar communiceren zo min mogelijk, wat dan de complexiteit vermindert en het ontwerp vereenvoudigt.

Het betekent dat de delen van een object nauw verband houden met de functie van het object. Dit betekent dat er qua functie of verantwoordelijkheid weinig of geen afval in het object zit. Dit kan op zijn beurt het begrip verbeteren van waarvoor het object in kwestie zou moeten worden gebruikt.

Opmerkingen

• doet niet ' Is het ook van toepassing op een hoger niveau dan alleen objecten? bijv. het groeperen van objecten / functies gerelateerd aan een taak in naamruimten?