To'g'ridan-to'g'ri bog'liqlikni xabar almashishga almashtirish
Ba'zida modulga faqatgina o'zida qandaydir voqea/o'zgarishlar yuz berganini boshqa modullarga bildirish kerak bo'ladi va bu ma'lumot bilan keyin nimalar sodir bo'lishi unga muhim emas.
Bu holda modullar bir-birlari haqidagi ma'lumotlarga ega bo'lishlariga, ya'ni to'g'ridan-to'g'ri havolalar orqali o'zaro aloqada bo'lishlariga hojat yo'q, ular faqatgina xabarlar (messages) yoki voqealar (events) orqali ma'lumot almashishlari yetarli.
Ba'zida modullarni xabar almashish orqali bog'lash to'g'ridan-to'g'ri bog'liqlikdan ko'ra kuchsizroqdek tuyuladi. Haqiqatan ham, metodlar chaqirilmaydi, sinflar haqida ma'lumot yo'q. Lekin bu faqatgina bir illyuziya.
Metod ismlarining o'rniga logika xabar turlariga, ularning parametrlari va uzatilgan ma'lumotlarga bog'lanadi. Bu kabi modullarning bog'lanishi yoyilib ketadi.
Avval shunday edi: metodlarni chaqirardik — bog'lanish bor edi, metodlarni chaqirmasak — bog'lanish yo'q edi. Endi tasavvur qiling, modul A o'z xabarlarida biroz boshqacha ma'lumotlar yuborishni boshladi. Va shu vaqtning o'zida ushbu xabarlarga bog'liq bo'lgan barcha modullar noto'g'ri ishlaydi.
Masalan, ilgari yangi foydalanuvchi qo'shilganda avtorizatsiya moduli USER_ADDED degan xabarni yuborar edi, yangilashdan keyin esa ro'yxatdan o'tishda va muvaffaqiyatli ro'yxatdan o'tganligini qo'shimcha parametrlar bilan ko'rsatib yuboradi.
Shuning uchun xabarlar mexanizmini juda puxta amalga oshirish juda muhim. Buning uchun turli xil shablonlar mavjud.
Observer (Kuzatuvchi). “bir-ko'pga” bog'liqlik holatlarida qo'llaniladi, bir nechta modullar bitta asosiy modulning holatiga bog'liq bo'lganida. Moddiy xabarlar mexanizmini ishlatadi, ya'ni asosiy modul barcha obunachilarga bir xil xabarlarni yuboradi va shu ma'lumotga qiziqqan modullar “obunachi” interfeysini amalga oshiradi va tarqatishga obuna bo'ladi.
Bu usul foydalanuvchi interfeysi bo'lgan tizimlarda keng qo'llaniladi, dasturning yadrosi (model) mustaqil bo'lib qoladi va unga bog'langan interfeyslarga qandaydir o'zgarishlar bo'lganini va yangilanish zarurligini bildiradi.
Bu yerda xabarlarning formati operatsion tizim darajasida standartlashtiriladi, ishlab chiquvchilar qayta uyg'unlik va yaxshi hujjatlarni tayyorlashlari kerak.
Xabarlarni tarqatish orqali o'zaro aloqa tashkil qilishning qo'shimcha “bonus”i bor — “e'lon qilingan” (ya'ni tarqatilgan) xabarlarga “obunachilar” mavjud bo'lishi shart emas. To'g'ri loyihalashtirilgan bunday tizim har qanday vaqtda modullarni qo'shish/o'chirishni qabul qiladi.
Xabar almashish shinasi
Xabar almashishni boshqa yo'llar bilan tashkil qilish mumkin va buning uchun Mediator (Vositachi) patterndan foydalanish mumkin.
U modullar o'rtasida “ko'p-ko'pga” bog'liqlik mavjud bo'lganda qo'llaniladi. Mediator modullar o'rtasidagi aloqa vositachisi sifatida harakat qiladi, aloqa markazi sifatida ishlaydi va modullarni bir-biriga havola qilishdan xalos etadi.
Natijada modullar bir-birlari bilan (“hamma bilan hamma”) aloqa qilish o'rniga modullar faqatgina vositachi bilan (“bittasi barchasi bilan”) aloqa qiladi. Vositachi ko'plab modullar o'rtasidagi aloqani inkapsulyatsiyaladi, deyishadi.
Bu shunday deb ataladi aqlli vositachi. Aynan shu yerda ko'pincha ishlab chiquvchilar o'z o'zgartirishlarini qo'sha boshlaydi, alohida modullarning xatti-harakatlariga ma'lum xabarlarni olishni yoqib/o'chirish orqali ta'sir qiladi.
Hayotdan odatiy misol — aeroportdagi trafik nazorati. Samolyotlardan kelgan barcha xabarlar to'g'ridan-to'g'ri boshqa samolyotlarga emas, balki dispetcherga boshqarish minorasiga keladi. Dispetcher esa qaysi samolyotlar havoga ko'tarilishi yoki qo'nishi mumkinligini hal qiladi va navbatdagi xabarlarni samolyotlarga yuboradi.
Muhim! Modullar bir-birlariga faqat oddiy xabarlar emas, balki buyruq obyektlarini ham yuborishlari mumkin. Bu o'zaro aloqa Command (Buyruq) shabloni bilan tavsiflanadi. Asosiy maqsad muayyan harakatni bajarish talabi, alohida bir obyekt sifatida inkapsulyatsiyalanadi.
Aslida bu obyekt bitta yagona metod execute() ni o'z ichiga oladi, bu esa keyinchalik ushbu harakatni boshqa modullarga bajarish uchun parametr sifatida uzatishga imkon beradi va umuman, buyruq obyekti ustida oddiy obyektlarga nisbatan barcha operatsiyalarni bajarishga imkon beradi.
Demetra qonuni (law of Demeter)
Demetra qonuni yashirin bog'liqliklardan foydalanishni taqiqlaydi: "Obyekt A obyekt B ga kirish imkoniyatiga ega bo'lsa va obyekt B obyekt C ga kirish imkoniyatiga ega bo'lsa, obyekt A obyekt C ga bevosita kirish imkoniyatiga ega bo'lmasligi kerak".
Bu degani, barcha bog'liqliklar kodda “aniq” bo'lishi kerak — sinflar/modullar faqat “o'z bog'liqliklarini” ishlatishi va ular orqali boshqalarga kirishga urinmasligi kerak. Yaxshi misol — uch darajali arxitektura. Interfeys darajasi logika darajasi bilan ishlashi kerak, lekin to'g'ridan-to'g'ri ma'lumotlar bazasi darajasi bilan aloqada bo'lmasligi kerak.
Bu tamoyilni qisqacha quyidagicha ifoda qilishadi: "Faqat yaqin do'stlaring bilan o'zaro aloqada bo'l, do'stlaring do'stlari emas". Bu esa kodning kamroq bog'liqligiga, shuningdek, dizayni yanada aniq va tushunarli bo'lishiga olib keladi.
Demetra qonuni “minimal bilim tamoyilini” amalga oshiradi, u esa kuchsiz bog'liqlikning asosini tashkil qiladi va obyekt/modul boshqa obyektlar/modullar va umuman hamma narsa, shu jumladan o'z komponentlari haqida imkon qadar kamroq tafsilotlarni bilishi kerakligini bildiradi.
Hayotdan analogiya: agar siz itning yugurishini xohlasangiz, uning panjalariga buyruq berish o'rinsiz, yaxshiroq itga buyruq bering va u o'z panjalari bilan o'zi shug'ullanadi.
Merosdan ko'ra kompozitsiya
Bu juda katta va qiziqarli mavzu va u kamida alohida bir ma'ruzaga loyiq. Internetda bu mavzu yuzasidan ko'p tortishuvlar bo'lib o'tdi va nihoyat bir qarorga kelindi — merosni minimal foydalanish, kompozitsiyani esa maksimal foydalanish.
Barcha gap shundaki, meros sinflar o'rtasidagi amalda eng kuchli bog'liqlikni beradi, shuning uchun undan qochish kerak. Bu mavzu Gerb Satterning “Kompozitsiyani merosdan afzal ko'ring” maqolasida yaxshi ochib berilgan.
Pattenlarni o'rganishni boshlaganingizda, ob'yektni yaratish yoki uning ichki tuzilishini boshqaradigan bir nechta patternlar bilan uchrashasiz. Aytmoqchimanki, bu kontekstda Delegation/Delegate shabloniga va o'yinlardan kelib chiqqan Component (Komponent) shabloniga e'tiborni qarating.
Patternlar haqida batafsilroq keyinroq gaplashamiz.
GO TO FULL VERSION