Dasturiy ta'minotni to'g'ri dekompozitsiya qilish

Iyerarxik dekompozitsiya

Dasturingiz sinflarini yozishni darhol boshlamang. Avval uni loyihalash kerak. Loyihalash puxta o'ylangan arxitektura bilan yakunlanishi kerak. Ushbu arxitekturaga ega bo'lish uchun tizimni ketma-ket dekompozitsiya qilishingiz kerak.

Dekompozitsiya iyerarxik tarzda amalga oshirilishi kerak — avval tizimni katta funktsional modullar/yordamchi tizimlarga ajratib, uning ishini umumiy ko'rinishda tasvirlash kerak. So'ngra, olingan modullar batafsil tahlil qilinadi va submodul yoki ob'ektlarga bo'linadi.

Ob'ektlarni ajratishdan oldin, tizimni asosiy ma'noli bloklarga bo'ling, hech bo'lmasa aqlan. Kichik programmalarda buni qilish odatda juda oson: iyerarxiyaning bir necha darajalari odatda etarli, chunki tizim dastlab yordamchi tizimlar/paketlarga, paketlar esa sinflarga bo'linadi.

Bu fikr oddiy emas. Masalan, Model-Ko'rinish-Kontroller (MVC) kabi keng tarqalgan “arxitektura shablonining” mohiyati nimada?

Faqatgina taqdimotni biznes mantiqidan ajratishda. Har qanday foydalanuvchi dasturi avvaliga ikki modulga bo'linadi — biri biznes mantiqini amalga oshiradi (Model), ikkinchisi esa foydalanuvchi bilan o'zaro aloqani ta'minlaydi (Foydalanuvchi Interfeysi yoki Ko'rinish).

Keyin modullar qandaydir tarzda o'zaro aloqa qilishlari kerakligi ma'lum bo'ladi, buning uchun ularga Interaktiv boshqaruvchi qo'shiladi, uning vazifasi modullar o'rtasidagi o'zaro aloqani boshqarishdir. Shuningdek, mobil (klassik) MVC versiyasida, View modeldan hodisalarni qabul qilish va real vaqtda ko'rsatiladigan ma'lumotlarni o'zgartirish uchun Observer shabloni qo'shiladi.

Tizimning boshlang'ich bo'linishidan olingan yuqori darajadagi odatiy modullar quyidagilardir:

• Biznes-mantiqa;
• Foydalanuvchi interfeysi;
• Ma'lumotlar bazasi;
• Xabar almashish tizimi;
• Ob'ekt konteyneri.

Birinchi bo'linishda odatda butun dastur 2-7 (maksimal 10 bo'lak) bo'linadi. Agar ko'proq qismlarga ajratsangiz, ular yana guruhlanishi kerak bo'ladi va oxir-oqibat 2-7 yuqori darajadagi modullarni olamiz.

Funktsional dekompozitsiya

Modullar/yordamchi tizimlarga bo'linish tizim hal qiladigan vazifalarga asoslanib amalga oshirilishi eng yaxshi yechimdir. Asosiy vazifa uni tashkil etuvchi yordamchi vazifalarga bo'linadi, ular mustaqil, bir-biridan mustaqil hal qilinishi mumkin.

Har bir modul qandaydir yordamchi vazifani hal qilish uchun javobgar bo'lishi va unga mos keluvchi funktsiyani bajarishi kerak. Funktsional maqsaddan tashqari modulni uning funktsiyasini bajarish uchun zarur bo'lgan ma'lumotlar to'plami ham tavsiflaydi, ya'ni:

Modul = Funktsiya + Ma'lumotlar, uni bajarish uchun zarur bo'lgan.

Agar modullarga dekompozitsiya to'g'ri bajarilgan bo'lsa, boshqa modullar bilan (boshqa funktsiyalar uchun mas'ul) o'zaro aloqasi minimal bo'ladi. U mavjud bo'lishi mumkin, lekin uning yo'qligi sizning modulingiz uchun tanqidiy ahamiyatga ega bo'lmasligi kerak.

Modul — bu tasodifiy kod bo'lagi emas, balki ma'lum bir vazifani ta'minlaydigan va ideal holda mustaqil yoki boshqa muhitda ishlay oladigan va qayta ishlatilishi mumkin bo'lgan funktsional mantiqli va tugallangan dasturiy birlikdir (kommunikatsiya). (Kristofer Aleksandr)

Shunday qilib, savodli dekompozitsiya, avvalo, tizim funktsiyalari va ularga kerakli ma'lumotlarni tahlil qilishga asoslanadi. Bunday holda funktsiyalar — bu sinf funktsiyalari va modullar emas, chunki ular ob'ektlar emas. Agar sizning modulingizda atigi ikkita sinf bo'lsa, demak siz haddan tashqari harakat qilgansiz.

Kuchli va zaif bog'lanish

Modullarga bo'linishda ortiqcha ketmaslik juda muhim. Agar yangi boshlovchiga monolit Spring-dasturini topshirib, uni modullarga bo'lishni so'rasangiz, u har bir Spring Bean-ni alohida modulga chiqarib, ishini tugatgan deb hisoblaydi. Lekin bu noto'g'ri.

Dekompozitsiya sifati uchun asosiy mezon modullarning o'z vazifalarini hal qilishda qanchalik diqqatli ekanligi va mustaqilligi hisoblanadi.

Odatda, bu quyidagicha ifodalanadi: "Dekompozitsiya natijasida olingan modullar ichida maksimal darajada birlashtirilgan bo'lishi kerak (high internal cohesion) va bir-biriga minimal bog'langan bo'lishi kerak (low external coupling)."

High Cohesion, yuqori birlashtirilganlik yoki "jipslik" moduli ichida, uning tor doiradagi bir muammoni hal qilishga diqqat qilganligidan dalolat beradi, turlicha funktsiyalar yoki bir-biri bilan aloqasiz majburiyatlarni bajarishga yo'naltirilmagan.

Birlashtirilganlik — cohesion, moduli bajaradigan vazifalar bir-biri bilan qanchalik bog'liqligini ifodalaydi.

High Cohesionning natijasi yagona mas'uliyat tamoyili (Single Responsibility Principle — SOLIDning birinchi beshtalik tamoyili) bo'lib, unga ko'ra har qanday ob'ekt/modul faqat bitta mas'uliyatga ega bo'lishi kerak va uni o'zgartirish uchun bir nechta sabab bo'lmasligi kerak.

Low Coupling, zaif bog'lanish, tizim modullarga bo'linganda ular iloji boricha mustaqil yoki bir-biriga zaif bog'langan bo'lishi kerakligini anglatadi. Ular o'zaro aloqa qila olishlari kerak, lekin bir-biri haqida iloji boricha kamroq bilishlari kerak.

Har bir modul boshqa modullarning qanday tuzilganini, qanday tilda yozilganini va qanday ishlashini bilmasligi kerak. Bunday modullarning o'zaro aloqasini tashkil qilish uchun odatda qandaydir konteyner ishlatiladi, bu modullar ham unga yuklanadi.

To'g'ri loyihalashtirishda, bitta modulni o'zgartirishda, boshqalarni tuzatishga hojat qolmaydi yoki bu o'zgarishlar minimal bo'ladi. Qanchalik zaif bog'lanish bo'lsa, dastur yozish/tushunish/kengaytirish/ta'mirlash osonroq bo'ladi.

Savodli loyihalangan modullar quyidagi xususiyatlarga ega bo'lishi kerak deb hisoblanadi:

• Funktsional yaxlitlik va tugallanish — har bir modul bitta funktsiyani amalga oshiradi, lekin uni yaxshi va to'liq amalga oshiradi, modul o'z funktsiyasini amalga oshirish uchun to'liq operatsiyalar to'plamini mustaqil ravishda bajaradi.
• Bitta kirish va bitta chiqish — dasturiy modul kirishda belgilangan boshlang'ich ma'lumotlar to'plamini oladi, mazmunli ishlov beradi va bitta natija ma'lumotlar to'plamini qaytaradi, ya'ni IPO standart tamoyili amalga oshiriladi — kirish–>jarayon–>chiqish.
• Mantiqiy mustaqillik — dasturiy modulning ishlashi faqat boshlang'ich ma'lumotlarga bog'liq, boshqa modullar ishlashiga bog'liq emas.
• Boshqa modullar bilan zaif axborot aloqalari — modullar o'rtasidagi ma'lumot almashish imkon qadar minimallashtirilishi kerak.

Yangi boshlovchiga modullar tegishli bog'liqlikni qanday yanada zaiflashtirishni tushunish juda qiyin. Qisman bu bilim tajriba bilan keladi, qisman — aqlli kitoblarni o'qishdan so'ng. Ammo eng yaxshi yordamdagi narsa allaqachon mavjud dasturlar arxitekturasining tahlili.

Merosdan ko'ra kompozitsiya

Savodli dekompozitsiya — bu ko'pgina dasturchilar uchun san'at va murakkab vazifa. Soddaligi chalg'ituvchi va xatolar qimmatga tushadi.

Ba'zida ajratilgan modullar bir-biriga juda bog'liqlik qiladi va ularni mustaqil ravishda ishlab chiqish mumkin emas. Yoki har birining qaysi funktsiyaga javobgar ekanligi noaniq. Agar siz shunga o'xshash muammo bilan duch kelsangiz, ehtimol modullarga bo'linish noto'g'ri amalga oshirilgan bo'lishi mumkin.

Har doim har bir modulning qanday rol o'ynashi aniq bo'lishi kerak. Modullar mustaqil va qadrli yordamchi dasturlar bilan yakunlansa, ular ilovadan ajratib olib ishlatiladigan (va demak, qayta ishlatiluvchi) bo'lishi mumkin bo'lgani uchun dekompozitsiya to'g'ri amalga oshirilganligini eng ishonchli mezon hisoblanadi.

Tizimni dekompozitsiya qilishda uning sifatini tekshirishni tavsiya etiladi, masalan: "Har bir modul qanday vazifani bajaradi?", “Modullarni qanchalik oson sinovdan o'tkazish mumkin?”, “Modullarni mustaqil yoki boshqa muhitda ishlatish mumkinmi?”, “Bitta moduldagi o'zgarishlar boshqalarga qanchalik ta'sir qiladi?” kabi savollarni berish orqali sinab ko'rish.

Modullar iloji boricha mustaqil bo'lishi kerak. Avval aytib o'tilganidek, bu to'g'ri dekompozitsiyaning kalit parametri hisoblanadi. Shuning uchun, modullar dastlab bir-biriga zaif bog'liq bo'lishlari kerak. Agar bu sizga muvaffaq bo'lsa, siz zo'rsiz.

Agar yo'q bo'lsa, bu erda hamma narsa yo'qolmagan. O'zaro aloqalarni minimallashtirish va zaiflashtirish uchun bir qator maxsus texnikalar va shablonlar mavjud. Masalan, MVC holatda bu maqsad uchun Observer shabloni ishlatilgan, ammo boshqa yechimlar ham bo'lishi mumkin.

Aytish mumkinki, bog'liqlikni kamaytirish texnikalari, arxitektoraning asosiy “vositasi”ni tashkil qiladi. Faqat shuni tushunish kerakki, gap barcha yordamchi tizimlar haqida ketmoqda va bog'liqlikni barcha iyerarxik darajalarda zaiflashtirish kerak, ya'ni faqat sinflar orasida emas, balki har bir iyerarxik darajadagi modullar o'rtasida ham.