SRP: mi ez, az egyetlen felelősség elve a fejlesztésben

Mi az SRP (Single Responsibility Principle)?

SRP (Single Responsibility Principle) — az egyetlen felelősség elve, amely kimondja: minden osztálynak vagy modulnak pontosan egy oka lehet a változásra. Ez nem jelenti azt, hogy egy osztálynak pontosan egy műveletet kell végeznie. Arról van szó, hogy egy kapcsolódó cselekvési csoportot egyetlen felelősség egyesít egyetlen szereplővel szemben.

Robert Martin az SRP-t a szereplők szempontjából fogalmazta újra: egy osztálynak csak egy érdekelt fél vagy egy embercsoport kérésére szabad változnia. Ha két különböző szereplő ugyanazon osztály megváltoztatását kéri — a felelősség helytelenül van elosztva.

Például az Employee osztály, amely egyszerre számolja ki a fizetést (számvitel kérése) és készít jelentést (vezetőség kérése), megsérti az SRP-t. A számítási szabályok megváltozása hatással lehet a jelentéskészítésre és fordítva.

Az SRP formális meghatározása

Egy modulnak egy és csak egy oka lehet a változásra. A változás okát a szereplő határozza meg — az a személy vagy rendszer, aki a követelményt kezdeményezi. Ha különböző szereplőktől származó követelmények ugyanazon modul megváltoztatásához vezetnek — a modul megsérti az SRP-t.

A szereplő koncepciója az SRP-t gyakorlati építészeti elemző eszközzé teszi, nem elvont ajánlássá. Egy rendszer tervezésekor elég feltenni a kérdést: „Ki fogja kérni ennek a kódnak a megváltoztatását?” — ha a válasz egynél több érdekelt felet tartalmaz, a felelősséget meg kell osztani.

Hogyan működik az egyetlen felelősség elve

Az egyetlen felelősség azon metódusok csoportosításával valósul meg, amelyek egy okból változnak. Az osztály a kapcsolódó logika „gyűjtőpontjává” válik, nem pedig egy „svájci bicskává” minden alkalomra. Ez leegyszerűsíti a kód megértését: a fejlesztő látja az osztályt és azonnal megérti a rendeltetését.

Az SRP működési mechanizmusa az egyetlen változási tengely szabályán alapul. Ha a funkcionalitás független okokból változhat — külön osztályokba kell kiszervezni. Az osztályok közötti kapcsolatok kompozíció vagy delegálás útján épülnek ki.

Az SRP megsértése az „istenosztályokban” (God Objects) nyilvánul meg, amelyek több tucat, különböző adatokkal dolgozó metódust tartalmaznak. Egy ilyen osztályt nehéz tesztelni — egy metódus tesztelése a környezet beállítását igényli az összes többihez. Az egyik felelősség megváltozása tönkretehet egy másikat, ami törékennyé teszi a kódot.

A gyakorlatban az SRP segít a fejlesztőknek megválaszolni a „hol van ez a kód?” kérdést. Ha minden felelősség külön osztályba van elkülönítve, a szükséges fájl megtalálása másodperceket vesz igénybe. Egy MVVM architektúrájú Android projektben ez azt jelenti, hogy a UserViewModel csak a felhasználói képernyő állapotáért felelős, a UserRepository pedig az adatok lekéréséért. A cache logikát kereső fejlesztő a UserCacheRepository-ba megy, nem a ViewModel-be. A kód ilyen szervezése felgyorsítja az új csapattagok betanulását és csökkenti a hibák számát refaktoráláskor.

Miért fontos az SRP a mobilfejlesztésben

A mobilfejlesztés különleges követelményeket támaszt a kód modularitásával szemben. Az Android Fragment vagy iOS ViewController gyakran a logika „vonzási pontjává” válik: kattintások kezelése, API hívás, válasz feldolgozása, UI frissítése — minden egy osztályban. Az SRP megköveteli e felelősségek szétválasztását.

Az Android architektúrában az SRP be van építve a Google Jetpack ajánlásaiba: a ViewModel a képernyő állapotáért, a Repository az adatokért, a UseCase az üzleti logikáért felel. Minden komponensnek egy oka van a változásra. Az iOS fejlesztésben az MVVM minta és a Coordinator ugyanezt a logikát követi.

Az SRP betartása a mobil projektekben mérhető előnyöket nyújt: az osztályméret 40-60%-os csökkenése, a code review idő rövidülése és a regressziós hibák számának csökkenése új funkcionalitás hozzáadásakor. Az elkülönített modulok könnyebben lefedhetők unit tesztekkel és újrahasznosíthatók más képernyőkön.

Az SRP hatása a tesztelésre

Az unit tesztek az SRP-t betartó osztályokhoz kevesebb mock objektumot és konfigurációt igényelnek. Ha egy osztálynak egy felelőssége van, a függőségei korlátozottak. A teszt egy viselkedést ellenőriz, nem több nem kapcsolódó forgatókönyv kombinációját.

A Google Testing Blog (2023) jelentése szerint az egyetlen felelősséggel rendelkező osztályok 35%-kal nagyobb tesztlefedettséget mutatnak az aggregátor osztályokkal összehasonlítva. A fejlesztők szívesebben írnak teszteket kis, érthető modulokhoz.

SRP példák Android és iOS rendszeren

Vizsgáljunk meg egy tipikus Android osztályt, amely megsérti az SRP-t — betölti az adatokat, feldolgozza a választ és frissíti a UI-t. A refaktorálás után minden felelősség külön komponensbe kerül.

// SRP megsértése: egy osztály mindent csinál
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // HTTP kérés
        // JSON feldolgozás
        // UI frissítés
        // Mentés adatbázisba
    }
}

// Az SRP alkalmazása után
class UserRepository {
    fun getUser(userId: Int): User
}

class UserViewModel {
    private val repo: UserRepository
    fun loadUser(userId: Int) { }
}

class UserProfileFragment {
    fun render(user: User) { }
}

Hasonló példa iOS Swift nyelven a hálózati réteg és a megjelenítési réteg szétválasztásával:

// SRP megsértése: ViewController kezeli az adatokat és UI-t
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // URLSession kérés
        // JSON dekódolás
        // Címke frissítés
    }
}

// Az SRP alkalmazása után
protocol UserServiceProtocol {
    func fetchUser(id: Int) async throws -> User
}

class ProfileViewModel {
    private let service: UserServiceProtocol
    func loadProfile(id: Int) { }
}

class ProfileViewController: UIViewController {
    func display(user: User) { }
}

Az SRP refaktorálás nem bonyolítja az architektúrát — újraelosztja a felelősséget. A kód mennyisége akár csökkenhet is a duplikációk megszüntetésével. Minden új osztálynak világos célja van és függetlenül fejleszthető.

Kompozíció, mint az öröklődés alternatívája

A kompozíció segít betartani az SRP-t ott, ahol az öröklődés szükségtelen kapcsolódásokat hoz létre. Több tucat metódussal rendelkező szuperosztály helyett az alosztály specializált objektumok készletét kapja a konstruktoron keresztül. Minden objektum a saját funkcionalitásáért felelős.

Az Android fejlesztésben a Decorator minta lehetővé teszi felelősségek hozzáadását az eredeti osztály módosítása nélkül. Az iOS-ben a Middleware lánc a hálózati rétegben külön modulokra bontja a naplózást, gyorsítótárazást és hitelesítést.

Tipikus SRP megsértések és következményeik

A leggyakoribb megsértés — a „God Class”: egy osztály, amely kezeli az adatbázist, értesítéseket küld, jelentéseket készít és feldolgozza a felhasználói bemenetet. Egy ilyen osztály a projekt szűk keresztmetszetévé válik: minden változtatás teljes regressziós tesztelést igényel.

A mobilfejlesztésben az SRP megsértését az üzleti logika és a UI logika keverése okozza az Activity, Fragment vagy ViewController osztályokban. Amikor az onClickListener metódus egyszerre érvényesíti az adatokat, meghívja az API-t és frissíti a gombok láthatóságát — ez az egyetlen felelősség elvének közvetlen megsértése.

Az SRP megsértésének következményei közé tartozik: a párhuzamos fejlesztés nehézsége (konfliktusok egy fájlban), az unit tesztelés akadályozottsága, a változtatások magas költsége és a kód olvashatóságának csökkenése. A szisztematikus SRP megsértéssel rendelkező projektek 2-3-szor több időt igényelnek új funkcionalitás hozzáadásához.

Az SRP megsértésének indikátorai a kódban

Az SRP megsértése közvetett jelek alapján határozható meg: az osztály több mint 200 sort tartalmaz, az alkalmazás különböző rétegeiből importál modulokat (UI + network + database), több mint 5 különböző témájú publikus metódusa van. A kohézió mérőszáma — statisztikai mutató: az osztályon belüli metódusok alacsony kohéziója SRP megsértésre utal.

Az SRP megsértések felderítéséhez érdemes statikus elemző eszközöket használni: Androidhoz — Detekt a TooManyFunctions szabállyal, iOS-hez — SwiftLint a file_length szabállyal. Ezek az eszközök kiemelik a méret- és komplexitásküszöböt meghaladó osztályokat.

Az SRP-t megsértő osztályok refaktorálása Extract Class vagy Extract Delegate segítségével történik: a kapcsolódó metódusok csoportja külön osztályba kerül, az eredeti osztály pedig delegálja hozzájuk a hívásokat. Az ilyen refaktorálások fokozatos alkalmazása a „God Class”-t lazán kapcsolódó modulok halmazává alakítja, mindegyik egyetlen felelősséggel. Ez a megközelítés lehetővé teszi az architektúra javítását a fejlesztés leállítása nélkül — a refaktorálás iteratív módon, egyszerre egy modullal történik.