Principii de arhitectură în dezvoltarea mobilă: ce sunt, tipuri și cum se aplică

Principiile SOLID

Principiile de arhitectură — sunt fundamentul codului de calitate. SOLID este un acronim introdus de Robert Martin («Unchiul Bob») care descrie cinci principii de proiectare orientată pe obiecte. Urmarea SOLID face codul mai flexibil, mai testabil și mai rezistent la schimbări. Încălcarea principiilor de arhitectură este una dintre principalele cauze ale datoriei tehnice.

Să examinăm fiecare principiu. Single Responsibility Principle (SRP) — fiecare clasă ar trebui să aibă un singur motiv de schimbare. Open/Closed Principle (OCP) — clasele sunt deschise pentru extensie, dar închise pentru modificare. Liskov Substitution Principle (LSP) — obiectele subtipurilor ar trebui să înlocuiască obiectele tipului de bază fără a întrerupe logica. Interface Segregation Principle (ISP) — multe interfețe specializate sunt mai bune decât o interfață generală. Dependency Inversion Principle (DIP) — dependența de abstracții, nu de implementări concrete.

Potrivit analizei SonarQube (2025), încălcarea principiilor SOLID apare în 68% din proiectele comerciale. Cele mai frecvente probleme sunt încălcarea SRP (35%) și ISP (22%). La IT Sectr, implementăm SOLID în faza de revizuire a arhitecturii — acest lucru ajută la identificarea problemelor înainte ca acestea să devină datorie tehnică.

Single Responsibility Principle (SRP)

SRP (Principiul Responsabilității Unice) — cel mai important și în același timp cel mai frecvent încălcat principiu SOLID. Acesta spune: o clasă ar trebui să aibă un singur motiv de schimbare. Dacă o clasă face prea multe, este dificil de testat, modificat și înțeles.

O încălcare tipică este o clasă care procesează simultan date, le salvează în baza de date și trimite notificări prin e-mail. Exemplul de mai jos arată o încălcare SRP în Kotlin și cum să o remediați.

// Încălcare SRP — clasa face trei lucruri diferite
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validarea datelor
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Salvare în baza de date
        val user = User(email, name)
        database.save(user)
        
        // 3. Trimitere notificare
        emailService.sendWelcomeEmail(email, name)
    }
}

// Remediere — împărțire în trei clase
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

În versiunea corectată, fiecare clasă este responsabilă pentru propria sarcină: UserValidator — pentru validare, UserRepository — pentru salvare, NotificationService — pentru notificări. Acest lucru face codul testabil și reutilizabil — puteți înlocui implementarea bazei de date fără a schimba logica de validare.

GRASP și Legea lui Demeter

GRASP (General Responsibility Assignment Software Patterns) — nouă principii de arhitectură pentru distribuirea responsabilității între obiecte, descrise de Craig Larman. Spre deosebire de SOLID, GRASP răspunde la întrebarea «care clasă ar trebui să conțină această metodă?». Modele cheie: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Legea lui Demeter (LoD, principiul cuplării minime) — o regulă simplă: un obiect ar trebui să comunice doar cu vecinii săi imediați. Nu ar trebui să scrieți a.getB().getC().doSomething() — aceasta creează o cuplare puternică între clase. LoD îmbunătățește reutilizabilitatea și simplifică testarea.

La IT Sectr, verificăm conformitatea cu LoD în timpul Revizuirii Codului. Dacă o metodă «trece prin» trei sau mai multe obiecte, este un semnal că arhitectura trebuie simplificată. Încălcarea LoD este unul dintre cele mai comune Code Smell-uri în proiectele mari.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) și YAGNI (You Ain't Gonna Need It) — trei principii de bază de arhitectură cunoscute de orice dezvoltator. În ciuda simplității lor, încălcările apar constant.

DRY — nu duplicați codul. Dacă aceeași logică apare în două locuri, extrageți-o într-o metodă sau clasă comună. Duplicarea este principala sursă de erori: o corecție într-un loc este uitată a fi aplicată în altul. DRY nu înseamnă că nu puteți avea cod similar — important este ca logica de afaceri să nu se repete.

KISS — cu cât mai simplu, cu atât mai bine. Soluțiile complexe cu multe abstracții și moșteniri sunt adesea excesive. Începeți cu o soluție simplă și complicați-o doar când este necesar. YAGNI — nu scrieți cod pentru funcționalități care ar putea fi necesare «cândva mai târziu». Acest lucru duce la umflarea bazei de cod și la creșterea complexității întreținerii.

DRY — Don't Repeat Yourself

DRY — nu este vorba doar de absența copierii-lipirii. Este un principiu conform căruia fiecare bucată de cunoaștere sau logică ar trebui să aibă o singură reprezentare, fără ambiguitate, în sistem. Duplicarea poate fi explicită (cod copiat) și implicită (aceeași logică în straturi diferite).

La IT Sectr, folosim metrici de analiză a codului pentru a detecta duplicarea. Instrumente precum SonarQube și Detekt arată procentul de cod duplicat. O valoare peste 5% este un motiv pentru refactorizare. Cu toate acestea, este important să rețineți: DRY nu ar trebui atins cu prețul abstracțiilor greșite — uneori este mai bine să lăsați două bucăți de cod similare așa cum sunt dacă combinarea lor ar complica înțelegerea.

Separation of Concerns și Modularitate

Separation of Concerns (SoC) — un principiu de arhitectură în care un sistem este împărțit în părți independente (concerns), fiecare rezolvând propria sarcină. Un exemplu clasic este separarea pe straturi: prezentare, logică de afaceri, acces la date. Fiecare strat depinde doar de stratul inferior.

Modularitatea — gradul în care un sistem poate fi împărțit în module. Un modul este un grup de clase legate logic cu o interfață bine definită. Modulele ar trebui să fie slab cuplate (low coupling) și puternic coezive (high cohesion).

Coeziune vs Cuplare

Coeziunea (Cohesion) — o măsură a cât de mult sunt legate între ele elementele din același modul. Coeziunea ridicată este bună: o clasă face un lucru și îl face bine. Cuplarea scăzută (Low coupling) — o măsură a cât de independente sunt modulele unul de altul. Cuplarea scăzută este bună: schimbarea unui modul nu le strică pe altele.

Arhitectura ideală este coeziune ridicată și cuplare scăzută. În practică, aceasta înseamnă: o clasă conține metode care lucrează pe aceleași date (coeziune) și depinde doar de abstracții, nu de implementări concrete (cuplare). Un dezechilibru duce la «Obiecte Zeu» sau «cod spaghetti».

Datoria tehnică și Code Smell

Datoria tehnică (Technical Debt) — o metaforă introdusă de Ward Cunningham care descrie «dobânda» pe care o echipă o plătește pentru decizii de arhitectură suboptimale și încălcarea principiilor de arhitectură. Ca și datoria financiară, datoria tehnică poate fi intenționată (am decis să facem repede, vom reface mai târziu) și neintenționată (arhitectură slabă din cauza lipsei de experiență).

Code Smell — semne superficiale ale unor probleme profunde în cod. Termenul a fost popularizat de Martin Fowler în cartea «Refactoring». Code Smell-uri tipice: metode lungi, clase mari, lanțuri lungi de apeluri, duplicare de cod, utilizarea excesivă a comentariilor (în loc de cod clar).

La IT Sectr, datoria tehnică este urmărită în Jira ca sarcini separate. În fiecare sprint, alocăm 20% din timp pentru refactorizare și rambursarea datoriei. Lucrul sistematic cu datoria tehnică este singura modalitate de a evita o situație în care adăugarea unei noi funcționalități durează mai mult decât dezvoltarea de la zero.