Алуучу/Орнотуучулар. Evil. Жана мезгил

Макаланын автору Егор Бугаенко 19-сентябрь, 2014-жыл | Жарыяланган: Негизги Java Бул эски талкууну Аллен Холуб 2003-жылы өзүнүн атактуу макаласында баштаган, Эмне үчүн алуучу жана сетер ыкмалары жаман - алуучулар/сеттер анти-үлгү жана биз алардан качышыбыз керекпи же бул биз үчүнбү? Объектке багытталган программалоодо керек. Мен бул талкууга өзүмдүн эки центимди кошом. Төмөндөгү тексттин өзөгү мындай: алуучулар жана орнотуучулар жаман практика; аларды колдонгондордун эч кандай шылтоосу жок. Бирок, дагы бир жолу, түшүнбөстүккө жол бербөө үчүн, мен мүмкүн болгон жерде get/set колдонуудан качуу керек деп сунуш кылбайм. Жок. Мен айтып жатам, сиз аларды codeуңузга жакындаткан жоксуз . Бул билдирүүгө кандай карайсыз? Сиздин көңүл бурууңузга татыктуубу? Сиз 15 жылдан бери get/set үлгүсүн колдонуп жатасызбы жана сиз Java архитекторусузбу? А сен чоочун бирөөнүн бул куру сөздү уккуң да келбейт? Мейли... Сиздин сезимдериңизди түшүнөм. Дэвид Уэсттин "Объекттик ой жүгүртүү" китебин көргөнгө чейин мен да ошондой сезимде болдум - бул мен окуган an objectке багытталган программалоо боюнча эң мыкты китеп. Андыктан сураныч. Тынчтанып, эмнени түшүндүргөнү жатканымды түшүнүүгө аракет кыл. Талаш-тартыштын предмети Объектке багытталган дүйнөдө "аксессорлорго" (алуучу жана орнотуучулардын башка аталышы) каршы бир нече аргументтер бар. Жана алардын баары абдан туура аргументтер. Келгиле, аларды тез карап көрөлү. Сура, Айтпа : Аллен Холуб мындай дейт: "Жумуш жасоо үчүн керектүү маалыматты сурабаңыз; ошол маалыматка ээ болгон уюмдан бул ишти сиз үчүн "суроо"." Бузулган инкапсуляция принциби : Объектти башка an objectтер бөлүп алса болот, анткени алар орнотуучулар аркылуу кандайдыр бир маалыматты an objectке киргизе алышат. Объект жөн гана өзүнүн абалын жетиштүү түрдө коопсуз капсулдай алbyte, анткени ал абалды каалаган адам өзгөртө алат. Ишке ашыруу чоо-жайы ачылды : Эгер сиз башка an objectтен бир an objectти ала алсаңыз, анда биз биринчи an objectтин ишке ашыруу деталдарына өтө көп таянып жатабыз. Эгер эртең ал өзгөрсө (мисалы, натыйжанын түрү), анда биз codeду өзгөртүүгө туура келет. Жогорудагы негиздемелердин баары, албетте, акылга сыярлык, бирок бул эң маанилүү нерсени өткөрүп жиберет. Негизги жаңылыш түшүнүк Көпчүлүк программисттер an objectти методдору бар маалымат структурасы деп эсептешет. Мен Божидар Божановдун макаласын келтирейин: Алуучу-лар менен сетирчилер жаман эмес. Бирок алгычтар жана орнотуучулар түзүлгөн an objectтердин көбү жөн гана маалыматтарды камтыйт. Бул туура эмес түшүнүк чоң түшүнбөстүктүн натыйжасы! Объекттер "маалыматтарды гана сактаbyte". Объекттер тиркелген методдору бар маалымат структуралары эмес. Бул "маалыматтарды сактоо" түшүнүгү an objectиге багытталган программалоо жана proceduresалык тилдерден, өзгөчө C жана COBOL тилдеринен келип чыккан. Мен дагы бир жолу кайталайм: an object бул жөн гана маалымат элементтеринин жана аларды башкарган функциялардын жыйындысы эмес. Объект маалымат an objectи эмес. Анда эмне? Топ жана ит Чыныгы an objectиге багытталган программалоодо an objectтер сиз жана мен сыяктуу тирүү жандыктар. Алар өздөрүнүн жүрүм-туруму, касиеттери жана жашоо цикли бар тирүү организмдер. Тирүү организмде сетер болушу мүмкүнбү? Итке топту («коюу») тиркөө мүмкүнбү? Ойлобойм. Бирок төмөндөгү codeдун бөлүгү дал ушундай кылат:

Dog dog = new Dog();
dog.setBall(new Ball());

Анда кандайча жагасың? Сиз иттен топту ала аласызбы («ал»)? Мейли, сиз кыла аласыз деп коёлу. Эгер ал жеген болсо, сен ага операция жасадың. Бул учурда, ооба, сиз иттен топту ала аласыз («ал»). Мен дал ушул нерсени айтып жатам:

Dog dog = new Dog();
Ball ball = dog.getBall();

Же андан да күлкүлүү мисал:

Dog dog = new Dog();
dog.setWeight("23kg");

Муну чыныгы жашоодо элестете аласызбы? Күн сайын жазып жаткандай сезилеби? Ооба болсо, анда сиз proceduresалык программистсиз. Жөн эле моюнга ал. Бул жерде Дэвид Уэст өзүнүн китебинин 30-бетинде мындай дейт: Ийгorктүү proceduresалык иштеп чыгуучуну ийгorктүү an objectивдүү иштеп чыгуучуга айландыруунун биринчи кадамы - бул лоботомия. Лоботомия керекпи? Мага ал сөзсүз керек болчу, мен аны Уэсттин "Объекттик ой жүгүртүү" китебин окуп жатып алдым. Объективдүү ой жүгүртүү Объект сыяктуу ойлоно баштасаңыз, бул ыкмалардын атын дароо өзгөртөсүз. Бул жерде сиз ала аласыз:

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

Азыр итти бизден топту алып, сурасак кайтарып бере турган чыныгы жаныбар катары карайбыз. Болгондо да, ит NULL кайтара алbyte деп белгилеймин. Иттер NULL деген эмне экенин бorшпейт! Объективдүү ой жүгүртүү (ой жүгүртүү) codeуңуздан NULL шилтемелерин дароо алып салат. "Ванда деп аталган балык" (1988) Чарльз Кричтон Мындан тышкары, an objectивдүү ой жүгүртүү биздин мисалдагы "иттин салмагы" сыяктуу an objectтин өзгөрбөстүгүнө алып келет. Сиз codeду мындайча кайра жазасыз:

Dog dog = new Dog("23kg");
int weight = dog.weight();

Ит - бул өзгөрүлгүс тирүү организм, ал сырттан эч кимге салмагын, өлчөмүн, атын ж.б. өзгөртүүгө жол бербейт. Ал суроо-талабы боюнча салмагын же аты-жөнүн "айтып бере алат". Объекттин айрым "ички" касиеттери боюнча сурамдарды ачыкка чыгарган коомдук методдордо эч кандай ката жок. Бирок бул ыкмалар "алуучу" эмес жана алар эч качан "ал" префиксин албашы керек. Биз иттен “чыкпайбыз”. Биз анын атын түшүнбөйбүз. Биз анын атын айтып берүүсүн суранабыз. Силер айырманы көрүп жатасызбы? Биз бул жерде семантика жөнүндө да сөз кылбайбыз. Биз программалоого proceduresалык мамилени an objectиге багытталгандан айырмалайбыз. Процедуралык программалоодо биз маалыматтар менен иштейбиз, аны манипуляциялайбыз, алабыз, орнотобуз жана керек болсо өчүрөбүз. Биз жооптуубуз жана маалыматтар жөн гана пассивдүү компонент. Ит биз үчүн эч нерсе эмес - ал жөн гана "маалыматтарды камтыйт". Анын өзүнүн жашоосу жок. Биз андан керектүү нерселердин бардыгын эркин ала алабыз (алабыз) жана ага каалаган маалыматтарды сала алабыз (коюбуз). C, COBOL, Паскаль жана башка proceduresалык тилдер ушундай иштейт (иштеген). Ал эми an objectиге багытталган дүйнөдө абал таптакыр карама-каршы. Бул жерде биз an objectтерди тирүү организмдер катары, алардын туулган датасы жана өлгөн учуру, кааласаңыз, өзүнүн мүнөзү жана адаттары менен карайбыз. Биз иттен бизге маалымат берүүнү сурансак болот (мисалы, анын салмагы) жана ал бизге маалыматты кайтарып бере алат. Бирок дайыма ит активдүү компоненти экенин унутпа. Ал өтүнүчтөн кийин эмне болорун чечет. Мына ошондуктан an objectтин методдорунун топтом же алуу менен башталышы таптакыр туура эмес. Бул көп адамдар ойлогондой, капсулацияны бузуу жөнүндө да эмес. Бул же сиз an object сыяктуу ойлонуп жатканыңыз же дагы эле Java синтаксиси менен COBOL жазып жатканыңыз жөнүндө. PS . Ооба, сиз: "JavaBeans, JPA, JAXB жана башка көптөгөн Java API'лери жөнүндө эмне айтууга болот?" Аксессорлорду түзүүнү жеңилдеткен Ruby'де орнотулган функция жөнүндө эмне айтууга болот? Мейли, сага эмне дейм... сенин жолуң жок. Чыныгы an objectтердин керемет дүйнөсүн түшүнүп, кабыл алгандан көрө, proceduresалык COBOLдун примитивдүү дүйнөсүндө калуу алда канча оңой. P.P.S. _ Мен айтууну унутуп калдым, ооба, сетер аркылуу көз карандылыкты киргизүү да коркунучтуу анти-үлгү. Бирок бул тууралуу кийинки постто! Оригиналдуу макала