Getters / Setters. ala. Lan periode

Artikel dening Egor Bugaenko 19 September 2014 | Dikirim ing: Inti Jawa Debat lawas iki diwiwiti dening Allen Holub ing artikel sing misuwur, ing taun 2003, Napa metode getter lan setter iku ala - iku getters / setter minangka anti-pola lan kudu kita nyingkiri, utawa iku soko kita ' re bound kanggo duwe? needed ing program object-oriented. Aku bakal nambah rong sen kanggo diskusi iki. Inti saka teks ing ngisor iki yaiku: getter lan setter iku laku sing ala; sing nggunakake ora ana alesan. Nanging maneh, supaya ora salah pangerten, aku ora menehi saran manawa panggunaan get / set kudu dihindari ing ngendi wae. Ora. Aku ngomong yen sampeyan ora nglilani dheweke cedhak karo kode sampeyan . Apa sampeyan mikir babagan statement iki? Layak kanggo manungsa waé? Apa sampeyan wis nggunakake pola get/set suwene 15 taun lan sampeyan dadi arsitek Jawa sing dihormati? Lan sampeyan malah ora pengin ngrungokake omong kosong iki saka wong liyo? Lha... aku ngerti perasaanmu. Aku ngrasakake cara sing padha nganti aku nemokake buku David West "Objek Thinking" - iku buku paling apik babagan pemrograman berorientasi obyek sing wis dakwaca. Dadi mangga. Tenang lan coba ngerti apa sing dakkarepake. Subyek Kontroversi Ana sawetara bantahan marang "aksesor" (jeneng liya kanggo getter lan setter) ing donya obyek-oriented. Lan kabeh argumen sing bener. Ayo dadi njupuk dipikir cepet ing wong. Takon, Aja Ngomong : Allen Holub ngandika, "Aja takon informasi sing perlu kanggo nindakake proyek; 'takon' entitas sing duwe informasi kanggo nindakake proyek kanggo sampeyan." Prinsip Enkapsulasi sing Dilanggar : Obyek bisa dipisahake dening obyek liyane amarga bisa nglebokake data menyang obyek kasebut, liwat setter. Obyek mung ora bisa mbungkus negarane kanthi aman amarga sapa wae bisa ngganti negara kasebut. Rincian Implementasi Dicethakaké : Yen sampeyan bisa njaluk siji obyek saka obyek liyane, banjur kita gumantung banget ing rincian implementasine saka obyek pisanan. Yen sesuk diganti (contone, jinis asil), banjur kita kudu ngganti kode. Kabeh kabeneran ing ndhuwur mesthi ana akal, nanging iki ora ana sing paling penting. Misconception Dasar Umume programer percaya yen obyek minangka struktur data kanthi metode. Aku ngutip artikel dening Bozhidar Bozhanov: Getters and Setters are not evil. Nanging umume obyek sing digawe getter lan setter mung ngemot data. Kesalahpahaman iki minangka akibat saka kesalahpahaman sing gedhe banget! Obyek ora "mung nyimpen data." Obyek dudu struktur data kanthi cara sing dilampirake. Konsep "panyimpenan data" iki asale saka basa pemrograman lan prosedural berorientasi obyek, utamane C lan COBOL. Aku bakal mbaleni maneh: obyek ora mung koleksi unsur data lan fungsi sing ngapusi wong. Objek dudu obyek data. Apa banjur? Ball lan Dog Ing pemrograman berorientasi obyek sing sejati, obyek iku makhluk urip, kaya sampeyan lan aku. Dheweke minangka organisme urip, kanthi prilaku, sifat lan siklus urip dhewe. Apa organisme urip bisa duwe setter? Apa sampeyan bisa masang ("nyetel") bal menyang asu? Aja mikir. Nanging iki persis apa sing ditindakake dening potongan kode ing ngisor iki:

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

Dadi kepiye sampeyan seneng? Apa sampeyan bisa njaluk ("njaluk") bal saka asu? Inggih, ayo nganggep sampeyan bisa. Yen dheweke mangan lan sampeyan nindakake operasi ing dheweke. Ing kasus iki, ya, sampeyan bakal bisa njaluk ("njaluk") bal saka asu. Iki persis sing dakkandhakake:

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

Utawa conto sing luwih konyol:

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

Apa sampeyan bisa mbayangno iki ing urip nyata? Apa muni kaya sampeyan nulis saben dina? Yen ya, sampeyan dadi programmer prosedural. Ngaku wae. Mangkene apa sing dikandhakake David West ing kaca 30 bukune: Langkah pertama kanggo ngowahi pangembang prosedural sing sukses dadi pangembang objektif sing sukses yaiku lobotomi. Apa sampeyan butuh lobotomi? Aku mesthi mbutuhake, lan aku entuk nalika maca buku West "Obyek Thinking". Objective Thinking Miwiti mikir kaya obyek lan sampeyan bakal langsung ngganti jeneng metode kasebut. Iki sing bisa sampeyan entuk:

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

Saiki kita nganggep asu kasebut minangka kewan nyata sing bisa njupuk bal saka kita lan bisa menehi maneh yen kita takon. Mung ing kasus, aku Wigati sing asu ora bisa bali NULL. Asu mung ora ngerti apa NULL! Pemikiran objektif (mikir) langsung mbusak referensi NULL saka kode sampeyan. A Fish Called Wanda (1988) dening Charles Crichton Kajaba iku, pamikiran objektif bakal nyebabake immutability saka obyek, kayata "bobot asu" ing conto kita. Sampeyan bakal nulis maneh kode kaya iki:

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

Anjing minangka organisme urip sing ora bisa diganti sing ora ngidini sapa wae ing njaba ngganti bobot, ukuran, utawa jeneng, lsp. Dheweke bisa "marang", miturut panyuwunan, bobot utawa jeneng. Ora ana sing salah karo metode umum sing mbukak pitakon babagan properti "internal" tartamtu saka sawijining obyek. Nanging cara kasebut dudu "getters" lan ora bakal nampa awalan "entuk". Kita ora "metu" saka asu. Kita ora ngerti jenenge. Kita njaluk dheweke ngandhani jenenge. Apa sampeyan ndeleng prabédan? Kita ora malah ngomong babagan semantik ing kene. Kita mbedakake pendekatan prosedural kanggo pemrograman saka sing berorientasi obyek. Ing pemrograman prosedural, kita nggarap data, ngapusi, entuk, nyetel, lan mbusak yen perlu. Kita tanggung jawab, lan data mung minangka komponen pasif. Anjing ora ana apa-apa kanggo kita - mung "ngandhut data." Dheweke ora duwe urip dhewe. Kita bisa kanthi bebas njaluk (njaluk) kabeh sing dibutuhake lan nglebokake (nyetel) data apa wae. Iki carane C, COBOL, Pascal lan basa prosedural liyane bisa (makarya). Lan kahanan iku temen ngelawan ing donya obyek-oriented. Ing kene kita nganggep obyek minangka organisme urip, kanthi tanggal lair lan wayahe mati, kanthi pribadine lan kabiasaan, yen sampeyan seneng. Kita bisa njaluk asu kanggo menehi kita Piece saka data (contone, bobot) lan bisa bali informasi kanggo kita. Nanging tansah elinga yen asu minangka komponen aktif. Dheweke mutusake apa sing kedadeyan sawise panjaluk kasebut. Lan mulane pancen salah yen metode obyek diwiwiti kanthi set utawa entuk. Lan iki dudu babagan nglanggar enkapsulasi, kaya sing dipikirake akeh wong. Iki babagan kasunyatan manawa sampeyan mikir kaya obyek utawa sampeyan isih nulis COBOL nganggo sintaks Jawa. PS . Lan ya, sampeyan bisa uga takon: "Apa babagan JavaBeans, JPA, JAXB lan akeh API Java liyane sing gumantung saka entuk / nyetel?" Apa babagan fungsi sing dibangun ing Ruby sing nggampangake nggawe aksesoris? Lha opo sing iso tak omongno...kowe kurang rejeki. Luwih gampang tetep ing jagad primitif COBOL prosedural tinimbang ngerti lan ngrampungake jagad obyek nyata sing apik banget. P.P.S._ _ Aku kelalen ngomong, ya, masang dependensi liwat setter uga anti-pola elek. Nanging luwih akeh babagan kasebut ing kirim sabanjure! Artikel asli