Tarjimondan: Afsuski, men ingliz tilida juda ko'p o'qigan bo'lsam ham, ingliz tilidan tarjima qilishda sezilarli tajribaga ega emasman. Ammo o'qish va tarjima qilish ikki xil narsa ekanligi ma'lum bo'ldi. Bundan tashqari, afsuski, menda sezilarli dasturlash tajribam yo'q (men yaqinda Spring MVC va Hibernate-da oddiy veb-ilovani yaratdim). Shuning uchun tarjima bo'lishi mumkin bo'lgandan ham yomonroq bo'lib chiqdi. Men maqolada keltirilgan kod misollarini biroz tuzatishga ruxsat oldim, chunki ular Java tilidagi nomlash qoidalariga mos kelmaydi. Ehtimol, ba'zi naqshlarning nomlarini tarjima qilishning hojati yo'qdir (bunday tarjima ko'p tushunishni ta'minlamaydi), lekin men bu yomonroq narsa deb o'yladim. "Yuqori uyg'unlik" ning tarjimasi sifatida "yuqori uyg'unlik" haqida alohida aytib o'tish kerak. Qabul qilaman, eng yaxshi tarjima emas. Ammo "kuchli ulanish" - bu "yuqori ulanish" (yana bir muhim tushuncha) va bu erda "muvofiqlik" mos bo'lishi dargumon. Men tanqidga ochiqman va maqolaga har qanday shakldagi sharhlarni minnatdorchilik bilan qabul qilaman. Ob'ektga yo'naltirilgan dasturlash - bu dasturlash uslubi bo'lib, unda dastur real dunyo ob'ektlariga mos keladigan komponentlardan iborat.Har qanday real ob'ekt o'ziga xos xususiyatlarga (vaqt o'tishi bilan o'zgarishi yoki o'zgarmasligi) va xatti-harakatiga (ular yoki bo'lmasligi mumkin) ega. boshqalarga qarab o'zgaradi). shartlari). Masalan, qalam quyidagi xususiyatlarga ega bo'lgan haqiqiy dunyo ob'ektidir:
U qizil (bu vaqt o'tishi bilan o'zgarmaydi).
Hozir u 10 santimetr uzunlikda (qalam o'tkirlashganda bu o'zgarishi mumkin).
Va u quyidagi xatti-harakatlarga ega:
To'g'ri ishlatilsa, iz qoldiradi.
Bosimga qarab (tashqi omillarga qarab) iz farq qilishi mumkin.
Uning uzunligi keskinlashganda qisqaradi (doimiy xatti-harakatlar).
Ushbu misolda bo'lgani kabi, real dunyo ob'ektlari juda ko'p xususiyatlarga ega bo'lishi mumkin, ammo dasturlarni yozishda biz faqat kerakli xususiyatlarni hisobga olamiz. Ob'ektga yo'naltirilgan dasturlashning afzalliklari bor. Masalan, real dunyo ob'ekti va dastur o'rtasidagi aloqani kutilgan tarzda o'rnatishni osonlashtiradi. Bu haqiqatan ham dastur o'sib borishi va ko'plab ob'ektlar bir-biri bilan o'zaro ta'sirida yordam beradi. Bu ob'ektiv dunyoda mas'uliyatni taqsimlashga yordam beradi, bu sizga ilova orqali fikrlashga e'tiboringizni qaratish imkonini beradi. OOP (Ob'ektga yo'naltirilgan dasturlash) bilan bog'liq yana bir muhim xususiyat - bu ob'ektlarning tasnifi. Dunyo (haqiqiy/virtual) ob'ektlarga to'la bo'lgani uchun ularni alohida nazorat qilish qiyin. Bizga turli xil ob'ektlar va ularning xususiyatlarini, masalan, qora qalam bilan bog'lashimizga yordam beradigan ushbu ob'ektlarni tasniflash usuli kerak. Agar oldingi misolda ishlatilsa, uni ajratib bo'lmaydigan bo'lar edi (bir xil?), lekin u boshqa ob'ekt. Ammo ikkalasi ham qalam bo'lgani uchun ular bir xil "Qalam" sinfiga kiradi. Holbuki, qalamga juda o'xshash qalam boshqa sinfga tegishli. Biroq, qalam va qalam ikkalasi ham "Yozuv asboblari" dir. Ob'ektga yo'naltirilgan dasturlash quyidagi printsiplarga ega:
Abstraktsiya
Abstraktsiya hodisalar emas, balki g'oyalar bilan o'zaro ta'sir qilish sifati yoki boshqacha qilib aytganda, vakillik fazilatlaridan ozodlik sifatida aniqlanadi . Bu dasturchilarga qanday dasturlashdan ko'ra nima dasturlash kerakligiga e'tibor qaratish imkonini beradi . Abstraktsiyani biz funksionallikni ta'minlovchi shartnoma sifatida ko'rib chiqish mumkin. Ushbu kontseptsiyadan foydalanganda amalga oshirish tafsilotlari yashirin bo'lishi mumkin. Misol uchun, agar bizga yozuvchi sinf kerak bo'lsa, unda "yozish" usuli borligiga ishonch hosil qilishimiz kerak.Biz nima qildik? Biz mavhum bo'lgan yuqori darajadagi sinfni ishlab chiqdik, boshqacha qilib aytganda, u bizga qanday funksionallik kerakligini biladi, lekin uni qanday amalga oshirish bu sinfning doirasiga kirmaydi. Bu juda ko'p afzalliklarni beradi: abstract class writer { write (); }
Biz tashqi ob'ektlar uchun zarur bo'lgan minimal ma'lumotlarni oshkor qilamiz, bu bizga dastur orqali fikrlashga e'tiborni qaratishga imkon beradi (bu yo'naltirilgan fikrlashni ta'minlaydi), chalkashliklardan qochish va kutilmagan va'dalar berishdan qochish imkonini beradi.
Agar amalga oshirish tafsilotlari oshkor etilsa, biz kelajakdagi yaxshilanishlar uchun joy qoldiramiz.
Meros olish
Umumiy ingliz tilidagi "meros" "olish va o'tkazish" degan ma'noni anglatadi. Bu so'z bizning madaniyatimizda juda uzoq vaqtdan beri mavjud. Ajdodlar mehnat evaziga yerga ega bo‘lib, o‘z farzandlariga meros qilib qoldirgan, hatto tabiat ham merosxo‘rlikka intiladi. Tananing barcha xususiyatlari, masalan, balandlik, teri / ko'z / soch rangi va boshqalar. ota-onamizdan meros bo'lgan genlarga bog'liq. Meros g'ildirakni qayta ixtiro qilishga to'sqinlik qiladi va taraqqiyotni tezlashtiradi. OOPda ham xuddi shunday. Biz bir nechta asosiy xususiyatlar/xulq-atvorga ega ota-ona sinfini yaratamiz. Ushbu ota-onadan meros bo'lgan barcha sinflar ota-onasi bilan bir xil xususiyatlar/xulq-atvorni o'z ichiga oladi. Biroq, meros qilib olingan sinflar ko'proq xususiyatga/xulq-atvorga ega bo'lishi yoki xatti-harakatni amalga oshirishni o'zgartirishi mumkin. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } Yuqoridagi misolda, ota-klass (WritingInstrument) "rang" xususiyatiga va "yozish" xatti-harakatiga ega. Nasl sinfi (tutqich) e'lon qilinganda, "rang" xususiyati va "yozish" xatti-harakati qayta e'lon qilinishi shart emas. Ular meros tufayli "tutqich" sinfida mavjud. Biroq, avlod sinfi o'zining qo'shimcha xususiyatlarini/xulq-atvorini e'lon qilishi mumkin. Buni amalda qanday qo'llashimiz mumkin? Biz ishlab chiquvchilar juda dangasamiz. Biz biror narsani qayta-qayta chop etishni xohlamaymiz. Bir xil kodning bir nechta nusxalarining mavjudligi quyidagi fikrlar tufayli tavsiya etilmaydi:
Kodning nusxalari qancha kam bo'lsa, uni saqlash shunchalik oson bo'ladi.
Agar kodning nusxalari ko'p bo'lmasa, unda bir joyda o'zgarish hamma joyda ko'rinadi.
Kod qancha kam bo'lsa, xatolar shunchalik kam bo'ladi.
Agar bitta kod ko'p joylarda ishlatilsa, umumlashtirishga erishiladi.
Biz kod yozishga e'tibor qaratamiz.
Biz sinovlarga e'tibor qaratamiz.
Java-da merosga "kengaytiradi" va "amalga oshiradi" kalit so'zlari yordamida erishiladi. class WritingInstrument { } class Pen extends WritingInstrument { }
Polimorfizm
"Polimorfizm" so'zi ikki so'zdan kelib chiqadi: "Poly" , ya'ni. "ko'p" / "birdan ortiq" "morf" , ya'ni. "Shakl" So'zma-so'z "polimorfizm" so'zi ob'ektlarning sharoitlarga qarab turli yo'llar bilan harakat qilish qobiliyatini anglatadi. Dasturlashda polimorfizm bir necha joylarda amalga oshirilishi mumkin:
Sinflar
Usullari
Operatorlar
Yuqorida aytilganlarning barchasi shartlarga, ehtimol kontekstga qarab, o'zini boshqacha tutishi mumkin. Bu foydali, chunki mijoz (sizning kutubxonalaringizdan foydalanadigan dasturchi) juda ko'p nozik narsalarni bilishi shart emas va kerakli funksionallik kontekstdan kerakli ma'lumotlarni tanlash orqali amalga oshiriladi. Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } Yuqoridagi misolda WritingObject-da standart dastur mavjud bo'lib, u nasl sinflari qalam va qalam tomonidan kengaytirilgan/bekor qilingan. write() usuli Main sinfida uch marta chaqiriladi. Usul qaysi ob'ektga chaqirilishiga qarab har safar boshqa amalga oshirish chaqiriladi. Bunday holda, write() usuli ko'p turdagi xatti-harakatlarga ega, chunki u polimorfikdir.
Inkapsulyatsiya
Inkapsulyatsiya tegishli ma'lumotlarni/funksionallikni bir birlikda to'plash deb ta'riflanadi. Bu ma'lumotlarga kirish/modifikatsiyani osonlashtirishga yordam beradi. Misol uchun, agar bizga berilgan foydalanuvchining barcha xossalarini chop etishimiz kerak bo'lsa, bizda quyidagi variantlar mavjud: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Biz barcha xususiyatlarni oladigan va ularni birin-ketin chop etadigan usul yaratdik. Ro'yxatdagi elementlar soni ortib borayotganligi sababli, endi to'g'ri maydonlarni aniqlash mumkin bo'lmaydi va bitta maydonni qo'shish/o'chirish usul imzosini o'zgartiradi. Shuning uchun, biz ushbu usulning barcha foydalanuvchilarini almashtirishimiz kerak, hatto ular yaqinda qo'shilgan maydonlarga muhtoj bo'lmasa ham. Kodni o'qish uchun qulayroq qilish va kelajakdagi o'zgartirishlarni osonlashtirish uchun biz xususiyatlarni sinfga kiritamiz va uni umumiy ob'ektga aylantiramiz.Ob'ekt class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} o'zgaruvchilar va bog'liq usullardan iborat dasturiy ta'minot to'plamidir. Haqiqiy dunyo ob'ektlarini dastur ob'ektlaridan foydalanib ko'rsatishingiz mumkin. Siz animatsiya dasturida haqiqiy itlarni yoki jismoniy mashqlar velosipedidagi dasturiy ob'ekt sifatida haqiqiy velosipedni tasavvur qilishingiz mumkin. OOPda sinf ob'ektlarni yaratish, ularni boshlang'ich holat (o'zgaruvchilar) bilan ta'minlash va xatti-harakatlarni (funktsiyalar, usullar) amalga oshirish uchun kengaytiriladigan shablon (dastur-kod-shablon) hisoblanadi. SOLID qisqartmasi 2000-yillarning boshlarida Robert C. Martin tomonidan atalgan "birinchi beshta tamoyil" uchun Maykl Feather tomonidan yaratilgan. Prinsiplarning maqsadi, birgalikda amalga oshirilganda, dasturchi oson saqlash va kengaytirish imkonini beradigan tizimni yaratish ehtimolini oshirishdir. SOLID tamoyillari - bu dasturni ishlab chiqishda "chirigan" kodni qayta ishlash orqali olib tashlash uchun zarur bo'lgan ko'rsatmalar bo'lib, buning natijasida kod osongina o'qilishi va kengaytirilishi kerak. Bu tezkor va moslashuvchan dasturlash strategiyasining bir qismidir.
Yagona javobgarlik printsipi
OOPda yagona mas'uliyat printsipi har bir sinf dastur tomonidan taqdim etilgan funksiyalarning bir qismi uchun javobgar bo'lishi kerakligini va bu mas'uliyat ushbu sinf tomonidan to'liq qamrab olinishi kerakligini bildiradi. Uning barcha funksionalligi ushbu mas'uliyat bilan chambarchas bog'liq bo'lishi kerak.
Ochiq/yopiq printsip
OOPda ochiq/yopiq tamoyil “dasturiy taʼminot obʼyektlari (sinflar, modullar, usullar va h.k.) kengaytirish uchun ochiq, lekin oʻzgartirish uchun yopiq boʻlishi kerak”, deb taʼkidlaydi. Boshqacha qilib aytganda, ob'ekt manba kodini o'zgartirmasdan o'z xatti-harakatlarini kengaytirishga ruxsat berishi kerak.
Liskov almashtirish printsipi
O'rinbosarlik OOPda printsipdir. Unda aytilishicha, agar kompyuter dasturidagi S T ning kichik turi bo'lsa, u holda T tipidagi ob'ektlar o'zgarmasdan S tipidagi ob'ektlar bilan almashtirilishi (ya'ni S tipidagi ob'ektlar T tipidagi ob'ektlar bilan almashtirilishi mumkin) bo'lishi kerak. har qanday talab qilinadigan xususiyatlar dasturlari (aniqlik, vazifani bajarish va boshqalar).
Interfeysni ajratish printsipi
Interfeysni ajratish printsipi shuni ko'rsatadiki, mijoz dasturchi o'zi ishlatmaydigan usullarga bog'liq bo'lishga majburlanmasligi kerak. Ushbu printsipga ko'ra, mijoz dasturchi faqat o'zi uchun qiziqarli bo'lgan usullar haqida bilishi uchun katta interfeyslarni kichikroq va aniqroq bo'lganlarga bo'lish kerak. Interfeysni ajratish printsipining maqsadi tizimni ajratilgan holda saqlashdir, bu esa uni qayta tiklash, o'zgartirishlar kiritish va qayta joylashtirishni osonlashtiradi.
Bog'liqlik inversiyasi printsipi
OOPda qaramlik inversiyasi printsipi dastur modullari orasidagi uzilishning o'ziga xos shaklini bildiradi. Ushbu tamoyilga amal qilgan holda, dastur arxitekturasini (siyosatini o'rnatish) tashkil etuvchi yuqori darajali modullardan qaram past darajadagi modullarga o'rnatilgan standart bog'liqlik munosabatlari teskari (teskari) o'zgartiriladi, shuning uchun o'zgartirilgan yuqori darajadagi modullar dasturni amalga oshirish tafsilotlaridan mustaqil bo'ladi. past darajadagi modullar. Ushbu tamoyil quyidagilarni bildiradi:
Yuqori darajadagi modullar past darajadagi modullarga bog'liq bo'lmasligi kerak. Ikkala turdagi modul ham abstraktsiyalarga bog'liq bo'lishi kerak.
Abstraktsiyalar amalga oshirish tafsilotlariga bog'liq bo'lmasligi kerak. Tafsilotlar abstraktsiyalarga bog'liq bo'lishi kerak.
Bu printsip odamlarning ob'ektga yo'naltirilgan dizayn haqida o'ylash usullarini o'zgartiradi va yuqori va past darajadagi ob'ektlar bir xil abstraktsiyalarga bog'liq bo'lishi kerakligini ta'kidlaydi.
GRASP tamoyillari
General Responsibility Assignment Software Patterns (GRASP) ob'ektga yo'naltirilgan dizayndagi sinflar va ob'ektlarga mas'uliyatni belgilash bo'yicha ko'rsatmalar beradi.
Nazoratchi
Controller namunasi tizim hodisalari bilan oʻzaro aloqada boʻlish masʼuliyatini butun tizimni ifodalovchi GUI boʻlmagan sinflarga yoki foydalanish holatlari stsenariysiga yuklaydi. Nazoratchi:
Bu foydalanuvchi bilan bevosita aloqada bo'lmagan va tizim hodisalarini qabul qilish va ularga javob berish uchun javobgar bo'lgan ob'ekt.
Bitta (yoki bir nechta o'zaro bog'liq) foydalanish holatlarining barcha tizim hodisalari bilan shug'ullanish uchun ishlatilishi kerak.
Bu tizim operatsiyalarini boshqaradigan GUI ortidagi birinchi ob'ekt.
U ishni o'zi bajarishi shart emas, uning vazifasi voqealar oqimini nazorat qilishdir.
Yaratuvchi
Yaratuvchi sinfning vazifasi keyinchalik foydalanish uchun ob'ektlarni yaratish va ishga tushirishdir. U ishga tushirish parametrlarini, shuningdek, qanday ob'ekt yaratilishini biladi. Ba'zan yaratuvchi sinf ob'ektlarni faol ravishda yaratadi va ularni keshga joylashtiradi va kerak bo'lganda bitta misolni taqdim etadi.
Yuqori uyg'unlik
Yuqori uyg'unlik - bu baholash sxemasi bo'lib, uning maqsadi ob'ektlarni bitta aniq vazifani bajarishga qaratilgan, oson boshqariladigan va tushunarli holatda saqlashdir. Yuqori ulanish odatda past ulanishni qo'llab-quvvatlash uchun ishlatiladi. Yuqori izchillik ma'lum bir elementning mas'uliyati aniq belgilanganligini bildiradi (kuchli bog'liq va yuqori darajada yo'naltirilgan). Dasturni sinflar va quyi tizimlarga bo'lish tizim xususiyatlarining uyg'unligini oshiradigan harakatlarga misoldir. Boshqa tomondan, bo'shashmasdan ulanish - bu elementning juda ko'p bog'liq bo'lmagan vazifalari bo'lgan vaziyat. Bo'shashmasdan bog'langan elementlarni tushunish qiyin, qayta foydalanish mumkin, saqlash qiyin va o'zgartirish qiyin.
Bilvosita
Aylanma yo‘nalish ikki element o‘rtasidagi o‘zaro ta’sir uchun mas’uliyatni oraliq ob’ektga yuklash orqali o‘rtasida bo‘sh ulanishni (va qayta foydalanishni) saqlaydi. Misol - Model-View-Controller (MVC) naqshida ma'lumotlar (model) va uning ko'rinishi (ko'rinishi) o'rtasida vositachilik qilish uchun boshqaruvchining kiritilishi.
Axborot bo'yicha mutaxassis
Axborot eksperti (shuningdek, ekspert yoki ekspert printsipi) mas'uliyatni kimga topshirishni aniqlash uchun qo'llaniladigan printsipdir. Mas'uliyat usullari, hisoblangan maydonlar va boshqalarni o'z ichiga oladi. Mas'uliyatni belgilashda ushbu printsipdan foydalanishda asosiy yondashuv quyidagi harakatlar ketma-ketligidir: mas'uliyatni tahlil qilish, uni bajarish uchun zarur bo'lgan ma'lumotlarni aniqlash va nihoyat, bu ma'lumot qaerda joylashganligini aniqlash. Axborot eksperti printsipidan foydalanish, uni bajarish uchun eng ko'p ma'lumotga ega bo'lgan sinfga mas'uliyat yuklanishiga olib keladi.
Past ulanish
Bo'shashmasdan ulanish - bu mas'uliyatni qanday belgilashni ko'rsatadigan baholash namunasidir: sinflar orasidagi bo'sh ulanish, birini o'zgartirish ikkinchisiga minimal ta'sir ko'rsatishi, qayta foydalanishni maksimal darajada oshirishi kerak.
Polimorfizm
Polimorfizmga ko'ra, turga qarab xatti-harakatlarning o'zgarishi, bu o'zgarish sodir bo'lgan turlarga beriladi. Bunga polimorfik operatsiyalar yordamida erishiladi.
Himoyalangan o'zgarishlar
Himoyalangan o'zgarishlar namunasi elementlarni boshqa elementlarga (ob'ektlar, tizimlar, quyi tizimlar) o'zgartirishdan himoya qiladi, bu interfeysdagi beqarorlik markazini o'rash va ushbu interfeysning turli xil ilovalarini yaratish uchun polimorfizmdan foydalanish.
Sof ishlab chiqarish
Sof konstruksiya muammo sohasidagi kontseptsiyani ifodalamaydigan sinfni o'z ichiga oladi va bo'shashmasdan ulanish, yuqori ulanish va shuning uchun maksimal qayta foydalanish potentsialiga erishish uchun maxsus ishlab chiqilgan (Axborot eksperti namunasi taklif qilgan yechim bunga erishmaydi). Bunday sinf odatda domenga asoslangan dizaynda "Xizmat" deb ataladi.
Tanqid
Potok va boshqalar tomonidan olib borilgan tadqiqotlar OOP va protsessual yondashuvlar o'rtasida sezilarli farqlarni ko'rsatmadi.
OOPni boshqa texnologiyalar, ayniqsa relyatsion texnologiyalar bilan tanqidiy taqqoslash, qat'iy va keng qabul qilingan OOP ta'rifi yo'qligi sababli qiyin (Kristofer J. Date)
Boshqa tillar (LISP dialektlari, funktsional tillar va boshqalar) bilan taqqoslaganda, OOP tillari noyob afzalliklarga ega emas va keraksiz murakkablikni keltirib chiqaradi. (Lorens Krubner)
Men ob'ektga yo'naltirilgan dasturlashni texnik jihatdan zaif deb bilaman. U dunyoni bitta turdagi interfeyslar nuqtai nazaridan qismlarga ajratishga harakat qiladi. Haqiqiy muammolarni hal qilish uchun sizga ko'p turdagi algebralar kerak - ko'p turdagi interfeyslar oilalari. Men ob'ektga yo'naltirilgan dasturlashni falsafiy jihatdan nosog'lom deb bilaman. Unda aytilishicha, hamma narsa ob'ektdir. Agar bu to'g'ri bo'lsa ham, bu unchalik qiziq emas: hamma narsani ob'ekt deb aytish umuman hech narsa demaslikdir. (Aleksandr Stepanov)
Yirik kompaniyalar orasida OOPning mashhurligi "katta (va tez-tez o'zgaruvchan) o'rtacha dasturchilar guruhlari" bilan bog'liq. OOP tomonidan qo'yilgan intizom dasturchiga "juda ko'p zarar etkazish" ga yo'l qo'ymaydi. (Pol Grem)
Ob'ektga yo'naltirilgan dasturlash birinchi navbatda otlarni qo'yadi. Nega bunday ekstremal choralarga borib, nutqning bir qismini poydevorga qo'yish kerak? Nima uchun bir tushuncha boshqasidan ustun turadi? OOP to'satdan fe'llarni bizning fikrlashimiz uchun ahamiyatini kamaytirishi mumkin emas. Bu g'alati darajada egri nuqtai nazar. (Stiv Yegge)
Clojure yaratuvchisi Rik Xikki ob'ekt tizimlarini real dunyoning o'ta soddalashtirilgan modellari deb ta'riflagan. U OOP ning vaqtni to'g'ri modellash qobiliyatiga ega emasligini ta'kidladi, bu esa dasturlarda ko'p qirrali ishlash odatiy holga aylanganda katta muammolarni keltirib chiqaradi. Unix dasturchisi va ochiq kodli dasturiy ta'minot himoyachisi Erik S. Raymond OOP "Yagona yechim" degan da'voni tanqid qildi va OOP shaffoflikka xalaqit beradigan ko'p qatlamli dasturlarni rag'batlantirishini yozdi. Qarama-qarshi yondashuv sifatida Raymond Unix va C misollarini keltirdi.
GO TO FULL VERSION