OCP — alapelvek, nyitottság a bővítésre és zártság a módosításra

Mi az OCP (Open/Closed Principle)?

OCP (Open/Closed Principle) — a nyitottság elve a bővítésre és zártság a módosításra. Az osztályokat, modulokat és függvényeket úgy kell megtervezni, hogy új viselkedést lehessen hozzáadni a forráskód módosítása nélkül. A bővítés öröklődés, kompozíció vagy interfész-implementációk helyettesítése révén érhető el.

Bertrand Meyer az Object-Oriented Software Construction (1988) című könyvében írta le először az OCP-t öröklődésen keresztül: az alaposztály változatlan marad, és az alosztályok bővítik a viselkedését. Az OCP modern értelmezése, amelyet Robert C. Martin javasolt, a polimorfizmuson és interfészeken alapul: az öröklődés helyett absztrakt szerződéseket használ.

A megközelítések közötti különbség jelentős. Az öröklődés merev kapcsolatot hoz létre az alap- és származtatott osztály között. Az interfészek és a kompozíció rugalmasságot biztosítanak: az implementáció lecserélhető a klienskód módosítása nélkül. Modern OCP — az absztrakcióról szól, nem az öröklődésről.

A polimorfizmus mint az OCP alapja

Polimorfikus OCP absztrakt osztályokat vagy interfészeket használ a szerződés meghatározásához. A klienskód az absztrakcióval dolgozik, anélkül hogy ismerné a konkrét implementációt. Új funkcionalitás egy új osztály létrehozásával kerül hozzáadásra, amely ugyanazt az interfészt implementálja — a meglévő kódban semmilyen változtatás nélkül. Ez a rendszert ellenállóvá teszi a változásokkal szemben és kiszámíthatóvá a bővítés szempontjából.

A mobilfejlesztésben ez a megközelítés mindenütt jelen van: a Strategy minta lehetővé teszi az algoritmusok (képtömörítés, gyorsítótárazás, hitelesítés) lecserélését egy közös interfészen keresztül. Egy új stratégia hozzáadása nem igényli az azt használó kód módosítását.

Hogyan valósítsuk meg a nyitottság és zártság elvét

Az OCP megvalósítása a változó viselkedés absztrakcióba történő elkülönítésével kezdődik. Ha a kódban van egy switch szerkezet vagy if-else lánc, amely az objektum típusát ellenőrzi — ez egy jel az OCP alkalmazására. Minden feltételág potenciálisan egy új ág hozzáadását igényli a bővítés során.

Az OCP szerinti refaktorálási folyamat három lépést foglal magában: azonosítsa a változó aspektust (ami bővíthető), különítse el egy interfészbe vagy absztrakt osztályba, írja át a klienskódot, hogy az absztrakcióval dolgozzon a konkrét osztály helyett. Ezt követően az új funkcionalitás a kliens módosítása nélkül kerül hozzáadásra.

Fontos megjegyzés: a módosításra való zártság nem abszolút. Ha a változtatási követelmény magát az absztrakciót vagy a szerződést érinti — a változtatás elkerülhetetlen. Az OCP az implementációkban bekövetkező változtatások ellen véd, nem a szerződésekben. A jó design feltételezi, hogy a szerződések stabilak, az implementációk pedig változóak.

Az architektúra OCP-vel való kompatibilitásának értékelésekor érdemes a bővítési pontokra tekinteni. Minden pont, ahol a fejlesztő if-else vagy switch kifejezést ad hozzá egy új típushoz – az absztrakció jelöltje. Az OCP szerint tervezett rendszer kiszámítható bővítési pontokkal rendelkezik: interfészek a „implementáld ezt az interfészt egy új típus hozzáadásához” dokumentációval. Androidban ilyen példa a Factory minta a ViewModelProvider.Factory-val kombinálva — egy új ViewModel típus hozzáadása nem igényli a meglévő gyárak módosítását.

Stratégiák és minták az OCP-hez

Leghatékonyabb minták az OCP betartásához a mobilfejlesztésben a Strategy, Template Method, Decorator és Factory. Mindegyik a viselkedés bővítésének problémáját oldja meg a meglévő kód módosítása nélkül, az objektumorientált tervezés különböző mechanizmusain keresztül.

Strategy lehetővé teszi az algoritmusok menet közbeni lecserélését egy közös interfészen keresztül. Az iOS-fejlesztésben a stratégiákat animációkhoz és űrlapérvényesítéshez használják. Template Method meghatározza az algoritmus vázát az alaposztályban, és az alosztályok felülírják a lépéseket — alkalmas közös szerkezetű, de eltérő tartalmú képernyőkhöz.

Decorator dinamikusan ad viselkedést egy objektumhoz anélkül, hogy megváltoztatná az osztályát. Androidban a Decorator-t a Repository gyorsítótárazási vagy naplózási réteggel való becsomagolására alkalmazzák. Factory Method interfészen keresztül hoz létre objektumokat, lehetővé téve az alosztályok számára, hogy eldöntsék, melyik osztályt példányosítsák — az OCP-kompatibilis függőségteremtés alapja.

Stratégia választása mobil projekthez

A minta kiválasztása a bővítendő viselkedés stabilitásától függ. A Strategy akkor optimális, amikor az algoritmusok teljesen lecserélődnek. Template Method — amikor a szerkezet rögzített, de a lépések változóak. Decorator — amikor a bővítésnek átláthatónak kell lennie a kliens számára. A legtöbb Android és iOS forgatókönyvhöz elegendő a Strategy + függőséginjektálás.

E minták OCP nélküli alkalmazása technikailag lehetséges, de értelmét veszti. Pontosan az OCP indokolja, miért vezetünk be egy további absztrakciós szintet: hogy a rendszer növekedhessen a meglévő kód újraírása nélkül.

OCP példák mobilalkalmazásokban

Tekintsük át az Android-példát a fizetésfeldolgozással. OCP nélkül minden új fizetési rendszer megköveteli a feldolgozó osztály módosítását. OCP-vel egy új interfész-implementáció kerül hozzáadásra a meglévő kód szerkesztése nélkül.

// OCP megsértése: a switch módosítást igényel egy új rendszerhez
class BadPaymentProcessor {
    fun process(type: String) {
        when (type) {
            "card" -> // kártyafeldolgozás
            "paypal" -> // PayPal-feldolgozás
        }
    }
}

// OCP-kompatibilis design
interface PaymentMethod {
    fun pay(amount: Double)
}

class CardPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

class PayPalPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

// Új rendszer — új osztály, a meglévő kód módosítása nélkül
class ApplePayPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

Az iOS-példa a szövegmezők érvényesítésével ugyanazt a logikát mutatja be a Swift protokollokon keresztül:

// OCP-kompatibilis érvényesítés
protocol ValidationRule {
    func validate(_ input: String) -> Bool
}

struct EmailRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.contains("@")
    }
}

struct PhoneRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count == 11
    }
}

// Új szabály hozzáadása nem igényli az érvényesítő kód módosítását
struct PasswordRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count >= 8
    }
}

Az OCP fő előnye ezekben a példákban: az ApplePay vagy PasswordRule hozzáadása nem igényli a meglévő osztályok módosítását. A kód horizontálisan bővül — új fájlokon keresztül, nem a régi fájlok módosításával. Ez csökkenti a regresszió kockázatát és felgyorsítja az új funkcionalitás bevezetését.

Gyakori hibák az OCP megsértésekor

A leggyakoribb megsértés — a switch vagy when szerkezet az objektum típusa alapján. Minden alkalommal, amikor egy új típus kerül hozzáadásra, meg kell találni az összes ilyen switch-t a kódban, és hozzá kell adni egy új ágat. Egy kihagyott switch — egy futásidejű hiba, amelyet nehéz észlelni a fordítási fázisban.

A mobilfejlesztésben az OCP-t hatalmas enum osztályok használatával sértik meg, amelyek metódusai az enum értékétől függnek. Egy új enum elem hozzáadása megköveteli az összes switch módosítását a teljes projektben. Alternatíva — polimorfizmus egy interfészen keresztül, ahol minden típus megvalósítja a saját viselkedését.

Egy másik tipikus megsértés — a God Adapter: RecyclerView.Adapter (Android) vagy UITableViewDataSource (iOS), amely if-else segítségével dolgozza fel a különböző cellatípusokat. Minden új cellatípus az adapter bővítését igényli. Megoldás — egy polimorfikus ViewHolder közös bind metódussal, ahol minden cellatípus felelős a saját megjelenítéséért.

Hogyan kerüljük el az OCP megsértését

Megelőző intézkedések magukban foglalják: a típus alapú switch elhagyását a polimorfizmus javára, a függőségek interfészeken keresztüli injektálását és a Factory minta alkalmazását az objektumok konfiguráció alapján történő létrehozásához. A kód elemzése „típuskapcsolókra” — kötelező része a kód-ellenőrzésnek az OCP-orientált csapatokban.

Meglévő OCP megsértés refaktorálása a Replace Conditional with Polymorphism segítségével történik: a feltétel minden ága egy külön osztály lesz egy közös interfész implementációjával. A klienskód átírásra kerül, hogy az interfésszel dolgozzon, és a konkrét implementáció egy gyáron vagy DI konténereken keresztül kerül biztosításra.

Fontos megérteni, hogy az OCP és a polimorfizmus nem old meg minden bővítési problémát. Ha az architektúra rosszul lett megválasztva, az új funkcionalitás hozzáadása nem csak az implementációk, hanem a szerződések módosítását is igényelni fogja. A jó architektúra előrejelzi a bővítés irányait, és pontosan ezeken a pontokon helyez el absztrakciókat. Az OCP-be való befektetés annál jobban megtérül, minél tovább él a projekt, és minél gyakrabban változnak az egyes modulokra vonatkozó követelmények.