OCP — prinsiplar, kengayishga ochiqlik va o'zgartirishga yopiqligi

OCP (Open/Closed Principle) nima?

OCP (Open/Closed Principle) — kengayishga ochiqlik va o'zgartirishga yopiqligi prinsipi. Sinflar, modullar va funksiyalar shunday loyihalanishi kerakki, yangi xatti-harakat ularning manba kodini o'zgartirmasdan qo'shilsin. Kengayish meros olish, kompozitsiya yoki interfeys implementatsiyalarini almashtirish orqali erishiladi.

Bertran Meyer Object-Oriented Software Construction (1988) kitobida OCP ni birinchi marta meros olish orqali tasvirlagan: asosiy sinf o'zgarishsiz qoladi, pastki sinflar esa uning xatti-harakatini kengaytiradi. Robert Martin tomonidan taklif qilingan zamonaviy OCP talqini polimorfizm va interfeyslarga tayanadi: meros olish o'rniga abstrakt kontraktlardan foydalaniladi.

Yondashuvlar orasidagi farq muhimdir. Meros olish asosiy va hosila sinflar o'rtasida qattiq bog'lanish yaratadi. Interfeyslar va kompozitsiya moslashuvchanlik beradi: implementatsiya mijoz kodini o'zgartirmasdan almashtiriladi. Zamonaviy OCP — meros olish haqida emas, abstraksiya haqida.

Polimorfizm OCP ning asosi sifatida

Polimorfik OCP kontraktni aniqlash uchun abstrakt sinflar yoki interfeyslardan foydalanadi. Mijoz kodi aniq implementatsiyani bilmagan holda abstraksiya bilan ishlaydi. Yangi funksionallik bir xil interfeysni implementatsiya qiladigan yangi sinf yaratish orqali qo'shiladi — mavjud kodga hech qanday o'zgartirish kiritilmaydi. Bu tizimni o'zgarishlarga chidamli va kengayish uchun bashorat qilinadigan qiladi.

Mobil ishlanmada bu yondashuv hamma joyda mavjud: Strategy naqshi umumiy interfeys orqali algoritmlarni (tasvir siqish, keshlash, autentifikatsiya) almashtirish imkonini beradi. Yangi strategiya qo'shilishi undan foydalanadigan kodni o'zgartirishni talab qilmaydi.

Ochiqlik va yopiq prinsipini qanday amalga oshirish

OCP ni amalga oshirish o'zgaruvchan xatti-harakatni abstraksiyaga ajratish bilan boshlanadi. Agar kodda ob'ekt turini tekshiradigan switch yoki if-else zanjiri mavjud bo'lsa — bu OCP ni qo'llash uchun signaldir. Har bir shart tarmog'i kengayish vaqtida potensial ravishda yangi tarmoq qo'shilishini talab qiladi.

OCP ga muvofiq refaktoring jarayoni uch bosqichni o'z ichiga oladi: o'zgaruvchan jihatni aniqlash (kengaytirilishi mumkin bo'lgan narsa), uni interfeys yoki abstrakt sinfga ajratish, mijoz kodini aniq sinf o'rniga abstraksiya bilan ishlash uchun qayta yozish. Shundan so'ng yangi funksionallik mijozni o'zgartirmasdan qo'shiladi.

Muhim eslatma: o'zgartirishga yopiqligi mutlaq emas. Agar o'zgartirish talabi abstraksiyaning o'ziga yoki kontraktga tegishli bo'lsa — o'zgarish muqarrar. OCP implementatsiyalardagi o'zgarishlardan himoya qiladi, kontraktlardagi o'zgarishlardan emas. Yaxshi dizayn kontraktlarning barqaror, implementatsiyalarning esa o'zgaruvchan bo'lishini nazarda tutadi.

Arxitekturning OCP ga muvofiqligini baholashda kengayish nuqtalariga qarash foydalidir. Dasturchi yangi tur uchun if-else yoki switch qo'shadigan har bir nuqta — abstraksiya uchun nomzoddir. OCP ga muvofiq loyihalashtirilgan tizim bashorat qilinadigan kengayish nuqtalariga ega: “yangi tur qo'shish uchun ushbu interfeysni implementatsiya qil” hujjatlashtirilgan interfeyslar. Android da bunday misol ViewModelProvider.Factory bilan birga Factory naqshidir — yangi ViewModel turini qo'shish mavjud fabrikalarni o'zgartirishni talab qilmaydi.

OCP uchun strategiyalar va naqshlar

Eng samarali naqshlar mobil ishlanmada OCP ga rioya qilish uchun Strategy, Template Method, Decorator va Factory ni o'z ichiga oladi. Ularning har biri ob'ektga yo'naltirilgan loyihalashning turli mexanizmlari orqali mavjud kodni o'zgartirmasdan xatti-harakatni kengaytirish muammosini hal qiladi.

Strategy umumiy interfeys orqali algoritmlarni joyida almashtirish imkonini beradi. iOS ishlanmasida strategiyalar animatsiyalar va formalarni validatsiya qilish uchun ishlatiladi. Template Method asosiy sinfda algoritm skeletini belgilaydi, pastki sinflar esa qadamlarni bekor qiladi — umumiy tuzilishga ega, ammo turli mazmundagi ekranlar uchun mos keladi.

Decorator sinfini o'zgartirmasdan ob'ektga dinamik ravishda xatti-harakat qo'shadi. Android da Decorator Repository ni keshlash yoki loglash qatlami bilan o'rash uchun qo'llaniladi. Factory Method interfeys orqali ob'ektlar yaratadi, pastki sinflarga qaysi sinfni yaratishni hal qilish imkonini beradi — OCP ga mos bog'liqlik yaratishning asosi.

Mobil loyiha uchun strategiya tanlash

Naqsh tanlash kengaytirilayotgan xatti-harakatning barqarorligiga bog'liq. Strategy algoritmlar to'liq almashtirilganda optimaldir. Template Method — tuzilma barqaror, ammo qadamlar o'zgaruvchan bo'lganda. Decorator — kengayish mijoz uchun shaffof bo'lishi kerak bo'lganda. Android va iOS da ko'pchilik stsenariylar uchun Strategy + bog'liqlik inyeksiyasi yetarli.

Bu naqshlarni OCP siz qo'llash texnik jihatdan mumkin, ammo ma'nosini yo'qotadi. Aynan OCP nega qo'shimcha abstraksiya darajasini joriy qilishimizni asoslaydi: tizim mavjud kodni qayta yozmasdan o'sishi uchun.

Mobil ilovalarda OCP misollari

Android misolini to'lovlarni qayta ishlash bilan ko'rib chiqaylik. OCP siz har bir yangi to'lov tizimi ishlov beruvchi sinfni o'zgartirishni talab qiladi. OCP bilan mavjud kodni tahrirlamasdan interfeysning yangi implementatsiyasi qo'shiladi.

// OCP buzilishi: switch yangi tizim uchun o'zgartirish talab qiladi
class BadPaymentProcessor {
    fun process(type: String) {
        when (type) {
            "card" -> // kartani qayta ishlash
            "paypal" -> // PayPal ni qayta ishlash
        }
    }
}

// OCP-ga mos dizayn
interface PaymentMethod {
    fun pay(amount: Double)
}

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

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

// Yangi tizim — mavjud kodni o'zgartirmasdan yangi sinf
class ApplePayPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

iOS misoli matn maydonlarini validatsiya qilish bilan bir xil mantiqni Swift protokollari orqali ko'rsatadi:

// OCP-ga mos validatsiya
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
    }
}

// Yangi qoida qo'shilishi validator kodini o'zgartirishni talab qilmaydi
struct PasswordRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count >= 8
    }
}

OCP ning asosiy afzalligi bu misollarda: ApplePay yoki PasswordRule qo'shilishi mavjud sinflarni o'zgartirishni talab qilmaydi. Kod gorizontal ravishda kengayadi — eski fayllarni o'zgartirish o'rniga yangi fayllar orqali. Bu regressiya xavfini kamaytiradi va yangi funksionallikni joriy qilishni tezlashtiradi.

OCP ni buzishda odatiy xatolar

Eng keng tarqalgan buzilish — ob'ekt turiga qarab switch yoki when konstruksiyasi. Har safar yangi tur qo'shilganda koddagi barcha bunday switch larni topish va yangi tarmoq qo'shish kerak. O'tkazib yuborilgan switch — kompilyatsiya bosqichida aniqlash qiyin bo'lgan runtime xatosi.

Mobil ishlanmada OCP ulkan enum sinflaridan foydalanilganda buziladi, bu sinflarning metodlari enum qiymatiga bog'liq. Yangi enum elementi qo'shilishi butun loyiha bo'ylab har bir switch ni o'zgartirishni talab qiladi. Muqobil — har bir tur o'z xatti-harakatini amalga oshiradigan interfeys orqali polimorfizm.

Yana bir odatiy buzilish — God Adapter: RecyclerView.Adapter (Android) yoki UITableViewDataSource (iOS), if-else orqali turli hujayra turlarini qayta ishlaydi. Har bir yangi hujayra turi adapterning kengaytirilishini talab qiladi. Yechim — har bir hujayra turi o'z ko'rsatilishi uchun javobgar bo'lgan umumiy bind metodi bilan polimorfik ViewHolder.

OCP buzilishidan qanday qochish mumkin

Profilaktik choralar o'z ichiga oladi: turga qarab switch dan voz kechish va polimorfizmga o'tish, interfeyslar orqali bog'liqliklarni inyeksiya qilish va konfiguratsiyaga ko'ra ob'ektlar yaratish uchun Factory naqshini qo'llash. Kodni “turga qarab kalitlar” uchun tahlil qilish — OCP ga yo'naltirilgan jamoalarda kod review ning majburiy qismidir.

Mavjud OCP buzilishini refaktoring qilish Replace Conditional with Polymorphism orqali amalga oshiriladi: shartning har bir tarmog'i umumiy interfeysni implementatsiya qiladigan alohida sinfga aylanadi. Mijoz kodi interfeys bilan ishlash uchun qayta yoziladi, aniq implementatsiya esa fabrika yoki DI konteyneri orqali ta'minlanadi.

OCP va polimorfizm barcha kengayish muammolarini hal qilmasligini tushunish muhimdir. Arxitektura noto'g'ri tanlangan bo'lsa, yangi funksionallik qo'shilishi nafaqat implementatsiyalarning, balki kontraktlarning ham o'zgartirilishini talab qiladi. Yaxshi arxitektura kengayish yo'nalishlarini bashorat qiladi va aynan shu nuqtalarda abstraksiyalar yaratadi. OCP ga investitsiya loyiha qancha uzoq yashasa va muayyan modullarga talablar qanchalik tez-tez o'zgarsa, shuncha ko'p o'zini oqlaydi.