Қабылдағыштар/Орнатқыштар. Жауыз. Және кезең

Мақала Егор Бугаенко 19 қыркүйек 2014 жыл | Жарияланған: Негізгі Java Бұл ескі пікірталасты Аллен Холуб өзінің 2003 жылы атақты мақаласында бастады, « Гетер және орнату әдістері неге жаман ? an objectіге бағытталған бағдарламалауда қажет. Мен бұл талқылауға екі центімді қосамын. Төмендегі мәтіннің мәні мынада: алушылар мен орнатушылар жаман тәжірибе; оларды пайдаланатындардың ешқандай ақтауы жоқ. Бірақ тағы да, түсінбеушілікке жол бермеу үшін мен мүмкіндігінше get/set пайдаланудан аулақ болу керек деп ұсынбаймын. Жоқ. Мен оларды codeыңызға жақындатпағаныңызды айтамын . Бұл мәлімдеме туралы не ойлайсыз? Назарларыңызға лайық па? Сіз 15 жыл бойы get/set үлгісін пайдаланып жүрсіз бе және сіз Java-ның құрметті сәулетшісісіз бе? Ал сіз бейтаныс адамнан бұл бос сөзді тыңдағыңыз да келмейді ме? Жарайды... Сенің сезімдеріңді түсінемін. Мен Дэвид Уэсттің «Объектті ойлау» кітабын алғанша, мен де солай сезіндім – бұл мен бұрын-соңды оқыған an objectіге бағытталған бағдарламалау бойынша ең жақсы кітап. Сондықтан өтінемін. Тыныштанып, нені түсіндіріп жатқанымды түсінуге тырысыңыз. Дау тақырыбы Объектіге бағытталған әлемде "акцессорларға" (алушылардың және орнатушылардың басқа атауы) қарсы бірнеше дәлелдер бар. Және олардың барлығы өте дұрыс дәлелдер. Оларды жылдам қарастырайық. Сұраңыз, айтпаңыз : Аллен Холуб былай дейді: «Жұмысты орындау үшін қажет ақпаратты сұрамаңыз; сол ақпараты бар ұйымнан тапсырманы орындау үшін «сұраңыз». Бұзылған инкапсуляция принципі : нысанды басқа нысандар бөлектеуге болады, себебі олар орнатушылар арқылы нысанға кез келген деректерді ендіре алады. Нысан өз күйін жеткілікті қауіпсіз инкапсуляциялай алмайды, себебі кез келген адам бұл күйді өзгерте алады. Іске асыру мәліметтері ашылды : Егер сіз бір нысанды басқа нысаннан ала алсаңыз, онда біз бірінші нысанның іске асыру мәліметтеріне тым көп сенеміз. Егер ертең ол өзгерсе (мысалы, нәтиже түрі), онда codeты өзгертуге тура келеді. Жоғарыда аталған негіздемелердің барлығы сөзсіз мағынасы бар, бірақ бұл ең маңызды нәрсені жіберіп алады. Негізгі қате түсінік Көптеген бағдарламашылар нысанды әдістері бар деректер құрылымы деп санайды. Мен Божидар Божановтың мақаласын келтіремін: Алушылар мен қондырғыштар жаман емес. Бірақ қабылдағыштар мен орнатушылар жасалған нысандардың көпшілігінде жай деректер болады. Бұл қате түсінік үлкен түсінбеушіліктің нәтижесі! Нысандар «тек деректерді сақтамайды». Нысандар әдістері қосылған деректер құрылымдары емес. Бұл «деректерді сақтау» ұғымы an objectіге бағытталған бағдарламалау және proceduresалық тілдерден, әсіресе C және COBOL тілдерінен шыққан. Мен тағы да қайталаймын: нысан жай ғана деректер элементтері мен оларды басқаратын функциялардың жиынтығы емес. Нысан деректер нысаны емес. Сонда ше? Доп және ит Шынайы 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-бетінде былай дейді: Табысты proceduresалық әзірлеушіні табысты an objectивті әзірлеушіге айналдырудың бірінші қадамы лоботомия болып табылады. Сізге лоботомия қажет пе? Маған бұл сөзсіз керек еді, мен оны Уэсттің «Объектті ойлау» кітабын оқып отырып алдым. Объективті ойлау Нысан сияқты ойлауды бастаңыз және сіз бұл әдістердің атын бірден өзгертесіз. Мынаны алуыңыз мүмкін:

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

Енді біз итті бізден допты алатын, сұрасақ қайтара алатын нағыз жануар деп қараймыз. Тек жағдайда, иттің NULL мәнін қайтара алмайтынын ескертемін. Иттер NULL не екенін білмейді! Объективті ойлау (ойлау) сіздің 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 сияқты ойлайсыз немесе әлі де Java синтаксисі бар COBOL жазып жатырсыз. PS . Иә, сіз: «JavaBeans, JPA, JAXB және алу/жинақтауға тәуелді басқа көптеген Java API интерфейстері туралы не деуге болады?» Аксессуарларды жасауды жеңілдететін Ruby-дегі кірістірілген функция туралы не деуге болады? Жарайды, саған не айтамын... жолың болмай қалды. Нақты an objectілердің ғажайып әлемін түсінуге және қабылдауға қарағанда, proceduresалық COBOL-тың қарабайыр әлемінде қалу әлдеқайда оңай. P.P.S. _ Мен айтуды ұмытып кеттім, иә, тәуелділіктерді орнатушы арқылы кірістіру де қорқынышты анти-үлгі. Бірақ бұл туралы толығырақ келесі постта! Түпнұсқа мақала