S.O.L.I.D. ni bilasizmi?

Bir juda yaxshi inson yaqinda mendan
S.O.L.I.D. haqida eshitganmisiz deb so’rab qolishdi? Haqiqatdan, men S.O.L.I.D. haqida eshitganmanmi? Uni nimaligini bilamanmi? U biron bir yangi qurilmami? Yana bir yangi dasturlash tilimi? Balkim dasturchilar uchun navbatdagi «juda kerakli» ish vositasidir!?

Ushbu savollarga o’zim va «boshqa» yaxshi insonlar uchun javob berishga harakat qilaman.

S.O.L.I.D. — obyektga yo’naltirilgan dasturlashda dasturlarni loyihalashning 5 asosiy tamoyilidir. Bu loyihalashda qo’llanilishi mumkin bo’lgan va dasturchi uchun shu loyihada qo’shimchalar, kengaytirishlar, ish jarayoni chiqgan xatolarni to’g’illashni osonlashtiradigan tamoyillardir. Bu tamoyillarni qo’llash va qo’llamaslik dasturchining xohishiga bog’liq. Lekin, bu asosiy tamoyillar loyihalashda loyiga tadbiq qilinsa, ish sifati ancha yuqori bo’ladi. loyiha kodida tartib bo’ladi. Va shu bilan birga bu tamoyillar kodda keraksiz qatorlar va modul, komponentlar bo’lishidan, bir xil kod bir necha marta takrorlanishidan, qoleversa ba’zi hollarda kodni ko’p marotaba refaktoring qilishdan saqlab qoladi.

Demak, asosiy 5 tamoyil izohlari bilan quyida keltirilgan:

SRP(Single responsibility principle) — yagona javobgarlik tamoyili, bunda har bir obyekt uchun faqat bitta vazifa yuklanadi. Agar Sizda bitta jarayonni hamma aspektlarini boshqaradigan klass bo’lsa bu yaxshi. Lekin, bu klass boshqa obyektlarni o’zgartirishga harakat qilsa yoki juda ko’p metodlarni o’zida jamlagan bo’lsa demak, loyihalashda xatolik bor;

OCP(Open/closed principle) — ochiqlik/yopiqlik tamoyili, har bir dasturlash qisimlari kengaytirishlar qo’shish uchun ochiq, lekin uni o’zgartirish uchun yopiq bo’lishi kerak;

LSP(Liskov substitution principle) — Liskovning o’rin almashtirish tamoyili, bu tamoyil ilk bor amerikalik olima Barbara Liskov tomonidan e’lon qilingan bo’lib, dasturda obyektlarni shu obyekt klassining bola klasslaridan olingan nusxalari bilan almashtirish mumkin bo’ladi;

ISP(Interface segregation principle) — interfeyslarga bo’lish tamoyili, hamma holat uchun umumy bo’lgan interfeysdan, har bir mijoz uchun alohida bo’lgan ko’plab interfeyslar yaxshi. Vaqt o’tishi bilan Sizning loyihangiz kengayadi, unga yangi funksiyalar, imkoniyatlar qo’shiladi. Bunda, loyiha boshidan loyiha strukturasi ustidan kuchi nazorat olib borilmasa, loyiha boshida aniq bir funksiyani bajaruvchi metodlar, loyiha oxiriga borib umuman boshqa vazifani bajarishi mumkin;

DIP(Dependency inversion principle) — tobelarni almashtirish tamoyili, abstraksiya aniq bir obyektga bog’liq bo’lmasligi kerak, Aksincha, obyekt abstraksiyani qoidalariga bo’ysinishi kerak.

S.O.L.I.D. tamoyillari o’z-o’zidan mukammal obyektga yo’naltirilgan ko’rinish bermaydi. Bu tamoyillarni qo’llash mumkin bo’lgan/bo’lmagan vaqtlar, holatlar bo’ladi. Shunda to’g’ri qaror qabul qilish kerak bo’ladi. Dasturchilarni «g’alati», ko’p hollarda ularni ziyoniga ishlovchi odatlari bor: internetda qanaqadir bir, texnologiya, usul, dasturlash tili haqida o’qib qolishadida, u ularga manzur bo’ladi yoki qiziqtirib qo’yadi. Va ular keyingi loyihalarda shuni tadbiq qilamiz deb reja qilib qo’yishadi va keyingi loyihalarda tadbiq qilishadi ham. Lekin, ko’p hollarda tadbiq qilishgan usullari, texnologiyalari aynan ushbu loyiha uchun to’g’ri keladimi yo’qmi, umuman qarorlarini to’g’ri/noto’g’riligi haqida loyiha boshi berk ko’chaga kirib qolgandan keyin o’ylashni boshlashadi, bu juda yomon holat.