Аудармашыдан: Өкінішке орай, мен ағылшын тілінде көп оқысам да, ағылшын тілінен аударуда айтарлықтай тәжірибем жоқ. Бірақ оқу мен аудару екі бөлек нәрсе екені белгілі болды. Сондай-ақ, өкінішке орай, менде айтарлықтай бағдарламалау тәжірибем жоқ (мен жақында ғана Spring MVC және Hibernate-де қарапайым веб-қосымшаны жасадым). Сондықтан аударма мүмкін болғаннан әлдеқайда нашар болды. Мен мақалада келтірілген code мысалдарын сәл түзетуге еркіндік бердім, өйткені олар Java тіліндегі атау конвенцияларына сәйкес келмейді. Бәлкім, кейбір үлгілердің атауларын аударудың қажеті жоқ шығар (мұндай аударма көп түсінік бермейді), бірақ мен бұл азырақ зұлымдық деп ойладым. «Жоғары когезия» сөзінің аудармасы ретінде «жоғары когезия» туралы бөлек атап өткен жөн. Мен келісемін, ең жақсы аударма емес. Бірақ «күшті байланыс» — «жоғары байланыс» (басқа маңызды ұғым) және «келісімділік» бұл жерде қолайлы болуы екіталай. Мен сынға ашықпын және мақалаға кез келген нысандағы пікірлерді ризашылықпен қабылдаймын. Объектіге бағытталған бағдарламалау – бұл бағдарлама нақты дүние an objectілеріне сәйкес келетін компоненттерден тұратын бағдарламалау стилі.Кез келген нақты an objectінің кейбір қасиеттері (уақыт өте келе өзгеретін немесе өзгермеуі мүмкін) және мінез-құлқы (олар немесе болмауы мүмкін) болады. басқаларға байланысты өзгереді). Мысалы, қарындаш келесі қасиеттерге ие нақты дүние an objectісі болып табылады:
Ол қызыл (бұл уақыт өте келе өзгермейді).
Оның ұзындығы қазір 10 сантиметр (қарындаш өткірленсе, бұл өзгеруі мүмкін).
Және оның келесі мінез-құлқы бар:
Дұрыс пайдаланған жағдайда із қалдырады.
Із қысымға байланысты (сыртқы факторларға байланысты) әртүрлі болуы мүмкін.
Оның ұзындығы қайраған сайын қысқарады (тұрақты мінез-құлық).
Бұл мысалдағыдай, нақты дүние an objectілері көптеген қасиеттерге ие болуы мүмкін, бірақ бағдарламаларды жазғанда біз тек қажетті қасиеттерді ескереміз. Объектіге бағытталған бағдарламалаудың артықшылықтары бар. Мысалы, бұл нақты дүние an objectісі мен бағдарлама арасында күтілетін жолмен байланысты орнатуды жеңілдетеді. Бұл қолданбаның өсуіне және көптеген нысандар бір-бірімен әрекеттесетініне шынымен көмектеседі. Бұл an objectивті әлемде жауапкершілікті бөлуге көмектеседі, бұл қолданба арқылы ойлауға назар аударуға мүмкіндік береді. OOP (Object Oriented Programming) бағдарламасымен байланысты тағы бір маңызды мүмкіндік an objectілердің классификациясы болып табылады. Әлем (нақты/виртуалды) нысандарға толы болғандықтан, оларды жеке басқару қиын. Бізге әртүрлі нысандарды және олардың қасиеттерін, мысалы, қара қарындашты байланыстыруға көмектесетін осы нысандарды жіктеудің тәсілі қажет. Алдыңғы мысалда қолданылса, оны ажырату мүмкін емес еді (бірдей?), бірақ ол басқа нысан. Бірақ екеуі де қарындаш болғандықтан, олар бір «Қарындаш» класына жатады. Ал қарындашқа өте ұқсас қалам басқа сыныпқа жатады. Дегенмен, қалам мен қарындаш екеуі де «Жазу құралдары». Объектіге бағытталған программалаудың келесі принциптері бар:
Абстракция
Абстракция оқиғалардан гөрі идеялармен өзара әрекеттесу сапасы немесе басқаша айтқанда, бейнелеу қасиеттерінен босатылу ретінде анықталады . Бұл бағдарламашыларға қалай бағдарламалауға емес, нені бағдарламалауға назар аударуға мүмкіндік береді . Абстракцияны біз функционалдылықты қамтамасыз ететін келісімшарт ретінде қарастыруға болады. Бұл тұжырымдаманы пайдалану кезінде іске асыру мәліметтері жасырылуы мүмкін. Мысалы, бізге жазатын сынып керек болса, онда оның «жазу» әдісі бар екеніне сенімді болуымыз керек.Біз не істедік? Біз абстрактілі, басқаша айтқанда, ол бізге қандай функционалдық қажет екенін білетін жоғары деңгейлі сыныпты құрастырдық, бірақ оны қалай жүзеге асыру керектігі бұл сыныптың ауқымынан тыс. Бұл көптеген артықшылықтар береді: abstract class writer { write (); }
Біз сыртқы құрылымдарға қажетті ең аз ақпаратты ашамыз, бұл бағдарлама арқылы ойлауға назар аударуға мүмкіндік береді (бұл бағытталған ойлауға мүмкіндік береді), шатасуды болдырмайды және күтпеген уәделерді бермеуге мүмкіндік береді.
Біз болашақ жақсартулар үшін орын қалдырмаймыз, егер іске асыру мәліметтері ашылған болса, мүмкін болмайды.
Мұрагерлік
Жалпы ағылшын тіліндегі «мұра» «алу және беру» дегенді білдіреді. Бұл сөз біздің мәдениетімізде ежелден бар. Ата-бабалар жерді тынымсыз еңбекпен иемденіп, балаларына мұра етіп қалдырған, тіпті табиғат мұрагерлік етуді ұнатады. Дененің барлық қасиеттері, мысалы, бойы, тері/көз/шаш түсі, т.б. ата-анамыздан алынған гендерге байланысты. Мұрагерлік доңғалақты қайта ойлап табуға жол бермейді және прогресті жылдамдатады. OOP-де де солай. Біз бірнеше негізгі қасиеттері/мінез-құлықтары бар ата-аналық класс жасаймыз. Осы ата-анадан мұраланған барлық сыныптарда олардың ата-анасымен бірдей сипаттар/мінез-құлық болады. Дегенмен, мұраланған сыныптар көбірек қасиеттерге/мінез-құлыққа ие болуы немесе мінез-құлықтың орындалуын өзгертуі мүмкін. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } Жоғарыдағы мысалда ата-аналық сыныпта (WritingInstrument) «түс» сипаты және «жазу» әрекеті бар. Ұрпақ класы (тұтқа) жарияланған кезде, "түс" сипаты мен "жазу" әрекетін қайта жариялау қажет емес. Олар тұқым қуалаушылыққа байланысты «тұтқа» класында бар. Дегенмен, ұрпақ класы өзінің қосымша қасиеттерін/мінез-құлқын жариялай алады. Мұны іс жүзінде қалай пайдалана аламыз? Біз әзірлеушілер өте жалқаумыз. Біз бірдеңені қайта-қайта басып шығарғымыз келмейді. Бір codeтың бірнеше көшірмелерінің болуы келесі ойларға байланысты қабылданбайды:
Кодтың көшірмелері неғұрлым аз болса, соғұрлым оны сақтау оңайырақ.
Егер codeтың көп көшірмелері болмаса, онда бір жерде өзгеріс барлық жерде көрінеді.
Код неғұрлым аз болса, соғұрлым қателер аз болады.
Егер бір code көп жерде қолданылса, онда жалпылауға қол жеткізіледі.
Біз codeты жазуға назар аударамыз.
Біз сынақтарға назар аударамыз.
Java тіліндегі мұраға «кеңейтеді» және «іске асырады» кілт сөздері арқылы қол жеткізіледі. class WritingInstrument { } class Pen extends WritingInstrument { }
Полиморфизм
«Полиморфизм» сөзі екі сөзден шыққан: «Поли» , яғни. «көп» / «бірден көп» «морф» , яғни. «Пішін» Сөзбе-сөз «полиморфизм» сөзі an objectілердің жағдайларға байланысты әртүрлі тәсілдермен әрекет ету қабілетін білдіреді. Бағдарламалауда полиморфизм бірнеше жерде жүзеге асырылуы мүмкін:
Сабақтар
Әдістері
Операторлар
Жоғарыда айтылғандардың барлығы жағдайларға, мүмкін контекстке байланысты басқаша әрекет етуі мүмкін. Бұл пайдалы, өйткені клиентке (кітапханаларды пайдаланатын бағдарламашы) көптеген нәзіктіктерді білу қажет емес және қажетті функционалдылық контекстен қажетті ақпаратты таңдау арқылы жүзеге асырылады. 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(); // третий вызов } } Жоғарыдағы мысалда WritingObject бағдарламасында әдепкі іске асыру бар, ол ұрпақ сыныптары қалам және қалам арқылы кеңейтілген/қайта анықталған. write() әдісі Main класында үш рет шақырылады. Әр жолы әдіс қай нысанға шақырылатынына байланысты әртүрлі іске асыру шақырылады. Бұл жағдайда write() әдісі көптеген мінез-құлыққа ие, себебі ол полиморфты.
Инкапсуляция
Инкапсуляция бір бірлікте қатысты деректерді/функцияларды жинау ретінде анықталады. Бұл деректерге қол жеткізуді/өзгертуді жеңілдетуге көмектеседі. Мысалы, егер бізге берілген пайдаланушының барлық қасиеттерін басып шығару қажет болса, бізде келесі опциялар бар: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Біз барлық қасиеттерді қабылдайтын және оларды бірінен соң бірі басып шығаратын әдісті жасадық. Тізімдегі элементтер саны көбейген сайын дұрыс өрістерді анықтау мүмкін болмайды және бір өрісті қосу/жою әдіс қолтаңбасын өзгертеді. Сондықтан, жаңадан қосылған өрістерді қажет етпесе де, осы әдістің барлық пайдаланушыларын ауыстыруымыз керек. Кодты оқуға ыңғайлы ету және болашақ модификацияларды жеңілдету үшін біз сипаттарды сыныпқа инкапсуляциялап, оны ұжымдық нысанға айналдырамыз.Объекті class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} – айнымалылар мен байланысты әдістердің бағдарламалық құралы. Бағдарлама an objectілерін пайдаланып нақты дүние an objectілерін көрсетуге болады. Сіз нақты иттерді анимациялық бағдарламада немесе нақты велосипедті жаттығу велосипедінің ішіндегі бағдарламалық құрал нысаны ретінде елестете аласыз. OOP-те класс an objectілерді құруға, оларды бастапқы күймен (айнымалылармен) қамтамасыз ететін және мінез-құлықты (функциялар, әдістер) іске асыруға арналған кеңейтілетін үлгі (бағдарлама-code-үлгі) болып табылады. SOLID аббревиатурасын 2000 жылдардың басында Роберт Мартин атаған «алғашқы бес қағида» үшін Майкл Фэтер ойлап тапты. Қағидалардың мақсаты, бірге жүзеге асырылған кезде, бағдарламалаушының қолдау және кеңейту оңай жүйені жасау ықтималдығын арттыру. SOLID принциптері рефакторинг арқылы «шіріген» codeты жою үшін қажет бағдарлама әзірлеудегі нұсқаулар болып табылады, нәтижесінде code оңай оқылатын және кеңейтілетін болуы керек. Бұл ептілік және бейімделгіш бағдарламалау стратегиясының бөлігі.
Бірыңғай жауапкершілік қағидасы
OOP-те жалғыз жауапкершілік принципі әрбір сынып бағдарламамен қамтамасыз етілген функционалдылықтың бір бөлігіне жауапты болуы керек және бұл жауапкершілік осы сыныппен толығымен қамтылуы керек екенін айтады. Оның барлық функционалдығы осы жауапкершілікпен тығыз байланысты болуы керек.
Ашық/жабық принцип
OOP-те ашық/жабық принцип «бағдарламалық қамтамасыз ету нысандары (сыныптар, модульдер, әдістер және т.б.) кеңейтуге ашық, бірақ өзгертуге жабық болуы керек» деп көрсетеді. Басқаша айтқанда, нысан бастапқы codeты өзгертпестен оның әрекетін кеңейтуге рұқсат беруі керек.
Лисковтың алмастыру принципі
Ауыстырушылық - бұл OOP принципі. Онда, егер компьютерлік бағдарламадағы S T түрінің ішкі түрі болса, онда T типті an objectілер оларды өзгертпей S типті an objectілермен (яғни S типті an objectілерді T түріндегі an objectілермен ауыстыруға болады) ауыстыруға болатындай болуы керек. кез келген қажетті сипаттар бағдарламалары (дәлдік, тапсырманы орындау және т.б.).
Интерфейсті бөлу принципі
Интерфейсті бөлу принципі клиент бағдарламашыны өзі пайдаланbyteын әдістерге тәуелді болуға мәжбүрлемеу керектігін айтады. Бұл принцип бойынша клиент бағдарламашы тек өзіне қызықты әдістер туралы білуі үшін үлкен интерфейстерді кішірек және нақтырақ деп бөлу қажет. Интерфейсті ажырату принципінің мақсаты жүйені ажыратуды сақтау болып табылады, бұл қайта өңдеуді, өзгерістер енгізуді және қайта орналастыруды жеңілдетеді.
Тәуелділіктің инversion принципі
OOP-те тәуелділікті инversionлау принципі бағдарлама модульдері арасындағы ажыратудың белгілі бір түрін білдіреді. Осы принципті ұстана отырып, қолданба архитектурасын (саясат орнату) құрайтын жоғары деңгейлі модульдерден тәуелді төмен деңгейлі модульдерге орнатылған стандартты тәуелділік қатынастары инверттелген (кері), осылайша модификацияланған жоғары деңгейлі модульдер бағдарламаны іске асыру мәліметтерінен тәуелсіз болады. төмен деңгейлі модульдер. Бұл принцип былай дейді:
Жоғары деңгейлі модульдер төмен деңгейлі модульдерге тәуелді болмауы керек. Модульдердің екі түрі де абстракцияларға тәуелді болуы керек.
Абстракциялар іске асыру мәліметтеріне тәуелді болмауы керек. Мәліметтер абстракцияларға байланысты болуы керек.
Бұл принцип жоғары және төмен деңгейлі нысандар бірдей абстракцияларға тәуелді болуы керек деп айта отырып, адамдардың an objectіге бағытталған дизайн туралы ойлау тәсілін өзгертеді.
GRASP принциптері
Жалпы жауапкершілікті тағайындау бағдарламалық жасақтама үлгілері (GRASP) an objectіге бағытталған дизайндағы сыныптар мен нысандарға жауапкершіліктерді тағайындау бойынша нұсқаулар береді.
Контроллер
Контроллер үлгісі жүйе оқиғаларымен әрекеттесу жауапкершілігін бүкіл жүйені немесе пайдалану сценарийін көрсететін GUI емес сыныптарға тағайындайды. Контроллер:
Бұл пайдаланушымен тікелей әрекеттеспейтін және жүйелік оқиғаларды қабылдауға және оларға жауап беруге жауапты нысан.
Бір (немесе өзара байланысты) пайдалану жағдайларының барлық жүйелік оқиғаларымен жұмыс істеу үшін қолданылуы керек.
Бұл жүйе әрекеттерін басқаратын GUI артындағы бірінші нысан.
Ол жұмысты өзі орындаудың қажеті жоқ, оның міндеті - оқиғалар ағынын бақылау.
Жаратушы
Жасаушы класының міндеті - кейін пайдалану үшін нысандарды жасау және бастау. Ол инициализация параметрлерін, сондай-ақ қандай нысан жасалатынын біледі. Кейде жасаушылар класы an objectілерді белсенді түрде жасайды және оларды кэшке орналастырады және қажет болғанда бір дананы қамтамасыз етеді.
Жоғары когезия
Жоғары үйлесімділік – бағалау үлгісі, оның мақсаты an objectілерді бір нақты тапсырманы орындауға бағытталған, оңай басқарылатын және түсінілетіндей күйде сақтау. Жоғары муфта әдетте төмен муфтаны қолдау үшін пайдаланылады. Жоғары үйлесімділік берілген элементтің міндеттерінің нақты анықталғанын білдіреді (қатты байланысты және жоғары бағытталған). Бағдарламаны сыныптар мен ішкі жүйелерге бөлу жүйе қасиеттерінің бірігуін арттыратын әрекеттердің мысалы болып табылады. Бос байланыс, керісінше, элементте тым көп байланысты емес тапсырмалар бар жағдай. Бос байланысқан элементтерді түсіну қиын, қайта пайдалануға болады, ұстау қиын және өзгерту қиын.
Жанама
Айналмалы қиылыс үлгісі аралық нысанға олардың арасындағы өзара әрекеттесу жауапкершілігін тағайындау арқылы екі элемент арасындағы бос байланысты (және қайта пайдалануға жарамдылығын) сақтайды. Мысал ретінде Model-View-Controller (MVC) үлгісіндегі деректер (модель) мен оның дисплейі (көрініс) арасында делдал болу үшін контроллерді енгізу болып табылады.
Ақпараттық сарапшы
Ақпараттық сарапшы (сонымен қатар сарапшы немесе сарапшы қағидасы) – жауапкершілікті кімге тапсыру керектігін анықтау үшін қолданылатын принцип. Міндеттерге әдістер, есептелген өрістер және т.б. Жауапкершілікті тағайындау кезінде осы принципті қолдану кезінде келесі әрекеттер тізбегі негізгі тәсіл болып табылады: жауапкершілікті талдау, оны орындау үшін қажетті ақпаратты анықтау және ең соңында бұл ақпараттың қай жерде орналасқанын анықтау. Ақпараттық сарапшы принципін пайдалану оны орындау үшін ең көп ақпараты бар сыныпқа жауапкершілікті тағайындауға әкеледі.
Төмен муфта
Бос байланыстыру - жауапкершіліктерді қалай тағайындау керектігін көрсететін бағалау үлгісі: сыныптар арасындағы бос байланыс, біреуін өзгерту екіншісіне ең аз әсер етуі керек, қайта пайдалану мүмкіндігін арттырады.
Полиморфизм
Полиморфизмге сәйкес мінез-құлықтың түрге байланысты өзгеруі осы вариация болатын түрлерге тағайындалады. Бұған полиморфты операцияларды қолдану арқылы қол жеткізіледі.
Қорғалған вариациялар
Қорғалған өзгерістер үлгісі интерфейстегі тұрақсыздық фокусын орау және сол интерфейстің әртүрлі іске асыруларын жасау үшін полиморфизмді пайдалану арқылы элементтерді басқа элементтерге (нысандарға, жүйелерге, ішкі жүйелерге) өзгертулерден қорғайды.
Таза өндіріс
Таза конструкция проблемалық аймақтағы тұжырымдаманы көрсетпейтін сыныпты қамтиды және бос ілінісу, жоғары ілінісу, сондықтан максималды қайта пайдалану әлеуетіне қол жеткізу үшін арнайы әзірленген (Ақпараттық сарапшы үлгісі ұсынатын шешім бұған қол жеткізе алмайды). Мұндай класс әдетте доменге негізделген дизайнда «Қызмет» деп аталады.
Сын
Поток және т.б. зерттеулері OOP және proceduresалық тәсілдер арасында айтарлықтай айырмашылықтарды көрсетпеді.
OOP-ті басқа технологиялармен, әсіресе реляциялық технологиялармен сыни салыстыру, қатаң және жалпы қабылданған OOP анықтамасының болмауына байланысты қиын (Кристофер Дж. Дайт)
Басқа тілдермен салыстырғанда (LISP диалектілері, функционалды тілдер және т.б.) OOP тілдерінің бірегей артықшылығы жоқ және қажетсіз күрделілік тудырады. (Лоуренс Крубнер)
Мен an objectіге бағытталған бағдарламалауды техникалық тұрғыдан әлсіз деп санаймын. Ол бір типте өзгеретін интерфейстер тұрғысынан әлемді бөліктерге бөлуге тырысады. Нақты есептерді шешу үшін сізге көп сұрыпталған алгебралар қажет - көптеген түрлерге таралатын интерфейстер отбасылары. Мен an objectіге бағытталған бағдарламалауды философиялық тұрғыдан дұрыс емес деп санаймын. Ол барлық нәрсенің an objectі екенін айтады. Бұл шындық болса да, бұл өте қызық емес: бәрі an object деу - мүлде ештеңе айтпау. (Александр Степанов)
Ірі компаниялар арасында OOP танымалдығы «орташа бағдарламашылардың үлкен (және жиі өзгеретін) топтарына» байланысты. OOP енгізген тәртіп бағдарламашыға «тым көп зиян келтіруге» жол бермейді. (Пол Грэм)
Объектіге бағытталған бағдарламалау зат есімдерді бірінші орынға қояды. Неліктен мұндай шектен шыққан шараларға барып, сөздің бір бөлігін тұғырға қою керек? Неліктен бір ұғым екіншісінен басым болады? OOP үшін кенеттен етістіктердің біздің ойлауымыз үшін маңыздылығын азайтуы мүмкін емес. Бұл біртүрлі қисық көзқарас. (Стив Йегге)
Clojure жасаушы Рик Хики an objectілік жүйелерді нақты әлемнің өте жеңілдетілген үлгілері ретінде сипаттады. Ол OOP-тың уақытты дұрыс модельдей алмауын атап өтті, бұл бағдарламаларда көп ағынды тарату жиі кездесетін кезде үлкен проблемаларды тудырады. Эрик С. Рэймонд, Unix бағдарламашысы және ашық бастапқы бағдарламалық қамтамасыз етуді қорғаушы OOP «Бір шешім» деген мәлімдемені сынға алды және OOP ашықтыққа кедергі келтіретін көп деңгейлі бағдарламаларды қолдайтынын жазды. Қарама-қарсы көзқарас ретінде Рэймонд Unix және C мысалдарын келтірді.
GO TO FULL VERSION