Dasturiy ta'minotni dasturlash bo'yicha tajribasiga ega bo'lgan har bir kishi, ularning martaba yo'liga qarab baholash parametrlaridan foydalangan holda, boshqalar tomonidan yozilgan dastur kodini baholaydi.
Kasbiy faoliyatim davomida men ko'plab ishlab chiqaruvchilarni tanidim va minglab kod satrlarini ko'rdim va ishlab chiquvchilarning mahoratini baholashim kerak bo'lganda men asosan ikkita omilni ko'rib chiqaman:
Yaxshiyamki, kodlashni yaxshiroq qilishni osonlashtiradigan ba'zi bir asoslar yoki printsiplar mavjud.
SOLID qisqartmasi:
S: yagona javobgarlik printsipi
O: ochiq-yopiq printsip
L: Liskovni almashtirish printsipi
I: Interfeysni ajratish printsipi
D: Bog'liqliklarni teskari yo'naltirish printsipi
Birinchi SOLID tamoyilini o'rganishdan boshlaymiz, ya'ni
Sinf (yoki modul) o'zgarishi, rivojlanishi uchun faqat bitta sabab bo'lishi kerak.
Kontseptsiyaning o'zi juda sodda, ammo ushbu soddaligiga erishish uchun amalga oshirish yo'li juda murakkab bo'lishi mumkin. Sinfni o'zgartirish uchun faqat bitta sabab bo'lishi kerak.
Lekin nega?
Nima uchun o'zgarishning yagona sababi bo'lishi juda muhim?
Masalan, o'zgarishning ikki xil sababi bo'lsa, ikki xil jamoa ikki xil sababga ko'ra bitta kod ustida ishlashi mumkin deb o'ylash mumkin. Tarkibiy tilda (masalan, C ++, C # yoki Java), boshqa jamoalar yoki dasturning boshqa qismlari bilan mos kelmaydigan modullarga olib kelishi mumkin bo'lgan har bir kishi o'z echimini amalga oshirishi kerak.
Yana bir misol, agar siz izohlangan tildan foydalanayotgan bo'lsangiz, turli sabablarga ko'ra bitta sinf yoki modulni qayta sinovdan o'tkazishingiz kerak bo'ladi. Bu sifat nazorati uchun ko'proq ish, vaqt va kuch sarflashni anglatadi.
Sinfi yoki moduliga tegishli bo'lishi kerak bo'lgan xususiyatni aniqlash, testlarni o'tkazish uchun nazorat ro'yxatiga qaraganda ancha murakkabroq.
Ammo texnik jihatdan kamroq fikr yuritishga harakat qilaylik, ya'ni sinfimiz yoki modulimiz foydalanuvchisini, ya'ni kim undan foydalanishini tahlil qilishga harakat qilaylik. Biz doimo yodda tutishimiz kerak bo'lgan asosiy jihat shundaki, biz ishlab chiqaradigan dastur yoki tizimning ma'lum bir modul tomonidan xizmat ko'rsatadigan foydalanuvchilari ushbu modifikatsiyani talab qilganlar bo'ladi. Xizmat qilganlar sinfni yoki modulni o'zgartirishni so'rashadi.
Modullarning ayrim namunalari va ulardan foydalanish:
Shunday qilib, agar birinchi qadam modul bilan suhbatdosh rolini o'ynaydigan aktyorlarni yoki aktyorni izlash bo'lsa, shaxslarni barcha rollar bilan bog'lash qiyin bo'lishi mumkin. Kichik kompaniyada bitta odam bir nechta rol o'ynashi mumkin, katta kompaniyada bitta rolga ega bo'lgan bir nechta odam bo'lishi mumkin.
Odamlarni yoki foydalanuvchilarni emas, balki rollarni aniqlash oqilona ko'rinadi.
Shuning uchun:
Keling, bir nechta misollarni ko'rib chiqaylik
Deylik, bizda kitob tushunchasi va uning funktsional imkoniyatlarini o'zida mujassam etgan Kitob sinfimiz bor.
sinf kitobi {
funktsiyasi getTitle () {
"Buyuk kitob" ni qaytarish;
}
funktsiyasi getAuthor () {
"Alessandro Baricco" ni qaytarish;
}
function nextpage () {
// keyingi sahifa
}
printCurrentPage () funktsiyasi {
echo "joriy sahifaning mazmuni";
}
}
Bu juda oddiy sinf. Bizning kitobimiz bor va sinf bizga sarlavha berishi mumkin, muallifni berishi va davom etishi mumkin. Va nihoyat, u joriy sahifani ekranda chop etishga qodir.
Biroq, kichik bir muammo bor.
Kitob ob'ektini boshqarishda ishtirok etgan aktyorlar haqida o'ylash, ular kim bo'lishi mumkin?
Bu erda ikki xil aktyor haqida bemalol o'ylashimiz mumkin: Kitoblarni boshqarish (kabi kutubxonachiva Ma'lumotlarni taqdim etish mexanizmi (foydalanuvchiga qanday qilib tarkibni etkazib berishni xohlayotganimiz kabi: ekrandagi, foydalanuvchi uchun grafik interfeys, faqat matn uchun foydalanuvchi interfeysi, ehtimol bosma).
Shuning uchun biz sinf bilan o'zaro aloqada bo'lgan ikkita juda xilma-xil aktyorlarga egamiz.
Qisqacha aytganda, bu sinf quyidagilarni o'z ichiga oladi:
bu muammo bo'lishi mumkin, chunki u yagona javobgarlik printsipini (SRP) buzadi.
Yagona javobgarlik printsipini hurmat qilish uchun qanday qilib o'zgartirishimiz mumkin, ushbu kodni qanday takomillashtirishimiz mumkin?
Quyidagi kodni ko'rib chiqing:
sinf kitobi {
funktsiyasi getTitle () {
orqaga "Oceano Mare";
}
funktsiyasi getAuthor () {
"Alessandro Baricco" ni qaytarish;
}
sahifani burish funktsiyasi () {
// keyingi sahifa
}
funktsiyasi getCurrentPage () {
echo "joriy sahifaning mazmuni";
}
}
interfeys printeri {
printPage funktsiyasi ($ page);
}
StampaLibro klassi Printerni amalga oshiradi {
printPages funktsiyasi ($ page) {
echo $ page;
}
}
class HtmlPrinter Printerni amalga oshiradi {
printPages funktsiyasi ($ page) {
aks-sado ' '. $ sahifa. ' ';
}
}
Ushbu juda oddiy misol taqdimotni biznes mantig'idan qanday ajratish kerakligini ko'rsatadi va SRP-ga muvofiq, bu bizning loyihamizning moslashuvchanligida katta afzalliklarga ega.
Keling, yana bir misolni ko'rib chiqaylik:
Yuqoridagi misolga o'xshash misol, ob'ekt o'zini taqdimotdan qutqarishi va qaytarib olishi mumkin.
sinf kitobi {
funktsiyasi getTitle () {
orqaga "Oceano Mare";
}
funktsiyasi getAuthor () {
"Alessandro Baricco" ni qaytarish;
}
sahifani burish funktsiyasi () {
// keyingi sahifa
}
funktsiyasi getCurrentPage () {
"joriy sahifaning mazmuni" ni qaytarish;
}
funktsiyani tejash () {
$ filename = '/ hujjatlar /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();
file_put_contents ($ filename, serialize ($ this));
}
}
Avvalgidek, bu erda ham biz turli xil aktyorlarni aniqlashimiz mumkin Kitoblarni boshqarish (kabi kutubxonachiva Qat'iylik. Biz har doim sahifadan sahifaga o'tish usulimizni o'zgartirmoqchi bo'lsak, bu sinfni o'zgartirishimiz kerak. O'zgarishlar uchun bir nechta sabablar bo'lishi mumkin.
sinf kitobi {
funktsiyasi getTitle () {
orqaga "Oceano Mare";
}
funktsiyasi getAuthor () {
"Alessandro Baricco" ni qaytarish;
}
sahifani burish funktsiyasi () {
// keyingi sahifa
}
funktsiyasi getCurrentPage () {
"joriy sahifaning mazmuni" ni qaytarish;
}
}
SimpleFilePersistence sinfi {
funktsiyani tejash (Book $ book) {
$ filename = '/ hujjatlar /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ filename, serialize ($ book));
}
}
Qat'iylik amaliyotini boshqa sinfga ko'chirish vazifalarni aniq ajratib beradi va biz o'zimizning "Book" sinfimizga ta'sir qilmasdan qat'iyatlilik usullari bilan almashamiz. Masalan, DatabasePersistence sinfini amalga oshirish ahamiyatsiz bo'lar edi va kitob operatsiyalari atrofida tuzilgan biznes mantig'imiz o'zgarmaydi.
Ikkinchi printsipni o'qish bilan davom eting Ochiq / Yopiq ->
Ercole Palmeri
Veeam tomonidan ishlab chiqarilgan Coveware kiber tovlamachilik hodisalariga javob berish xizmatlarini taqdim etishda davom etadi. Coveware sud tibbiyoti va remediatsiya imkoniyatlarini taklif qiladi ...
Bashoratli texnik xizmat ko'rsatish zavodlarni boshqarishga innovatsion va proaktiv yondashuv bilan neft va gaz sektorini inqilob qilmoqda.…
Buyuk Britaniya CMA Big Tech kompaniyasining sun'iy intellekt bozoridagi xatti-harakatlari haqida ogohlantirish e'lon qildi. U yerda…
Evropa Ittifoqi tomonidan binolarning energiya samaradorligini oshirish uchun ishlab chiqilgan "Yashil uylar" qarori qonunchilik jarayonini yakunladi ...
