Kódmetrikák – Osztálykapcsolás

Az osztálykapcsolódás a CK94 által eredetileg definiált objektumok közötti csatolás (CBO) néven is szerepel. Az osztálykapcsolás alapvetően annak mértéke, hogy egy osztály hány osztályt használ. A magas szám rossz, és az alacsony szám általában jó ezzel a metrikával. Az osztálykapcsolódás a szoftverhibák pontos előrejelzését mutatja, és a legutóbbi tanulmányok kimutatták, hogy a 9-et tartalmazó felső határérték a leghatékonyabb S2010.

A Microsoft dokumentációja szerint az osztálykapcsolás "paraméterek, helyi változók, visszatérési típusok, metódushívások, általános vagy sablonalapú példányok, alaposztályok, felületi implementációk, külső típusokon definiált mezők és attribútumdekorációk révén méri az egyedi osztályokhoz való csatlakozást. A jó szoftvertervezés azt diktálja, hogy a típusok és módszerek nagy kohézióval és alacsony összekapcsolásokkal rendelkezzenek. A magas összekapcsolás olyan kialakítást jelez, amelyet nehéz újrahasználni és karbantartani, mert sok függés van más típusok esetében."

Az összekapcsolás és a kohézió fogalmai egyértelműen összefüggnek. A témával kapcsolatos vita megtartása érdekében nem jutunk mélyebbre a kohézióval, csak azért, hogy röviden meghatározzuk KKLS2000:

"A modul-kohéziót a Yourdon és a Constantine vezette be, mint "a modul belső elemei mennyire szorosan kötődnek egymáshoz" YC79. Egy modul erős kohézióval rendelkezik, ha pontosan egy feladatot jelöl [...], és minden eleme hozzájárul ehhez az egyetlen tevékenységhez. A kohéziót a tervezés attribútumaként írják le kód helyett, és olyan attribútumként, amely felhasználható az újrafelhasználhatóság, a karbantarthatóság és a megváltoztathatóság előrejelzésére."

Példa osztálykapcsolóra

Vizsgáljuk meg az osztálykapcsolódást működés közben. Először hozzon létre egy új konzolalkalmazást, és hozzon létre egy Személy nevű új osztályt néhány tulajdonsággal, majd azonnal kiszámítja a kódmetrikákat:

Figyelje meg, hogy az osztálykapcsoló 0, mivel ez az osztály nem használ más osztályokat. Most hozzon létre egy PersonStuff nevű osztályt egy olyan metódussal, amely létrehozza a Person egy példányát, és beállítja a tulajdonságértékeket. Számítsa ki újra a kódmetrikákat:

Látja, hogyan emelkedik az osztálykapcsolat értéke? Azt is figyelje meg, hogy függetlenül attól, hogy hány tulajdonságot állított be, az osztálykapcsoló értéke csak 1-sel megy fel, és nem valamilyen más értékkel. Az osztálykapcsolódás ezt a metrikát csak egyszer méri minden egyes osztályra, feleslegesen attól, hogy mennyit használják azt. Ezenkívül láthatja, hogy DoSomething() értéke 1, de a konstruktor, PersonStuff(), értéke 0. Jelenleg nincs olyan kód a konstruktorban, amely egy másik osztályt használ.

Mi a teendő, ha egy másik osztályt használó konstruktorban kódot helyez el? A következőt kapja:

Most a konstruktor egyértelműen rendelkezik egy másik osztályt használó kóddal, és az osztálykapcsolódási metrika ezt a tényt mutatja. Ismét láthatja, hogy a teljes osztálykapcsoló PersonStuff() 1, és DoSomething() egyben 1 is, amely azt mutatja, hogy csak egy külső osztályt használ, függetlenül attól, hogy mennyi belső kód van használatban.

Ezután hozzon létre egy másik új osztályt. Adjon nevet ennek az osztálynak, és hozzon létre benne néhány tulajdonságot:

Használja fel az osztályt a DoSomething() metódusban a PersonStuff osztályon belül, és számolja ki újra a kódmetrikát:

Mint látható, a PersonStuff osztály összekapcsoltsága 2-ig terjed, és ha részletesen megvizsgálja az osztályt, láthatja, hogy a DoSomething() metódusban van a legtöbb összekapcsolás, de a konstruktor csak 1 osztályt használ. Ezekkel a metrikákkal megtekintheti egy adott osztály teljes maximális számát, és tagonként részletezheti a részleteket.

A varázslatos szám

A ciklonos összetettséghez hasonlóan nincs minden szervezetnek megfelelő korlát. Az S2010 azonban azt jelzi, hogy a 9-ből álló korlát optimális:

"Ezért a küszöbértékeket tekintjük a leghatékonyabbnak." Ezek a küszöbértékek (egyetlen tag esetén) CBO = 9[...]." (kiemelés hozzáadva)

Kódelemzés

A kódelemzés tartalmazza a karbantarthatósági szabályok egy kategóriáját. További információ: Karbantarthatósági szabályok. Az örökölt kódelemzés használatakor a kiterjesztett tervezési útmutató szabálykészlet egy karbantarthatósági területet tartalmaz:

A karbantarthatósági területen belül az osztálykapcsolódás egyik szabálya:

Ez a szabály figyelmeztetést ad ki, ha az osztálykapcsolódás túlzott. További információ: CA1506: A túlzott osztálykapcsolódás elkerülése.

Idézetek

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, No. 6). Lekért május 14, 2011, a University of Pittsburgh honlapján: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., and Saint-Denis, G. (2000). Kohézió újraértékelése: Empirikus tanulmány ipari rendszereken (Műhelytanulmány az objektumorientált szoftverfejlesztés kvantitatív megközelítései témájában). Beolvasva: 2011. május 20. Az Université de Montréal webhelyéről http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). A CK-metrikák empirikus elemzése Object-Oriented tervezés összetettségéhez: A szoftverhibák következményei (IEEE-tranzakciók a szoftverfejlesztésben, 29. kötet, 4. sz.).

S2010

Shatnawi, R. (2010). A Object-Oriented metrikák elfogadható kockázati szintjeinek mennyiségi vizsgálata Open-Source rendszerekben (IEEE-tranzakciók a szoftverfejlesztésben, vol. 36, No. 2).

YC79

Edward Yourdon és Larry L. Constantine. Strukturált tervezés. Prentice Hall, Englewood Cliffs, N.J., 1979.