Object-oriented programming — dastur tuzilishini holat va xatti-harakatga ega obyektlar hamda ular orasidagi hamkorlik orqali ifodalovchi paradigma. OOP classga asoslangan yoki prototipga asoslangan bo‘lishi mumkin. Encapsulation, polymorphism va composition uning markaziy g‘oyalari; inheritance keng tarqalgan vosita bo‘lsa-da, har obyekt modeli uchun majburiy emas.
Obyekt modeli
Obyekt identity, state va behaviorga ega. Class-based tilda class instance’larning field va methodlarini belgilaydi. Prototype-based tilda obyekt boshqa obyektni delegation manbai sifatida ishlatadi. Message passing nuqtai nazarida caller ichki representationni emas, obyektga yuboriladigan operatsiyani biladi.
Domain entity barqaror identity bilan, value object esa qiymatlari bilan teng hisoblanadi. Order, account va session entity bo‘lishi mumkin; money yoki coordinate immutable value objectga mos. Model biznes lug‘atiga yaqin bo‘lsa kod va talab orasidagi tafovut kamayadi.
Encapsulation
Encapsulation holatni tasodifiy o‘zgartirishdan yashirib, invariantni methodlar orqali saqlaydi. withdraw balance fieldini setter bilan almashtirishdan ko‘ra limit, currency va audit qoidasini bir joyda bajaradi. Private modifier vosita, maqsad esa dependency va responsibilityni boshqarishdir.
Data transfer object ataylab fieldlar to‘plami bo‘lishi mumkin. Uni domain object bilan aralashtirish serialization formatini ichki modelga bog‘laydi. Explicit mapping API evolyutsiyasi va sensitive fieldlarni nazorat qiladi.
Polymorphism
Polymorphism bir contract ortida turli implementatsiyani ishlatadi. Dynamic dispatch runtime type bo‘yicha overridden methodni tanlaydi. Interface-based polymorphism payment provider yoki storage strategy’ni almashtiradi. Parametric polymorphism generic type orqali bir algoritmni ko‘p type’da xavfsiz ishlatadi.
Duck typing formal inheritancedan ko‘ra kerakli xatti-harakat mavjudligiga tayanadi. Har modelning trade-off’i bor: compile-time contract xatoni erta topadi, dynamic model moslashuvchanlik beradi. Contract test implementatsiyalar umumiy semantikani saqlashini tekshiradi.
Inheritance va composition
Inheritance haqiqiy “is-a” aloqasi va substitutability bo‘lganda qo‘llanadi. Chuqur hierarchy fragile base class va yashirin coupling yaratadi. Subclass parent preconditionini kuchaytirmaydi va postconditionini zaiflashtirmaydi.
Composition collaboratorlarni field sifatida birlashtiradi. Strategy runtime’da almashtiriladi, decorator behavior qo‘shadi. “Composition over inheritance” universal taqiq emas; u faqat kod reuse uchun noto‘g‘ri subtype yaratmaslikni eslatadi.
Arxitektura va test
Har database jadvaliga class yaratish OOP dizaynini avtomatik bermaydi. Responsibility va boundary use case’dan keladi. Juda ko‘p mayda class navigatsiyani qiyinlashtirishi, katta service esa barcha qoidani markazlashtirishi mumkin. Cohesion va change pattern muvozanatni ko‘rsatadi.
Dependency injection test double berishni osonlashtiradi, lekin constructor orqali o‘nlab dependency class responsibility’si kengligini ko‘rsatadi. Unit test invariantni, integration test object mapping va tashqi contractni tekshiradi. Performance-sensitive qismda allocation va dynamic dispatch profiler bilan baholanadi.
Model chegaralari
Har bir otni sinfga aylantirish yaxshi obyekt modeli bermaydi. Sinf aniq invariant va xatti-harakatga ega bo‘lsa foydali; faqat ma’lumot tashuvchi tuzilma uchun oddiy record yetarli bo‘lishi mumkin. Meros chuqurlashgan sari ajdoddagi o‘zgarish ko‘plab avlodlarga ta’sir qiladi, shuning uchun kompozitsiya ko‘pincha moslashuvchanroq tanlovdir. Obyektlar orasidagi bog‘liqlik interfeys orqali ifodalansa, testda o‘rinbosar komponent berish osonlashadi. Shu bilan birga, haddan tashqari mayda interfeys va qatlamlar kodni tushunishni og‘irlashtiradi. Domen modeli saqlash jadvalining to‘g‘ridan-to‘g‘ri nusxasi emas; u biznes qoidalarini bir joyda saqlab, noto‘g‘ri holat yaratilishiga yo‘l qo‘ymasligi kerak.
Bog‘liq tushunchalar
Object, Class, Encapsulation, Polymorphism, Inheritance, Composition, Dynamic dispatch