Architektúraelvek a mobilfejlesztésben: mik ezek, milyen típusok vannak és hogyan alkalmazzuk

SOLID elvek

Az architektúraelvek — a minőségi kód alapkövei. A SOLID egy Robert Martin («Bob bácsi») által bevezetett mozaikszó, amely az objektumorientált tervezés öt elvét írja le. A SOLID követése rugalmasabbá, tesztelhetőbbé és változásokkal szemben ellenállóbbá teszi a kódot. Az architektúraelvek megsértése a technikai adósság egyik fő oka.

Vizsgáljuk meg az egyes elveket. Single Responsibility Principle (SRP) — minden osztálynak csak egy oka lehet a változásra. Open/Closed Principle (OCP) — az osztályok nyitottak a bővítésre, de zártak a módosításra. Liskov Substitution Principle (LSP) — az altípusok objektumainak képesnek kell lenniük helyettesíteni az alaptípus objektumait a logika megtörése nélkül. Interface Segregation Principle (ISP) — sok speciális interfész jobb, mint egy általános. Dependency Inversion Principle (DIP) — absztrakcióktól függjön, ne konkrét implementációktól.

A SonarQube elemzés (2025) szerint a SOLID elvek megsértése a kereskedelmi projektek 68%-ában fordul elő. A leggyakoribb problémák az SRP megsértése (35%) és az ISP megsértése (22%). A IT Sectr-nél az architektúra felülvizsgálati szakaszában vezetjük be a SOLID-ot — ez segít azonosítani a problémákat, mielőtt azok technikai adóssággá nőnének.

Single Responsibility Principle (SRP)

SRP (Egyszerű Felelősség Elve) — a legfontosabb és egyben a leggyakrabban megsértett SOLID elv. Kimondja: egy osztálynak csak egy oka lehet a változásra. Ha egy osztály túl sokat csinál, nehéz tesztelni, módosítani és megérteni.

Egy tipikus megsértés egy olyan osztály, amely egyszerre dolgoz fel adatokat, menti el az adatbázisba és küld e-mail értesítéseket. Az alábbi példa egy SRP megsértést mutat Kotlinban és annak javítását.

// SRP megsértése — az osztály három különböző dolgot csinál
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Adatok érvényesítése
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Mentés adatbázisba
        val user = User(email, name)
        database.save(user)
        
        // 3. Értesítés küldése
        emailService.sendWelcomeEmail(email, name)
    }
}

// Javítás — három osztályra bontás
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

A javított verzióban minden osztály a saját feladatáért felelős: UserValidator — az érvényesítésért, UserRepository — a mentésért, NotificationService — az értesítésekért. Ez tesztelhetővé és újrafelhasználhatóvá teszi a kódot — az adatbázis implementációt kicserélheti az érvényesítési logika megváltoztatása nélkül.

GRASP és Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — Craig Larman által leírt kilenc architektúraelv a felelősség objektumok közötti elosztására. A SOLID-tal ellentétben a GRASP arra a kérdésre válaszol, hogy «melyik osztálynak kell tartalmaznia ezt a metódust?». Kulcsfontosságú minták: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, minimális kapcsolódás elve) — egy egyszerű szabály: egy objektum csak a közvetlen szomszédaival kommunikálhat. Nem szabad a.getB().getC().doSomething() -t írni — ez erős kapcsolódást hoz létre az osztályok között. A LoD javítja az újrafelhasználhatóságot és egyszerűsíti a tesztelést.

Az IT Sectr-nél a Kód Felülvizsgálat során ellenőrizzük a LoD betartását. Ha egy metódus három vagy több objektumon «megy keresztül», az jelzés, hogy az architektúrát egyszerűsíteni kell. A LoD megsértése az egyik leggyakoribb Code Smell a nagy projektekben.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) és YAGNI (You Ain't Gonna Need It) — három alapvető architektúraelv, amelyet minden fejlesztő ismer. Egyszerűségük ellenére a megsértések folyamatosan előfordulnak.

DRY — ne ismételje a kódot. Ha ugyanaz a logika két helyen jelenik meg, emelje ki egy közös metódusba vagy osztályba. Az ismétlés a hibák fő forrása: az egyik helyen végzett javítást elfelejtik a másik helyen alkalmazni. A DRY nem jelenti azt, hogy nem lehet hasonló kódja — a fontos az, hogy az üzleti logika ne ismétlődjön.

KISS — minél egyszerűbb, annál jobb. A sok absztrakcióval és öröklődéssel rendelkező összetett megoldások gyakran túlzóak. Kezdje egy egyszerű megoldással, és csak szükség esetén tegye összetettebbé. YAGNI — ne írjon kódot olyan funkciókhoz, amelyekre «egyszer majd» szükség lehet. Ez a kódbázis felduzzadásához és a karbantartás bonyolultságának növekedéséhez vezet.

DRY — Don't Repeat Yourself

DRY — nem csupán a másolás-beillesztés hiányáról szól. Ez egy olyan elv, amely szerint a tudás vagy logika minden darabjának egyetlen, egyértelmű reprezentációval kell rendelkeznie a rendszerben. Az ismétlés lehet explicit (másolt kód) és implicit (ugyanaz a logika különböző rétegekben).

Az IT Sectr-nél kódelemzési mérőszámokat használunk az ismétlés felderítésére. Az olyan eszközök, mint a SonarQube és a Detekt, megmutatják az ismételt kód százalékát. Az 5% feletti érték refaktorálásra ad okot. Fontos azonban emlékezni: a DRY-t nem szabad rossz absztrakciók árán elérni — néha jobb két hasonló kódrészletet úgy hagyni, ahogy vannak, ha az egyesítésük megnehezítené a megértést.

Separation of Concerns és Modularitás

Separation of Concerns (SoC) — egy architektúraelv, ahol a rendszer független részekre (concerns) van osztva, amelyek mindegyike a saját feladatát oldja meg. Klasszikus példa a rétegekre bontás: prezentáció, üzleti logika, adatelérés. Minden réteg csak az alatta lévő rétegtől függ.

Modularitás — az a mérték, amennyire egy rendszer modulokra bontható. Egy modul egy logikailag összefüggő osztálycsoport egy jól meghatározott interfésszel. A moduloknak lazán kapcsolódóknak (low coupling) és erősen kohézíveknek (high cohesion) kell lenniük.

Kohézió vs Kapcsolódás

Kohézió (Cohesion) — annak mértéke, hogy egy modulon belül az elemek mennyire kapcsolódnak egymáshoz. A magas kohézió jó: egy osztály egy dolgot csinál, és azt jól csinálja. Alacsony kapcsolódás (Low coupling) — annak mértéke, hogy a modulok mennyire függetlenek egymástól. Az alacsony kapcsolódás jó: egy modul megváltoztatása nem töri meg a többit.

Az ideális architektúra magas kohézió és alacsony kapcsolódás. A gyakorlatban ez azt jelenti: egy osztály olyan metódusokat tartalmaz, amelyek ugyanazon az adatokon dolgoznak (kohézió), és csak absztrakcióktól függ, nem konkrét implementációktól (kapcsolódás). Az egyensúly felborulása «Isten Objektumokhoz» vagy «spagetti kódhoz» vezet.

Technikai adósság és Code Smell

Technikai adósság (Technical Debt) — egy Ward Cunningham által bevezetett metafora, amely leírja azt a «kamatot», amelyet egy csapat fizet a nem optimális architektúra döntésekért és az architektúraelvek megsértéséért. A pénzügyi adóssághoz hasonlóan a technikai adósság is lehet szándékos (úgy döntöttünk, hogy gyorsan csináljuk, később átdolgozzuk) és nem szándékos (rossz architektúra tapasztalat hiánya miatt).

Code Smell — felszínes jelei a mély problémáknak a kódban. A kifejezést Martin Fowler tette népszerűvé a «Refactoring» című könyvében. Tipikus Code Smell-ek: hosszú metódusok, nagy osztályok, hosszú hívási láncok, kódismétlés, megjegyzések túlzott használata (egyértelmű kód helyett).

Az IT Sectr-nél a technikai adósságot Jira-ban követjük különálló feladatként. Minden sprintben a fejlesztési idő 20%-át fordítjuk refaktorálásra és adósság törlesztésére. A technikai adóssággal való szisztematikus munka az egyetlen módja annak, hogy elkerüljük azt a helyzetet, amikor egy új funkció hozzáadása tovább tart, mint a nulláról történő fejlesztése.