Mit jelent a ' magas kohézió ' jelentése?

A kohézió szemléletének egyik módja az OO szempontjából az, ha a az osztály bármelyik privát attribútumot használja. Olyan metrikák segítségével, mint az LCOM4 (a kohéziós módszerek hiánya), amire a gnat ebben a válaszban itt rámutatott , azonosítani lehet azokat az osztályokat, amelyek visszafoghatók. A metódusok vagy osztályok koherensebbé tételének oka az, hogy egyszerűbbé teszi a kódtervezést mások számára . Bízz bennem; a legtöbb műszaki vezető és karbantartó programozó szeretni fogja Önt, amikor kijavítja ezeket a problémákat.

Használhat olyan eszközöket a gyártási folyamatban, mint például a szonár azonosítsa az alacsony kohéziót a kódalapban. Van néhány nagyon gyakori eset, amelyekre gondolok, ahol a módszerek alacsonyak “összetartás” ban:

1. eset: A módszer egyáltalán nem kapcsolódik az osztályhoz

Vegye figyelembe a következő példát:

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

Az egyik módszer , Discharge() hiányzik az összetartás, mert nem érinti az osztály egyik tagját sem. Ebben az esetben csak egy privát tag van: _foodValue. Ha nem csinál semmit az osztály belsõ részeivel, akkor valóban oda tartozik? A módszer áthelyezhetõ egy másik osztályba, amely megnevezhetõ pl. FoodDischarger.

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

Javascriptben csinálod, mivel a függvények első osztályú objektumok, a mentesítés ingyenes funkció lehet:

 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  

2. eset: Segédprogram

Ez valójában egy gyakori eset, amely megtöri az összetartást. Mindenki szereti a hasznossági osztályokat, de ezek általában tervezési hibákat jeleznek, és a kódbázis fenntartását legtöbbször bonyolultabbá teszik (a segédosztályokhoz kapcsolódó nagy függőség miatt). Vegye figyelembe a következő osztályokat:

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

Itt láthatjuk, hogy a segédprogram osztályának szüksége van a Food osztályba tartozó tulajdonságok eléréséhez. A hasznossági osztályban alkalmazott módszerek ebben az esetben egyáltalán nincsenek kohézióban, mert külső erőforrásokra van szükségük a munka elvégzéséhez. Ebben az esetben nem lenne jobb, ha a módszerek abban az osztályban lennének, ahol önmagával dolgoznak ( hasonlóan az első esethez)?

2b. eset: Rejtett objektumok a segédprogram osztályaiban

Van még egy olyan segédprogram osztály, ahol nem realizált tartományi objektumok vannak. egy programozónak a karakterlánc-manipuláció programozásakor egy segédprogram osztályt kell írnia hozzá.Mint itt, amely néhány gyakori karakterlánc-ábrázolást érvényesít:

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

Mi a legtöbb nem veszi észre, hogy egy irányítószám, egy telefonszám vagy bármilyen más karakterlánc repesentáció maga is objektum lehet:

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

Az a gondolat, hogy nem szabad közvetlenül” kezelni a húrokat “, részletesen ebben a @codemonkeyism blogbejegyzésben található, de szorosan kapcsolódik a kohézióhoz, mert a programozók módja a húrok használata a logika hasznossági osztályokba helyezésével.

• Most már csak ha megszereznénk az ORM-eket az egyedi irányítószám és telefonszám osztályok megfelelő kezeléséhez: |
• +1 jó példa. Az utolsó pontot lásd még: sourcemaking.com/refactoring/primitive-obsession
• @Pete Az ORM kezeli, ha konverziót biztosít operátorok a karakterlánctól a megadott típusig (irányítószám, telefonszám): msdn.microsoft.com/en-us/library/85w54y0a.aspx

A nagy kohézió azt jelenti, hogy hasonló és kapcsolódó dolgokat együtt tartsunk, azokat a részeket összekapcsoljuk vagy összeolvasztjuk, amelyek megosztják a tartalmat, a funkcionalitást, ok vagy cél t. Más szavakkal, az alacsony kohézió például egy funkciót / osztályt / kód entitást jelenthet, amely több célt szolgál, nem pedig “ a lényegig “. Az egyik hordozó ötlet az, hogy egy dolgot csinálj és jól csinálsz . Mások tartalmazhatják azt a nyilvánvaló tényt, hogy sok helyen nem replikál hasonló funkciókat. Ez javítja a kódbázis lokalitását is, bizonyos típusú dolgok megtalálhatók egy bizonyos helyen (fájl, osztály, készlet funkciók, …) ahelyett, hogy szétszórtan lennének.

Példaként vegyünk egy osztályt, amely két vagy három célt szolgál: Erőforrásokat (például egy fájlt) tölt be / tárol, majd elemzi és megjeleníti a tartalom. Egy ilyen osztálynak alacsony kohéziója van, mert legalább két külön feladatot kezel, amelyek egyáltalán nem kapcsolódnak egymáshoz (fájl I / O, elemzés és megjelenítés). A magas kohéziójú tervezés külön osztályokat használhat az erőforrás betöltéséhez és tárolásához, elemzéséhez, majd megjelenítéséhez.

Másrészt az alacsony csatolás célja, hogy a különálló dolgokat elkülönítsék egymástól, hogy kölcsönhatásba lépjenek egymással. a lehető legkevesebbet, ami csökkenti a bonyolultságot és leegyszerűsíti a kialakítást.

Ez azt jelenti, hogy egy objektum részei szorosan összefüggenek az objektum funkciójával. Ez azt jelenti, hogy az objektumon belül a funkció vagy a felelősség szempontjából nagyon kevés vagy egyáltalán nincs hulladék. Ez pedig javíthatja annak megértését, hogy mire kell használni a tárgyat.

Megjegyzések

• nem ' t magasabb szintre is vonatkozik, mint az objektumok? pl. egy feladattal kapcsolatos objektumok / függvények csoportosítása névterekbe?