Getters/Setters. kasamaan. At period

Artikulo ni Egor Bugaenko Setyembre 19, 2014 | Nai-post sa: Core Java Ang matandang debateng ito ay sinimulan ni Allen Holub sa kanyang sikat na artikulo, noong 2003, Bakit masama ang mga pamamaraan ng getter at setter - ang mga getter/setters ba ay isang anti-pattern at dapat ba nating iwasan ang mga ito, o ito ba ay isang bagay na tayo' re bound to have?kailangan sa object-oriented programming. Idaragdag ko ang aking dalawang sentimo sa talakayang ito. Ang diwa ng teksto sa ibaba ay ito: ang mga getter at setter ay masamang gawi; ang mga gumagamit nito ay walang dahilan. Ngunit muli, upang maiwasan ang hindi pagkakaunawaan, hindi ko iminumungkahi na ang paggamit ng get/set ay dapat iwasan hangga't maaari. Hindi. Sinasabi ko na hindi mo man lang sila pinalapit sa iyong code . Ano sa palagay mo ang pahayag na ito? Karapat-dapat sa iyong pansin? Ginagamit mo na ba ang get/set pattern sa loob ng 15 taon at ikaw ba ay isang iginagalang na arkitekto ng Java? At ayaw mong makinig sa kalokohang ito mula sa isang estranghero? Well... I understand your feelings. Naramdaman ko ang parehong paraan hanggang sa napunta ako sa libro ni David West na "Object Thinking" - ito ang pinakamahusay na libro sa object-oriented programming na nabasa ko. Kaya pakiusap. Huminahon at subukang unawain kung ano ang sinusubukan kong ipaliwanag. Paksa ng Kontrobersya Mayroong ilang mga argumento laban sa "mga accessor" (isa pang pangalan para sa mga getter at setter) sa object-oriented na mundo. At lahat sila ay napakatamang mga argumento. Tingnan natin ang mga ito nang mabilis. Magtanong, Huwag Sabihin : Sabi ni Allen Holub, "Huwag humingi ng impormasyong kailangan mo para gumawa ng trabaho; 'magtanong' sa entity na mayroong impormasyong iyon na gawin ang trabaho para sa iyo." Nilabag na Prinsipyo ng Encapsulation : Maaaring paghiwalayin ang isang object ng iba pang mga object dahil nagagawa nilang mag-embed ng anumang data sa object, sa pamamagitan ng mga setter. Ang isang bagay ay hindi maaaring ma-encapsulate ang sarili nitong estado nang sapat na ligtas dahil kahit sino ay maaaring baguhin ang estado na iyon. Inihayag ang Mga Detalye ng Pagpapatupad : Kung makakakuha ka ng isang bagay mula sa isa pang bagay, masyado kaming umaasa sa mga detalye ng pagpapatupad ng unang bagay. Kung bukas ito ay magbabago (halimbawa, ang uri ng resulta), pagkatapos ay kailangan nating baguhin ang code. Ang lahat ng mga katwiran sa itaas ay tiyak na may katuturan, ngunit nakakaligtaan nito ang pinakamahalagang punto. Pangunahing Maling Paniniwala Karamihan sa mga programmer ay naniniwala na ang isang bagay ay isang istraktura ng data na may mga pamamaraan. Sinipi ko ang artikulo ni Bozhidar Bozhanov: Getters and Setters are not evil. Ngunit karamihan sa mga bagay kung saan nilikha ang mga getter at setter ay naglalaman lamang ng data. Ang maling akala na ito ay bunga ng isang malaking hindi pagkakaunawaan! Ang mga bagay ay hindi "nag-iimbak lamang ng data." Ang mga bagay ay hindi mga istruktura ng data na may mga nakalakip na pamamaraan. Ang konseptong ito ng "imbakan ng data" ay nagmula sa object-oriented programming at procedural na mga wika, lalo na ang C at COBOL. Uulitin ko muli: ang isang bagay ay hindi lamang isang koleksyon ng mga elemento ng data at mga function na nagmamanipula sa kanila. Ang isang object ay hindi isang data object. Ano ngayon? Bola at Aso Sa totoong object-oriented na programming, ang mga bagay ay mga buhay na nilalang, katulad mo at ako. Sila ay mga buhay na organismo, na may sariling pag-uugali, mga katangian at ikot ng buhay. Maaari bang magkaroon ng setter ang isang buhay na organismo? Maaari mo bang ikabit ang (“itakda”) ng bola sa isang aso? wag mong isipin. Ngunit iyon mismo ang ginagawa ng piraso ng code sa ibaba:

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

Kaya paano mo ito gusto? Maaari mo bang makuha ("kunin") ang bola mula sa aso? Well, ipagpalagay natin na kaya mo. Kung sakaling kinain niya ito at inoperahan mo siya. Sa kasong ito, oo, makukuha mo (“kunin”) ang bola mula sa aso. Ito mismo ang aking pinag-uusapan:

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

O isang mas nakakatawang halimbawa:

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

Naiisip mo ba ito sa totoong buhay? Parang araw-araw kang nagsusulat? Kung oo, ikaw ay isang procedural programmer. Aminin mo na lang. Narito ang sinabi ni David West sa pahina 30 ng kanyang aklat: Ang unang hakbang sa pagbabago ng isang matagumpay na developer ng pamamaraan sa isang matagumpay na developer ng layunin ay isang lobotomy. Kailangan mo ba ng lobotomy? Talagang kailangan ko ito, at nakuha ko ito habang binabasa ang aklat ni West na "Object Thinking". Layunin na Pag-iisip Simulan ang pag-iisip tulad ng isang bagay at agad mong palitan ang pangalan ng mga pamamaraang ito. Narito ang maaari mong makuha:

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

Ngayon tinatrato namin ang aso bilang isang tunay na hayop na maaaring kunin ang bola mula sa amin at maaaring ibalik ito kung kami ay humingi. Kung sakali, tandaan ko na ang aso ay hindi maaaring ibalik ang NULL. Hindi lang alam ng mga aso kung ano ang NULL! Ang layunin ng pag-iisip (pag-iisip) ay agad na nag-aalis ng mga NULL na sanggunian mula sa iyong code. Isang Isda na Tinawag na Wanda (1988) ni Charles Crichton Bilang karagdagan, ang layunin ng pag-iisip ay hahantong sa kawalan ng pagbabago ng isang bagay, tulad ng "bigat ng aso" sa aming halimbawa. Isusulat mong muli ang code na tulad nito:

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

Ang aso ay isang hindi nababagong buhay na organismo na hindi papayagan ang sinuman sa labas na baguhin ang timbang, o laki, o pangalan nito, atbp. Maaari niyang "sabihin", kapag hiniling, ang kanyang timbang o pangalan. Walang mali sa mga pampublikong pamamaraan na naglalantad ng mga query para sa ilang partikular na "internal" na katangian ng isang bagay. Ngunit ang mga pamamaraang ito ay hindi "getters" at hindi sila dapat tumanggap ng prefix na "get". Hindi tayo "nakakalabas" sa aso. Hindi namin nakuha ang kanyang pangalan. Hinihiling namin sa kanya na sabihin sa amin ang kanyang pangalan. Nakikita mo ba ang pagkakaiba? Hindi namin pinag-uusapan ang tungkol sa semantics dito. Pinag-iiba namin ang procedural approach sa programming mula sa object-oriented. Sa procedural programming, nagtatrabaho kami sa data, manipulahin ito, kunin ito, itakda ito, at tanggalin ito kung kinakailangan. Kami ang namamahala, at ang data ay isang passive component lamang. Ang aso ay wala sa amin - ito ay "naglalaman ng data." Wala siyang sariling buhay. Malaya nating makukuha (makukuha) ang lahat ng kailangan natin dito at ilagay (itakda) ang anumang data dito. Ito ay kung paano gumagana ang C, COBOL, Pascal at iba pang mga procedural na wika (nagtrabaho). At ang sitwasyon ay ganap na kabaligtaran sa object-oriented na mundo. Dito tinatrato namin ang mga bagay bilang mga buhay na organismo, na may sariling petsa ng kapanganakan at sandali ng kamatayan, na may sariling personalidad at gawi, kung gusto mo. Maaari naming hilingin sa aso na bigyan kami ng isang piraso ng data (halimbawa, ang bigat nito) at maaari nitong ibalik ang impormasyon sa amin. Ngunit laging tandaan na ang aso ay ang aktibong sangkap. Siya ang magpapasya kung ano ang mangyayari pagkatapos ng kahilingan. At iyon ang dahilan kung bakit ganap na mali para sa mga pamamaraan ng isang bagay na magsimula sa set o get. At hindi ito tungkol sa paglabag sa encapsulation, gaya ng iniisip ng maraming tao. Ito ay tungkol sa katotohanan na nag-iisip ka tulad ng isang bagay o nagsusulat ka pa rin ng COBOL na may Java syntax. PS . At oo, maaari mong itanong: "Paano ang JavaBeans, JPA, JAXB at marami pang ibang Java API na nakadepende sa get/set?" Paano naman ang built-in na function sa Ruby na nagpapadali sa paggawa ng mga accessor? Well, ano ang masasabi ko sa iyo... wala kang swerte. Mas madaling manatili sa primitive na mundo ng pamamaraang COBOL kaysa maunawaan at yakapin ang kahanga-hangang mundo ng mga totoong bagay. P.P.S. _ Nakalimutan kong sabihin, oo, ang pagpasok ng mga dependency sa pamamagitan ng isang setter ay isang kahila-hilakbot na anti-pattern. Ngunit higit pa tungkol diyan sa susunod na post! Orihinal na artikulo