Котормочудан: Тилекке каршы, мен англисче көп окусам да, англис тorнен которууда олуттуу тажрыйбам жок. Бирок окуу менен которуу эки башка нерсе экен. Ошондой эле, тилекке каршы, менде олуттуу программалоо тажрыйбасы жок (мен жакында эле Spring MVC жана Hibernateде жөнөкөй веб тиркемесин жасадым). Демек, котормо болушу мүмкүн болгонго караганда алда канча начар болуп чыкты. Мен макалада келтирилген codeдуу мисалдарды бир аз оңдоого эркиндик бердим, анткени алар Java тorндеги ат коюу конвенцияларына туура келбейт. Балким, кээ бир калыптардын атын которуу жарабай калгандыр (мындай котормо анчалык деле түшүнүк бербейт), бирок мен мунун азыраак жамандыгы деп ойлогом. «Жогорку биримдиктин» котормосу катары «жогорку когезия» жөнүндө өзүнчө сөз кылуу керек. Мен макулмун, мыкты котормо эмес. Бирок "күчтүү байланыш" - "жогорку туташуу" (дагы бир маанилүү түшүнүк) жана "ырааттуулук" бул жерде ылайыктуу болушу күмөн. Мен сынга ачыкмын жана макалага кандай гана формада болбосун сын-пикирлерди ыраазычылык менен кабыл алам. Объектке багытталган программалоо – бул программа реалдуу дүйнөдөгү an objectтерге туура келген компоненттерден турган программалоонун стor.Ар кандай реалдуу an objectтин кээ бир касиеттери (убакыттын өтүшү менен өзгөрүшү мүмкүн же өзгөрбөшү мүмкүн) жана жүрүм-туруму (алар же өзгөрбөшү мүмкүн) болот. башкаларга жараша өзгөрөт). Мисалы, карандаш төмөнкү касиеттерге ээ болгон чыныгы дүйнө an objectиси:
Ал кызыл (бул убакыттын өтүшү менен өзгөрбөйт).
Анын узундугу азыр 10 сантиметр (карандаш курчуса, бул өзгөрүшү мүмкүн).
Жана анын төмөнкү жүрүм-туруму бар:
Туура колдонулса из калтырат.
Из басымга жараша ар кандай болушу мүмкүн (тышкы факторлорго жараша).
Анын узундугу курчуган сайын кыскарат (туруктуу жүрүм-турум).
Бул мисалдагыдай эле, реалдуу дүйнө an objectтери көптөгөн касиеттерге ээ болушу мүмкүн, бирок программаларды жазууда биз керектүү касиеттерди гана эске алабыз. Объектке багытталган программалоонун өзүнүн артыкчылыктары бар. Мисалы, реалдуу an object менен программанын ортосундагы байланышты күтүлгөн жол менен орнотууну жеңилдетет. Бул чындап эле жардам берет, анткени колдонмо өсүп, көптөгөн an objectтер бири-бири менен иштешет. Бул an objectивдүү дүйнөнүн ичинде милдеттерди бөлүштүрүүгө жардам берет, бул колдонмо аркылуу ой жүгүртүүгө басым жасоого мүмкүндүк берет. OOP (Object Oriented Programming) менен байланышкан дагы бир маанилүү өзгөчөлүк - бул an objectтердин классификациясы. Дүйнө (реалдуу/виртуалдык) an objectтерге толгондуктан, аларды өз алдынча башкаруу кыйын. Бизге кара карандаш сыяктуу ар кандай an objectтерди жана алардын касиеттерин байланыштырууга жардам бере турган бул an objectтерди классификациялоонун ыкмасы керек. Мурунку мисалда колдонулса айырмаланбай турган (ошол эле?) болмок, бирок бул башка an object. Бирок экөө тең карандаш болгондуктан, алар бир класска кирет "Карандаш". Ал эми карандашка абдан окшош калем башка класска кирет. Бирок, калем жана карандаш экөө тең "Жазуу куралдары". Объектке багытталган программалоо төмөнкү принциптерге ээ:
Абстракция
Абстракция окуяларга караганда идеялар менен өз ара аракеттенүү сапаты же башкача айтканда, өкүлчүлүк сапаттардан эркиндик катары аныкталат . Бул программисттерге кантип программалоо керек экенине эмес, эмнени программалоого көңүл бурууга мүмкүндүк берет . Абстракцияны биз функционалдык мүмкүнчүлүктөрдү камсыз кылган келишим катары кароого болот. Бул концепцияны колдонууда ишке ашыруунун деталдары жашырылышы мүмкүн. Мисалы, бизге жаза турган класс керек болсо, анда биз анын "жазуу" ыкмасы бар экенине ынанышыбыз керек, биз эмне кылдык? Биз абстракттуу болгон жогорку деңгээлдеги классты иштеп чыктык, башкача айтканда, ал бизге кандай функция керек экенин билет, бирок аны кантип ишке ашыруу бул класстын алкагына кирбейт. Бул көптөгөн артыкчылыктарды сунуш кылат: abstract class writer { write (); }
Биз тышкы субъекттерге зарыл болгон минималдуу маалыматты ачып беребиз, бул бизге программа аркылуу ой жүгүртүүгө көңүл бурууга мүмкүндүк берет (бул багытталган ой жүгүртүүгө мүмкүндүк берет), башаламандыктан качууга жана күтүлбөгөн убадаларды берүүдөн качууга мүмкүндүк берет.
Биз келечектеги жакшыртууларга орун калтырбайбыз, эгерде ишке ашыруунун деталдары ачылса, мүмкүн эмес.
Мурас
"Мурас" жалпы англис тorнде "кабыл алуу жана өткөрүп берүү" дегенди билдирет. Бул сөз биздин маданиятта көптөн бери бар. Ата-бабалар жерди мээнет менен алып, балдарына мураска калтырышкан, жада калса табият мураска да ыктайт. Дененин бардык касиеттери, мисалы, бою, теринин/көздүн/чачтын түсү ж.б. ата-энебизден тукум кууп өткөн гендерге көз каранды. Мурас дөңгөлөктү кайра ойлоп табууга жол бербейт жана прогрессти тездетет. 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 классында үч жолу чакырылат. Ар бир жолу методдун кайсы an objectиге чакырылганына жараша башка ишке ашыруу чакырылат. Бул учурда, write() ыкмасы жүрүм-турумдун көп түрлөрүнө ээ, анткени ал полиморфтук.
Инкапсуляция
Инкапсуляция тиешелүү маалыматтарды/функцияларды бир бирдикте чогултуу катары аныкталат. Бул маалыматтарга жетүү/өзгөртүү жардам берет. Мисалы, эгер бизге берилген колдонуучу ээ болгон бардык касиеттерди басып чыгаруу керек болсо, бизде төмөнкү варианттар бар: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Биз бардык касиеттерди алып, аларды биринин артынан бири басып чыгарган ыкманы түздүк. Тизмедеги элементтердин саны көбөйгөн сайын туура талааларды аныктоо мүмкүн болбой калат жана бир талааны кошуу/алып салуу методдун кол тамгасын өзгөртөт. Ошондуктан, биз бул ыкманын бардык колдонуучуларын алмаштырышыбыз керек, алар жакында кошулган талааларга муктаж болбосо да. Кодду окууга ыңгайлуу кылуу жана келечектеги өзгөртүүлөрдү жеңилдетүү үчүн, биз класстын касиеттерин капсулдап, аны жамааттык an objectке айландырабыз.Объект class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} бул өзгөрмөлөрдүн жана ага байланыштуу методдордун программалык пакети. Сиз программа an objectилерин колдонуу менен реалдуу дүйнө an objectтерин көрсөтө аласыз. Сиз анимация программасында чыныгы иттерди, же чыныгы велосипедди тренажердун ичиндеги программалык an object катары элестете аласыз. OOPде класс an objectтерди түзүү, аларга баштапкы абалды (өзгөрмөлөрдү) берүү жана жүрүм-турумду (функцияларды, методдорду) ишке ашыруу үчүн кеңейтилүүчү шаблон (программа-code-шаблон) болуп саналат. SOLID кыскартылышы 2000-жылдардын башында Роберт Мартин тарабынан айтылган "биринчи беш принцип" үчүн Майкл Фэтер тарабынан иштелип чыккан. Принциптердин максаты, чогуу ишке ашырылганда, программист тейлөө жана кеңейтүү оңой болгон системаны түзүү ыктымалдыгын жогорулатуу. SOLID принциптери программаны иштеп чыгуудагы көрсөтмөлөр болуп саналат, алар рефакторинг аркылуу “чириген” codeду жок кылуу үчүн зарыл, анын натыйжасында code оңой окула турган жана кеңейтилүүчү болуп калышы керек. Бул ийкемдүү жана ийкемдүү программалоо стратегиясынын бир бөлүгү.
Бирдиктүү жоопкерчorк принциби
OOPдо бирдиктүү жоопкерчorк принциби ар бир класс программа тарабынан камсыз кылынган функциялардын бир бөлүгү үчүн жооптуу болушу керек жана бул жоопкерчorк толугу менен ошол класс тарабынан камтылууга тийиш деп айтылат. Анын бардык функциялары ушул жоопкерчorк менен тыгыз байланышта болушу керек.
Ачык/жабык принциби
OOPде ачык/жабык принцип "программалык камсыздоо an objectтери (класстар, модулдар, методдор ж.б.) кеңейтүү үчүн ачык, бирок өзгөртүү үчүн жабык болушу керек" деп айтылат. Башка сөз менен айтканда, an object баштапкы codeду өзгөртпөстөн, анын жүрүм-турумун кеңейтүүгө уруксат бериши керек.
Лисковдун алмаштыруу принциби
Алмаштыруучулук - бул OOPдогу принцип. Анда айтылгандай, эгерде компьютердик программадагы S T түрүнүн түрү болсо, анда T түрүндөгү an objectтер өзгөрүүсүз S тибиндеги an objectтерге (б.а. S тибиндеги an objectтер T тибиндеги an objectтерге алмаштырылышы мүмкүн) болушу керек. бардык талап кылынган касиеттер программалары (тактык, тапшырманы аткаруу, ж.б.).
Interface Segregation Principe
Интерфейстин бөлүү принциби кардар программисти ал колдонбогон методдорго көз каранды болууга мажбурлабашы керек деп айтылат. Бул принцип боюнча, кардар программист өзү үчүн кызыктуу болгон ыкмалар жөнүндө гана бorши үчүн, чоң интерфейстерди кичирээк жана конкреттүү деп бөлүү керек. Интерфейстин ажыратуу принцибинин максаты - системаны ажыратуу, бул рефакторлорду, өзгөртүүлөрдү киргизүүнү жана кайра жайгаштырууну жеңилдетет.
Көз карандылыктын инversion принциби
OOPде көз карандылыктын инversion принциби программалык модулдардын ортосундагы ажыратуунун белгилүү бир формасын билдирет. Бул принципти сактоо менен, колдонмо архитектурасын түзүүчү жогорку деңгээлдеги модулдардан (саясатты орнотуу) көз каранды төмөнкү деңгээлдеги модулдарга орнотулган стандарттык көз карандылык мамилелери тескериленет (тескери), модификацияланган жогорку деңгээлдеги модулдар төмөнкү деңгээлдеги модулдар. Бул принцип мындай дейт:
Жогорку деңгээлдеги модулдар төмөнкү деңгээлдеги модулдардан көз каранды болбошу керек. Модулдардын эки түрү тең абстракциялардан көз каранды болушу керек.
Абстракциялар ишке ашыруунун деталдарынан көз каранды болбошу керек. Детальдар абстракцияларга көз каранды болушу керек.
Принцип жогорку жана төмөнкү деңгээлдеги an objectтер бирдей абстракцияларга көз каранды болушу керек деп айтуу менен an objectке багытталган дизайн жөнүндө адамдардын ой жүгүртүүсүн тескеритет.
GRASP принциптери
Жалпы жоопкерчorкти тапшыруу программалык үлгүлөрү (GRASP) an objectке багытталган дизайндагы класстарга жана an objectтерге жоопкерчorктерди ыйгаруу боюнча көрсөтмөлөрдү берет.
Controller
Controller үлгүсү тутум окуялары менен өз ара аракеттенүү үчүн жоопкерчorкти бүт системаны же колдонуу сценарийин чагылдырган GUI эмес класстарга дайындайт. Контроллер:
Бул колдонуучу менен түздөн-түз өз ара аракеттенбеген an object жана системанын окуяларын кабыл алуу жана аларга жооп берүү үчүн жооптуу.
Бир (же бир нече өз ара байланыштуу) колдонуу учурларынын бардык тутум окуялары менен күрөшүү үчүн колдонулушу керек.
Бул системанын операцияларын башкарган GUI артындагы биринчи an object.
Ал ишти өзү жасашы керек эмес, анын милдети окуялардын агымын көзөмөлдөө.
Жаратуучу
Жаратуучу класстын милдети an objectтерди түзүү жана кийинки колдонуу үчүн баштоо. Ал инициализациянын параметрлерин, ошондой эле кандай an object түзүлөрүн билет. Кээде жаратуучу класс an objectтерди активдүү жаратат жана аларды кэшке жайгаштырат жана керек болгондо бир нусканы берет.
Жогорку Когезия
Жогорку когезия – баа берүүчү үлгү, анын максаты an objectтерди бир так тапшырманы аткарууга багытталган, оңой башкарылуучу жана түшүнө тургандай абалда сактоо болуп саналат. High Coupling, адатта, төмөн Coupling колдоо үчүн колдонулат. Жогорку ырааттуулук берилген элементтин милдеттери так аныкталгандыгын билдирет (катуу байланышкан жана жогорку багытталган). Программаны класстарга жана подсистемаларга бөлүү системанын касиеттеринин биригүүсүн жогорулатуучу аракеттердин мисалы болуп саналат. Башка жагынан алганда, бош байланыш - бул элементтин өтө көп байланышпаган милдеттери бар кырдаал. Бошоң бириктирилген элементтерди түшүнүү кыйын, кайра колдонууга болот, сактоо кыйын жана өзгөртүү кыйын.
кыйыр
Айланма үлгүсү эки элементтин ортосундагы бош байланышты (жана кайра колдонууга мүмкүндүгүн) алардын ортосундагы өз ара аракеттенүү үчүн жоопкерчorкти ортодогу an objectке жүктөйт. Мисал катары, модель-көрүнүш-контроллер (MVC) үлгүсүндөгү маалыматтар (модел) менен анын дисплейи (көрүү) ортосунда ортомчулук кылуу үчүн контроллердин киргизorши болуп саналат.
Маалымат боюнча эксперт
Маалымат Эксперти (ошондой эле Эксперт же Эксперттик Принцип) жоопкерчorкти кимге өткөрүп берүүнү аныктоо үчүн колдонулган принцип. Милдеттерге ыкмалар, эсептелген талаалар ж.б. Жоопкерчorкти дайындоодо бул принципти колдонууда негизги мамиле төмөнкүдөй иш-аракеттердин ырааттуулугу болуп саналат: жоопкерчorкти талдоо, аны аткаруу үчүн зарыл болгон маалыматты аныктоо жана акырында бул маалымат кайда жайгашканын аныктоо. Маалымат Эксперти принцибинин колдонулушу аны аткаруу үчүн эң көп маалыматы бар класска жоопкерчorкти ыйгарууга алып келет.
Төмөн бириктирүү
Жоопкерчorкти кантип бөлүштүрүүнү аныктаган баалоо үлгүсү: класстар ортосундагы бош байланыш, бирин алмаштыруу экинчисине минималдуу таасир тийгизиши керек, кайра колдонууга мүмкүндүктү жогорулатуу.
Полиморфизм
Полиморфизмге ылайык, жүрүм-турумдун түрүнө жараша өзгөрүшү бул вариация болгон типтерге ыйгарылат. Бул полиморфтук операцияларды колдонуу менен ишке ашат.
Корголгон вариациялар
Корголгон өзгөртүүлөр үлгүсү элементтерди башка элементтерге (an objectтерге, системаларга, подсистемаларга) өзгөрүүдөн коргойт, ал интерфейстин туруксуздугунун фокусун ороп, ал интерфейстин ар кандай ишке ашырууларын түзүү үчүн полиморфизмди колдонот.
Таза Фабрика
Таза конструкция көйгөй чөйрөсүндөгү концепцияны билдирбеген классты камтыйт жана бош туташтырууга, жогорку туташтырууга, демек максималдуу кайра колдонуу потенциалына жетүү үчүн атайын иштелип чыккан (Маалымат Эксперти үлгүсү сунуш кылган чечим буга жетишпейт). Мындай класс, адатта, Доменге негизделген дизайнда "Кызмат" деп аталат.
Сын
Поток ж.
ООПту башка технологиялар менен, айрыкча реляциялык технологиялар менен критикалык салыштыруу, катаал жана кеңири кабыл алынган OOP аныктамасынын жоктугунан улам кыйын (Christopher J. Date)
Башка тилдерге салыштырмалуу (LISP диалектилери, функционалдык тилдер, ж. (Лоуренс Крубнер)
Мен an objectиге багытталган программалоону техникалык жактан начар деп эсептейм. Ал бир типте өзгөрүп турган интерфейстер боюнча дүйнөнү бөлүктөргө бөлүүгө аракет кылат. Чыныгы көйгөйлөрдү чечүү үчүн сизге көп сорттуу алгебра керек - көптөгөн типтерге жайылган интерфейстердин үй-бүлөлөрү. Мен an objectиге багытталган программалоону философиялык жактан туура эмес деп эсептейм. Анда баары бир an object экени айтылат. Бул чын болсо да, бул абдан кызык эмес: бардыгын an object деп айтуу - такыр эч нерсе деп айтуу. (Александр Степанов)
ООПтун ири компаниялардын арасында популярдуулугу "орточо программисттердин чоң (жана тез-тез алмашып туруучу) топторуна" байланыштуу. OOP тарабынан коюлган тартип программистке "өтө көп зыян келтирүүгө" жол бербейт. (Пол Грэм)
Объектке багытталган программалоо зат атоочторду биринчи орунга коёт. Эмне үчүн мындай ашынган чараларга барып, сөздүн бир бөлүгүн постаментке коюу керек? Эмне үчүн бир түшүнүк экинчисинен артыкчылыкка ээ? OOP күтүлбөгөн жерден этиштердин биздин ой жүгүртүүбүз үчүн анча маанилүү эмес болушу мүмкүн эмес. Бул кызыктай бурмаланган көз караш. (Стив Йегге)
Clojure жаратуучусу Рик Хики an objectorк системаларды реалдуу дүйнөнүн өтө жөнөкөйлөштүрүлгөн моделдери катары сүрөттөгөн. Ал OOPтин убакытты туура моделдей албагандыгын баса белгиледи, бул көп агым программаларда кеңири таралганда чоң көйгөйлөрдү жаратат. Эрик С. Рэймонд, Unix программисти жана ачык булактуу программалык камсыздоонун жактоочусу, OOP "Бир чечим" деген дооматты сынга алып, OOP ачык-айкындуулукка тоскоол болгон көп катмарлуу программаларды кубаттай турганын жазган. Карама-каршы ыкма катары Рэймонд Unix жана C мисалдарын келтирди.
GO TO FULL VERSION