Agar umringizda OO code yozib ko'rgan bo'lsangiz demak siz albatta ushbu paradigm haqida eshitgansiz. Balkim tushunchalar unchalik ham zo'r bo'lmagandir ammo keling bugun shu haqida gaplashamiz (kamchiliklarini esa kelasi epizodda yozaman).
Single Responsibilaty
Har bir class faqat bitta ma'suliyatli ishni bajarishi kerak!
Open degan class yaratdingiz, unga nimani ochishni qizig'i yo'q DB connection och desangiz uni ham qilaveradi, fileni w modeda och desangiz uni ham qilaveradi umumman farqi yo'q. Ammo bu noto'g'ri yechim chunki bitta classni vazifalari qancha ko'paysa shuncha ko'p buggy bo'lish ehtimoli ham ko'payadi. Uning o'rniga esa OpenDBConnection, OpenFile va OpenFolder degan classlar yaratish tavsiya qilinadi.
Open Closed
Classlar kengayish uchun ochiq, ammo modifikatsiya (o'zgarish) uchun yopiq bo'lishlari kerak
Misol uchun OpenFolder classini olaylik. Shu classga faylni ham open qilish imkoniyatini berish mumkin ammo, classdagi imkoniyatlarni o'chirmagan yoki o'zgartirmagan xolda. Misol uchun. O'sha folder ichidagi fayllarni ochish uchun alohida method open_file(filename: str, mode: str) yozib chiqishingiz va simplicity maqsadida OpenFile classidan foydalanishingiz mumkin. Bu orqali esa qo'shimcha logika yozmaysiz shunchaki tepada aytilganidek yagona maqsadli klasslardan birini ishlatgan bo'lasiz :)
Liskov Substitution
Agar B class A classidan inheritance olgan bo'lsa, B class objecti A class objectini o'rnini bosa olishi kerak hech qanday o'zgarishlarsiz.
Ho'p nimalar bo'layabdi deyishga shoshilmang, qisqacha aytganda Kofechini o'g'li ham kofe tayyorlashni bilishi kerak. Agar "hey dadang ishga kelmabdi menga kofe qilib ber" deyishsa "mana suv iching kofe qilishni bilmayman" demasdan kofe qilib berishi kerak o'sha o'g'il degan ma'noni bildiradi. Ya'ni child class objecti, parent class objecti qila olgan ishlarni qila olishi kerak demoqchi. Menimcha bunga qandaydir chuqur misol keltirish shart emas deb o'ylayman, shu yetar )
Interface Segregation
Mijozlarga kerakmas bo'lgan narsalarni, ular ishlatishiga majburlamaslik kerak
Misol uchun OpenFile classiga databasega ulanish kerak emas. Va uni bunga majbur qilishga doir ishlarni uni ichida bajarish shunchaki useless. Ya'ni class faqat o'z vazifasiga tegishli ishlarni bajarishi kerak. Yana ham aniqroq aytsak static methodlar ham eval degani aylanay 😉
Dependency Inversion
High-level modullar yoki classlar low-level modul yoki classlarga bog'liq bo'lmasligi kerak. Buning o'rniga ular abstractionga bog'liq bo'lishi kerak
- High-level class: ishni bajaruvchi.
- Low-level class: ishni bajaruvchi qurol
- Abstraction: Shu ikkisini bog'lovchi o'rtakash (connector)
Misol uchun Televizorni olaylik. Televizorni pulti o'zida yoki ichki mehanizmga bog'lanmasligi kerak. Agar shunday bo'lsa televizordagi o'sha qism buzilsa ham usta chaqirasiz, boshqa qism buzilsa ham usta chaqirasiz. Uning o'rniga esa pultni alohida masaofaviy boshqaruvga o'tkazishingiz mumkin bo'ladi. Pultni batareyasi o'chsa televizorni emas pultni ochasiz. Pult buzilsa televizorni emas pultni tuzatasiz . Xullas abstraction bu yerda ikkisini bog'lovchi tizmda aylanay )
Yuqoridagi tushunchalar to'liq yoritilmagan va ushbu yo'llar bilan yoritilishidan maqsad oson tushunish uchun va umumiy tushunchalar berildi. Keyingi sonlarda har biriga alohida, pros-and-cons qilib to'xtalib o'tishga harakat qilamiz.