OCP — prinsiplər, genişlənməyə açıqlıq və dəyişdirilməyə qapalılıq

OCP (Open/Closed Principle) nədir?

OCP (Open/Closed Principle) — genişlənməyə açıqlıq və dəyişdirilməyə qapalılıq prinsipidir. Siniflər, modullar və funksiyalar elə layihələndirilməlidir ki, yeni davranış onların mənbə kodunu dəyişmədən əlavə olunsun. Genişlənmə miras, kompozisiya və ya interfeys implementasiyalarının əvəzlənməsi ilə əldə edilir.

Bertrand Meyer Object-Oriented Software Construction (1988) kitabında OCP-ni ilk dəfə miras vasitəsilə təsvir etmişdir: əsas sinif dəyişməz qalır, alt siniflər isə onun davranışını genişləndirir. Robert Martin tərəfindən təklif edilən müasir OCP şərhi polimorfizmə və interfeyslərə əsaslanır: miras əvəzinə abstrakt kontraktlardan istifadə olunur.

Yanaşmalar arasındakı fərq əhəmiyyətlidir. Miras əsas və törəmə siniflər arasında sərt əlaqə yaradır. İnterfeyslər və kompozisiya elastiklik verir: implementasiya müştəri kodunu dəyişmədən əvəzlənir. Müasir OCP — miras deyil, abstraksiya haqqındadır.

Polimorfizm OCP-nin əsası kimi

Polimorfik OCP kontraktı müəyyən etmək üçün abstrakt siniflər və ya interfeyslərdən istifadə edir. Müştəri kodu konkret implementasiyanı bilmədən abstraksiya ilə işləyir. Yeni funksionallıq eyni interfeysi implementasiya edən yeni sinif yaratmaqla əlavə edilir — mövcud koda heç bir dəyişiklik edilmədən. Bu, sistemi dəyişikliklərə qarşı davamlı və genişlənmə üçün proqnozlaşdırıla bilən edir.

Mobil inkişafda bu yanaşma hər yerdə mövcuddur: Strategy nümunəsi vahid interfeys vasitəsilə alqoritmləri (şəkil sıxma, keşləmə, autentifikasiya) əvəz etməyə imkan verir. Yeni strategiyanın əlavə edilməsi onu istifadə edən kodun dəyişdirilməsini tələb etmir.

Açıqlıq və qapalılıq prinsipini necə həyata keçirmək olar

OCP-nin həyata keçirilməsi dəyişən davranışın abstraksiyaya ayrılması ilə başlayır. Əgər kodda obyektin tipini yoxlayan switch və ya if-else zənciri varsa — bu, OCP-nin tətbiqi üçün siqnaldır. Hər bir şərt qolu genişlənmə zamanı potensial olaraq yeni qolun əlavə edilməsini tələb edir.

OCP-yə uyğun refaktoring prosesi üç addımı əhatə edir: dəyişən aspekti müəyyən etmək (genişlənə bilən hissə), onu interfeys və ya abstrakt sinfə ayırmaq, müştəri kodunu konkret sinif əvəzinə abstraksiya ilə işləmək üçün yenidən yazmaq. Bundan sonra yeni funksionallıq müştərini dəyişmədən əlavə edilir.

Vacib qeyd: dəyişdirilməyə qapalılıq mütləq deyil. Əgər tələb abstraksiyanın özünə və ya kontrakta aiddirsə — dəyişiklik qaçılmazdır. OCP implementasiyalardakı dəyişikliklərdən qoruyur, kontraktlardakı dəyişikliklərdən yox. Yaxşı dizayn kontraktların sabit, implementasiyaların isə dəyişkən olmasını nəzərdə tutur.

Arxitekturanın OCP-yə uyğunluğunu qiymətləndirərkən genişlənmə nöqtələrinə baxmaq faydalıdır. Proqramçının yeni tip üçün if-else və ya switch əlavə etdiyi hər bir nöqtə — abstraksiya üçün namizəddir. OCP-yə uyğun layihələndirilmiş sistem proqnozlaşdırıla bilən genişlənmə nöqtələrinə malikdir: “yeni tip əlavə etmək üçün bu interfeysi implementasiya et” sənədləşdirilmiş interfeyslər. Android-də belə bir nümunə ViewModelProvider.Factory ilə birlikdə Factory nümunəsidir — yeni ViewModel tipinin əlavə edilməsi mövcud fabriklərin dəyişdirilməsini tələb etmir.

OCP üçün strategiyalar və nümunələr

Ən təsirli nümunələr mobil inkişafda OCP-yə riayət etmək üçün Strategy, Template Method, Decorator və Factory daxildir. Onların hər biri obyekt-yönümlü layihələndirmənin müxtəlif mexanizmləri vasitəsilə mövcud kodu dəyişmədən davranışın genişləndirilməsi problemini həll edir.

Strategy ümumi interfeys vasitəsilə alqoritmləri yerindəcə əvəz etməyə imkan verir. iOS inkişafında strategiyalar animasiyalar və formaların validasiyası üçün istifadə olunur. Template Method əsas sinifdə alqoritmin skeletini müəyyən edir, alt siniflər addımları ləğv edir — ümumi struktura malik, lakin fərqli məzmunlu ekranlar üçün uyğundur.

Decorator sinfini dəyişmədən obyektə dinamik olaraq davranış əlavə edir. Android-də Decorator Repository-nin keş və ya loglama qatı ilə bükülməsi üçün tətbiq olunur. Factory Method interfeys vasitəsilə obyektlər yaradır, alt siniflərə hansı sinfi yaratmaq qərarını verir — OCP-yə uyğun asılılıq yaratmanın əsasıdır.

Mobil layihə üçün strategiya seçimi

Nümunənin seçimi genişləndirilən davranışın sabitliyindən asılıdır. Strategy alqoritmlər tamamilə əvəz edildikdə optimaldır. Template Method — struktur sabit, lakin addımlar dəyişkən olduqda. Decorator — genişlənmə müştəri üçün şəffaf olmalı olduqda. Android və iOS-da əksər ssenarilər üçün Strategy + asılılıq injectiyası kifayətdir.

Bu nümunələrin OCP olmadan tətbiqi texniki cəhətdən mümkündür, lakin mənasını itirir. Məhz OCP əlavə abstraksiya səviyyəsini nə üçün tətbiq etdiyimizi əsaslandırır: sistemin mövcud kodu yenidən yazmadan böyüməsi üçün.

Mobil tətbiqlərdə OCP nümunələri

Android nümunəsini ödənişlərin işlənməsi ilə nəzərdən keçirək. OCP olmadan hər yeni ödəniş sistemi işləyən sinifin dəyişdirilməsini tələb edir. OCP ilə mövcud kodu dəyişmədən interfeysin yeni implementasiyası əlavə edilir.

// OCP-nin pozulması: switch yeni sistem üçün dəyişiklik tələb edir
class BadPaymentProcessor {
    fun process(type: String) {
        when (type) {
            "card" -> // kartın işlənməsi
            "paypal" -> // PayPal işlənməsi
        }
    }
}

// OCP-uyğun dizayn
interface PaymentMethod {
    fun pay(amount: Double)
}

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

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

// Yeni sistem — mövcud kodu dəyişmədən yeni sinif
class ApplePayPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

iOS nümunəsi mətn sahələrinin validasiyası ilə eyni məntiqi Swift protokolları vasitəsilə nümayiş etdirir:

// OCP-uyğun validasiya
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
    }
}

// Yeni qaydanın əlavə edilməsi validator kodunun dəyişdirilməsini tələb etmir
struct PasswordRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count >= 8
    }
}

OCP-nin əsas üstünlüyü bu nümunələrdə: ApplePay və ya PasswordRule əlavə edilməsi mövcud siniflərin dəyişdirilməsini tələb etmir. Kod üfüqi şəkildə genişlənir — köhnə faylları dəyişmək əvəzinə yeni fayllar vasitəsilə. Bu, reqressiya riskini azaldır və yeni funksionallığın tətbiqini sürətləndirir.

OCP-nin pozulmasında tipik səhvlər

Ən geniş yayılmış pozuntu — obyektin tipinə görə switch və ya when konstruksiyası. Hər dəfə yeni tip əlavə edildikdə kodda bütün belə switch-ləri tapmaq və yeni qol əlavə etmək lazımdır. Buraxılmış switch — kompilyasiya mərhələsində aşkar edilməsi çətin olan runtime xətasıdır.

Mobil inkişafda OCP nəhəng enum siniflərindən istifadə edildikdə pozulur, bu siniflərin metodları enum dəyərindən asılıdır. Yeni enum elementi əlavə edilməsi bütün layihə boyu hər switch-in dəyişdirilməsini tələb edir. Alternativ — hər tipin öz davranışını reallaşdırdığı interfeys vasitəsilə polimorfizmdir.

Digər bir tipik pozuntu — God Adapter: RecyclerView.Adapter (Android) və ya UITableViewDataSource (iOS), if-else vasitəsilə müxtəlif hüceyrə tiplərini emal edir. Hər yeni hüceyrə tipi adapterin genişləndirilməsini tələb edir. Həll yolu — hər hüceyrə tipinin öz göstərilməsinə cavabdeh olduğu ümumi bind metodu olan polimorfik ViewHolder-dir.

OCP pozuntusundan necə qaçınmaq olar

Profilaktik tədbirlər daxildir: tipə görə switch-dən imtina edərək polimorfizmə keçid, interfeyslər vasitəsilə asılılıqların inject edilməsi və konfiqurasiyaya görə obyektlər yaratmaq üçün Factory nümunəsinin tətbiqi. Kodun “tipə görə keçidlər” üçün təhlili — OCP-yönümlü komandalarda kod review-in məcburi hissəsidir.

Mövcud OCP pozuntusunun refaktoringi Replace Conditional with Polymorphism vasitəsilə həyata keçirilir: şərtin hər bir qolu ümumi interfeysin implementasiyası ilə ayrıca sinfə çevrilir. Müştəri kodu interfeyslə işləmək üçün yenidən yazılır, konkret implementasiya isə fabrik və ya DI konteyneri vasitəsilə təmin edilir.

Başa düşmək vacibdir ki, OCP və polimorfizm bütün genişlənmə problemlərini həll etmir. Arxitektura səhv seçilibsə, yeni funksionallığın əlavə edilməsi təkcə implementasiyaların deyil, həm də kontraktların dəyişdirilməsini tələb edəcək. Yaxşı arxitektura genişlənmə istiqamətlərini proqnozlaşdırır və məhz bu nöqtələrdə abstraksiyalar yaradır. OCP-yə investisiya layihə nə qədər uzun yaşayırsa və konkret modullara olan tələblər nə qədər tez-tez dəyişirsə, bir o qədər çox bəhrəsini verir.