Üks põhjus muutumiseks

Nii mõnegi programmeerija jaoks lõppeb objekt-orienteeritud disain vastava keelekonstruktsioonide kasutamisega. Mõnede jaoks on isegi partial sõna .NET raamistikus väärtuslik disainivõte (genereeritud koodi jaoks küll, kuid mitte erinevate kihtide loomiseks). Siinkohal seletangi ühte lihtsat printsiipi lahti, mis lõpetab selliste ulakuste teostamise (kui seda ka jälgida).

Single Responsibility Principle
Objektil peaks olema ainult üks põhjus muutumiseks.

Tundub küllaltki lihtsa printsiibina, kuid tihtipeale rikutakse seda liiga palju.

Objekt-orienteeritud raamatutes võib näha märksõnu nagu low coupling (madal sidestus) ja high cohesion (kõrge sidusus, kohesioon, mu arvates võiks seda nimetada tiheduseks) ning viimast neist võib viia kokku selle printsiibiga. See tähendab, et printsiip suunab fookuse objekti konkreetsusele ja tihedus näitab kui palju objekti atribuutidest (meetoditest, väljadest jne) on omavahel põimunud.

Kuna näited teevad elu kergemaks, siis muster, kus seda printsiipi eiratakse on Active Record (Fowler, “Patterns of Enterprise Application Architecture”, lk 160).

Vasakul pool on Active Record mustri järgi tehtud klass. Mulle isiklikult selline lähenemine ei meeldi, sest see võib käest ära minna väga lihtsalt (kui mõnda raamistikku kasutada, näiteks Castle Active Record, siis on asi veidi parem). Paremal pool on seevastu DDD ideede järgi loodud ning äriloogika ja andmete haldamise loogika on kenasti eraldatud.

NDepend-is on olemas mõõdik, mis näitab tiheduse puudumist klassi kohta. Selle abiga on võimalik üles leida võimalikud kohad, kus veidi ümber struktureerida parema objekt-orienteeritud mudeli poole. Valem ise on järgnev:

• LCOM = 1 – (sum(MF)/M*F)
• LCOM HS = (M – sum(MF)/F)(M-1)

Where:

• M is the number of methods in class (both static and instance methods are counted, it includes also constructors, properties getters/setters, events add/remove methods).
• F is the number of instance fields in the class.
• MF is the number of methods of the class accessing a particular instance field.
• Sum(MF) is the sum of MF over all instance fields of the class.

The underlying idea behind these formulas can be stated as follow: a class is utterly cohesive if all its methods use all its instance fields, which means that sum(MF)=M*F and then LCOM = 0 and LCOMHS = 0.

Soovituslik oleks hoida neid väärtusi alla 0.8 kui meetodeid on rohkem kui 10 ja välju ka üle 10.

Head nõiajahti nendele klassidele.