SOLID ob'ektga yo'naltirilgan dasturlashning 5 tamoyili nimadan iborat

Qattiq geometrik raqamlar
ta'lim
1

SOLID - qisqartma bo'lib, ob'ektga yo'naltirilgan dizaynning beshta tamoyiliga (OOD yoki OOP) murojaat qiladi. Bu ishlab chiquvchilar boshqarish, saqlash va kengaytirishga oson bo'lgan dasturiy ta'minot yaratish uchun foydalanishi mumkin bo'lgan ko'rsatmalar. Ushbu tushunchalarni tushunish sizni yaxshi ishlab chiquvchiga aylantiradi va dasturiy ta'minotni boshqarish muammolaridan qochishga yordam beradi. Yaxshi dasturchi bo'lish nimani anglatadi?

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:

  • Kodni o'qishda soddalik;
  • Vaqt o'tishi bilan ularning kodlari ishlashi va rivojlanishi qanchalik ehtimoli bor.

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

Yagona javobgarlik printsipi

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:

  • Texnik xizmat ko'rsatish moduli: foydalanuvchi ma'lumotlar bazasi ma'murlari va dastur me'morlaridan iborat.
  • Hisobot moduli: foydalanuvchi ofis ishchilari, buxgalterlar va ishlab chiqarishdan iborat.
  • Ish haqini boshqarish tizimi uchun to'lovlarni hisoblash moduli: foydalanuvchilarga yuristlar, menejerlar va buxgalterlar kirishi mumkin.
  • Kutubxonani boshqarish tizimi uchun matnni qidirish moduli: foydalanuvchilarni kutubxonachi yoki kutubxonaning o'zi tashrif buyuruvchilar va mijozlar taqdim etishi mumkin.

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:

  • dasturiy ta'minot tizimidan foydalanuvchi o'zgarish sabablarini aniqlaydi;
  • mas'uliyat - bu ma'lum bir aktyorning, ya'ni tizim foydalanuvchisining ehtiyojlarini qondiradigan funktsiyalar oilasi;
  • aktyorlar, foydalanuvchi foydalanuvchi ehtiyojini qondirishi kerak bo'lgan funktsiyalar oilasi uchun o'zgarish manbasiga aylanadi;
  • foydalanuvchi ehtiyojlari evolyutsiyasi, funksionallik evolyutsiyasini boshqaradi;

SOLID tamoyillari

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:

  • bilan biznes mantiq 
  • taqdimot 

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 ->

1 izoh

Fikr qoldiring

E-pochta manzilingiz chop etilmaydi. Men o'zimni yo'qotib qoldim *

liskov printsipi
ta'lim
Liskovni almashtirish printsipi, uchinchi SOLID printsipi

Bolalar sinflari hech qachon ota-ona sinfining ta'riflariga ta'sir qilmasligi yoki o'zgartirmasligi kerak. Ushbu tamoyil kontseptsiyasi Barbara Liskov tomonidan 1987 yilgi konferentsiyaning asosiy ma'ruzasida kiritilgan va keyinchalik 1994 yilda Jannette Ving bilan birgalikda maqolasida chop etilgan. Ularning asl ta'rifi…

Google marketing tendentsiyalari
ta'lim
Google Trends-ni real vaqtda marketing uchun qanday ishlatish

2020 yilda kompaniyalar duch kelgan eng katta qiyinchiliklardan biri bu qaysi mahsulot tarmoqlari o'z biznesini diversifikatsiya qilishni tushunishda edi: aslida sanoat tarmoqlarining aksariyati og'ir oqibatlarga olib keldi, bu kompaniyalarga kirib borishi deyarli imkonsiz bo'lib, ayniqsa, yangi o'yinchi sifatida. Juda kam ishlab chiqarish sohalari ...

biznes-razvedka strategiyasi
usullari
Muvaffaqiyatli biznes intellekti uchun strategiyalar

Sizning biznes intellektingiz uchun muvaffaqiyatli strategiyani yaratish maqsadlarni to'g'ri ko'rishdan boshlanadi. Quyida ba'zi bir muhim fikrlarni ko'rib turibmiz. Mavjud vaziyatni baholash Ushbu jihatni qadrlamaslik katta xato bo'ladi. Mavjud vaziyatni baholash jarayonlarni, tuzilmalarni tahlil qilishni anglatadi ...