Coeziunea (Cohesion) în dezvoltarea mobilă: baze, niveluri și cum să o crești

Ce este Cohesion

Cohesion (coeziunea) — metrică care evaluează cât de mult sunt legate logic metodele, câmpurile și proprietățile dintr-o singură clasă sau modul. Un modul cu coeziune înaltă îndeplinește o singură sarcină și conține doar elementele necesare pentru aceasta. Un modul cu coeziune scăzută încearcă să facă mai multe lucruri simultan — metodele sunt slab legate din punct de vedere semantic.

În contextul programării orientate pe obiecte, cohesion este strâns legat de Single Responsibility Principle (S). Dacă o clasă are o singură responsabilitate clară, cohesion-ul său este, de regulă, ridicat. Dacă o clasă se ocupă atât de UI, cât și de logica de afaceri și de comunicarea rețea — cohesion-ul este scăzut și o astfel de clasă trebuie împărțită în mai multe clase separate cu responsabilitate mai restrânsă.

Înțelegerea cohesion ajută programatorul să ia decizii de refactorizare. Când vedeți că într-o clasă există o metodă care nu folosește câmpurile clasei, acesta este un semnal de coeziune scăzută. O astfel de metodă fie este de prisos în clasă, fie clasa este prost proiectată. Tendința spre coeziune înaltă — este o muncă continuă de îmbunătățire a arhitecturii la fiecare nivel al codului.

Tipuri și niveluri de coeziune

În ingineria software se disting șapte niveluri de cohesion, aranjate de la cel mai prost la cel mai bun. Înțelegerea acestei scale permite evaluarea obiectivă a calității unui modul și determinarea direcției de urmat în refactorizare. Cu cât nivelul este mai înalt, cu atât codul va fi mai ușor de întreținut și de înțeles.

Coeziune scăzută: coincidentală, logică și temporală

Coincidentală (coincidental) — cel mai prost nivel, când elementele din modul sunt grupate aleatoriu, fără nicio legătură logică. Exemplu: clasa Utilities, care conține metode de formatare a datei, trimitere de email și calculare a discountului. O astfel de clasă nu poate fi înțeleasă fără citirea tuturor metodelor, iar modificarea unei metode poate strica altele doar pentru că se află în apropiere.

Logică (logical) coeziune — elementele îndeplinesc sarcini logic legate, dar diferite ca esență. O clasă cu metodele parseJSON, parseXML și parseCSV este logic legată de tema „parsare“, dar fiecare metodă face o treabă fundamental diferită. Problemă: la adăugarea unui format nou (YAML), clasa crește, iar interfața sa devine îmflată.

Temporală (temporal) coeziune — elementele sunt grupate după timpul de execuție. Clasa AppInitializer, care configurează baza de date, încarcă configurarea, inițializează analitica — toate acestea se întâmplă la pornirea aplicației, dar sarcinile în sine nu sunt legate între ele. Mai bine să le împărțim în Initializer separate pentru fiecare zonă de responsabilitate.

Coeziune medie: procedurală și comunicațională

Procedurală (procedural) coeziune apare când elementele sunt unite prin succesiunea de execuție. Modulul „Procesare comandă” conține metodele validateCart, processPayment, sendConfirmation — fiecare metodă este apelată strict după precedenta. Este mai bine decât coeziunea coincidentală sau logică, dar încă nu este ideal: fiecare pas poate fi extras într-un modul separat.

Comunicațională (communicational) coeziune — elementele lucrează cu aceleași date. Clasa UserService cu metodele getUser, updateUser, deleteUser este unită de entitatea comună User. Este semnificativ mai bine decât coeziunea procedurală: clasa are un domeniu clar. Majoritatea claselor Repository din proiectele mobile au coeziune comunicațională.

Coeziune înaltă: funcțională

Funcțională (functional) coeziune — cel mai înalt nivel, când fiecare element al modulului participă la executarea unei singure sarcini. Clasa PasswordValidator cu unica metodă validate, care verifică lungimea, prezența caracterelor și complexitatea parolei — exemplu de coeziune funcțională. Dacă o astfel de clasă se schimbă, este doar pentru că s-au schimbat regulile de validare a parolelor.

Obținerea coeziunii funcționale — scopul principal al refactorizării arhitecturale. Fiecare clasă trebuie să aibă exact un motiv pentru a se schimba. În dezvoltarea mobilă, coeziunea funcțională se obține prin extragerea de Use Cases separate, View-uri personalizate, formattere și validatoare. Fiecare astfel de clasă este un bloc de construcție complet, cu o zonă clară de responsabilitate.

Cohesion vs Coupling

Cohesion și coupling — două fețe ale aceleiași calități. Cu cât cohesion-ul din interiorul unui modul este mai mare, cu atât coupling-ul între module este, de regulă, mai mic. Un sistem bine proiectat tinde simultan spre coeziune înaltă în interior și legătură slabă în exterior. Această regulă este considerată fundamentală în ingineria software încă din anii 1970.

Raportul cohesion-coupling poate fi reprezentat ca un echilibru. Dacă programatorul sacrifică cohesion-ul, combinând mai multe sarcini într-o singură clasă, modulele vecine primesc mai multe dependențe — trebuie să apeleze la această clasă supraîncărcată în scopuri diferite, ceea ce crește coupling-ul. Și invers, împărțirea în clase mici, cu coeziune înaltă, reduce numărul de puncte de interacțiune între module.

În practică aceasta înseamnă: când extrageți o nouă clasă cu coeziune funcțională, eliberați simultan alte module de necesitatea de a cunoaște detaliile implementării sale. De exemplu, extrăgând EncryptionManager într-o clasă separată cu coeziune funcțională, oferiți altor module o interfață simplă encrypt/decrypt, fără a fi nevoie să înțeleagă detaliile algoritmului de criptare.

// Coeziune scăzută — clasa face totul deodată
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Coeziune înaltă — fiecare clasă rezolvă o singură sarcină
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Exemplul arată diferența: UserManager are coeziune logică — toate metodele sunt despre utilizatori, dar fiecare face o treabă fundamental diferită. După refactorizare, fiecare clasă are coeziune funcțională, iar coupling-ul scade, deoarece celelalte module depind doar de clasa de care au nevoie, nu de întrebul UserManager.

Cum se măsoară coeziunea în cod

LCOM (Lack of Cohesion of Methods) — cea mai cunoscută metrică pentru măsurarea coeziunii clasei. LCOM numără câte perechi de metode nu folosesc câmpuri comune. Valoarea 0 înseamnă coeziune ideală (toate metodele lucrează cu aceleași câmpuri), valoarea mare — coeziune scăzută. LCOM4 (versiunea îmbunătățită) ia în considerare legăturile tranzitive prin alte metode.

în Android metricile de coeziune pot fi obținute prin Detekt cu regula TooManyFunctions. Clasele cu zeci de metode care folosesc diferite grupuri de câmpuri au, cel mai probabil, coeziune scăzută. în iOS, SwiftLint are regulile file_length și function_body_length — indicatori indirecți: fișierele și metodele lungi semnalează adesea coeziune scăzută.

Metoda manuală de evaluare: puneți întrebarea „Această clasă se va schimba dintr-un motiv sau din mai multe?” Dacă puteți numi mai mult de un motiv independent — clasa are coeziune scăzută. Al doilea test: „Poate fi împărțită această clasă în două clase independente?” Dacă da — faceți aceasta. Verificarea regulată a coeziunii la code review previne apariția claselor God și reduce datoria tehnică.

Cum să crești Cohesion într-un proiect mobil

Primul pas — aplicați Single Responsibility Principle. Fiecare clasă trebuie să aibă o singură responsabilitate clară. Dacă într-o clasă există o metodă care nu aparține sarcinii sale principale, extrageți-o într-o clasă separată. Tehnica Extract Class sau Extract Delegate din IDE automatizează acest proces. După extragere, verificați dacă clasa originală a devenit mai focusată.

Al doilea pas — folosiți pattern-ul Facade pentru simplificarea interfeței. Dacă o clasă oferă 20 de metode, dintre care clienții folosesc doar 3-4, probabil clasa are coeziune scăzută — oferă prea multă funcționalitate diversă. Grupați metodele pe teme și extrageți clase separate pentru fiecare grup, iar clasa originală transformați-o într-un facade sau ștergeți-o.

Al treilea pas — acordați atenție grupurilor de câmpuri. Dacă o clasă are câmpuri care sunt folosite doar de o parte dintre metode — acesta este un indicator de coeziune scăzută. Împărțiți clasa după grupurile de câmpuri. De exemplu, dacă clasa conține câmpurile userRepository, networkClient și analyticsTracker, dar metodele primului grup folosesc doar userRepository, iar al doilea — networkClient — acestea sunt două clase diferite.

Al patrulea pas — evitați crearea claselor „utilitare” cu metode static arbitrare. Fiecare metodă statică aflată într-o clasă Utils sau Helpers — candidat pentru extragerea într-o clasă specializată. FormatUtils.dateToString este mai bine să fie mutat în DateFormatter, iar ValidationUtils.isValidEmail — în EmailValidator. Aceasta crește coeziunea fiecărei clase și face codul auto-documentabil.