Getters/Setters. jahat. Dan tempoh

Artikel oleh Egor Bugaenko 19 September 2014 | Dihantar dalam: Core Java Perdebatan lama ini telah dimulakan oleh Allen Holub dalam artikelnya yang terkenal, pada tahun 2003, Mengapa kaedah getter dan setter adalah jahat - adakah getter/setter adalah anti-corak dan patutkah kita mengelakkannya, atau adakah ia sesuatu yang kita' semula terikat untuk mempunyai? diperlukan dalam pengaturcaraan berorientasikan objek. Saya akan menambah dua sen saya pada perbincangan ini. Intipati teks di bawah ialah ini: getter dan setter adalah amalan buruk; mereka yang menggunakannya tidak mempunyai alasan. Tetapi sekali lagi, untuk mengelakkan salah faham, saya sama sekali tidak mencadangkan penggunaan get/set harus dielakkan di mana mungkin. Tidak. Saya katakan bahawa anda tidak membenarkan mereka mendekati kod anda . Apa pendapat anda tentang kenyataan ini? Layak mendapat perhatian anda? Adakah anda telah menggunakan corak get/set selama 15 tahun dan adakah anda seorang arkitek Java yang dihormati? Dan anda tidak mahu mendengar karut ini dari orang yang tidak dikenali? Nah... saya faham perasaan awak. Saya merasakan perkara yang sama sehingga saya menemui buku David West "Pemikiran Objek" - ia adalah buku terbaik mengenai pengaturcaraan berorientasikan objek yang pernah saya baca. Jadi tolonglah. Bertenang dan cuba fahami apa yang saya cuba terangkan. Subjek Kontroversi Terdapat beberapa hujah terhadap "aksesor" (nama lain untuk getter dan setter) dalam dunia berorientasikan objek. Dan semuanya adalah hujah yang betul. Mari kita lihat sekilas tentang mereka. Tanya, Jangan Beritahu : Allen Holub berkata, "Jangan minta maklumat yang anda perlukan untuk melakukan kerja; 'tanya' entiti yang mempunyai maklumat itu untuk melakukan kerja untuk anda." Prinsip Enkapsulasi yang Dilanggar : Objek boleh diasingkan oleh objek lain kerana mereka dapat membenamkan sebarang data ke dalam objek, melalui penetap. Objek tidak boleh merangkum keadaannya sendiri dengan cukup selamat kerana sesiapa sahaja boleh menukar keadaan itu. Butiran Pelaksanaan Didedahkan : Jika anda boleh mendapatkan satu objek daripada objek lain, maka kami terlalu bergantung pada butiran pelaksanaan objek pertama. Jika esok ia berubah (contohnya, jenis hasil), maka kita perlu menukar kod tersebut. Semua justifikasi di atas sememangnya masuk akal, tetapi ini terlepas perkara yang paling penting. Salah Tanggapan Asas Kebanyakan pengaturcara percaya bahawa objek ialah struktur data dengan kaedah. Saya memetik artikel oleh Bozhidar Bozhanov: Getters and Setters are not evil. Tetapi kebanyakan objek yang getter dan setter dibuat hanya mengandungi data. Kesalahpahaman ini adalah hasil daripada salah faham yang besar! Objek tidak "sekadar menyimpan data." Objek bukan struktur data dengan kaedah dilampirkan. Konsep "storan data" ini datang daripada bahasa pengaturcaraan dan prosedur berorientasikan objek, terutamanya C dan COBOL. Saya akan ulangi sekali lagi: objek bukan sekadar koleksi elemen data dan fungsi yang memanipulasinya. Objek bukan objek data. Selepas itu, apa? Bola dan Anjing Dalam pengaturcaraan berorientasikan objek sebenar, objek adalah makhluk hidup, sama seperti anda dan saya. Mereka adalah organisma hidup, dengan tingkah laku, sifat dan kitaran hidup mereka sendiri. Bolehkah organisma hidup mempunyai setter? Bolehkah anda melampirkan (“menetapkan”) bola pada anjing? jangan fikir. Tetapi itulah yang dilakukan oleh sekeping kod di bawah:

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

Jadi bagaimana anda menyukainya? Bolehkah anda mendapatkan ("mendapatkan") bola daripada anjing itu? Baiklah, anggap anda boleh. Sekiranya dia memakannya dan anda melakukan pembedahan ke atasnya. Dalam kes ini, ya, anda akan boleh mendapatkan ("mendapatkan") bola daripada anjing itu. Inilah yang saya maksudkan:

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

Atau contoh yang lebih tidak masuk akal:

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

Bolehkah anda bayangkan ini dalam kehidupan sebenar? Adakah ia berbunyi seperti anda menulis setiap hari? Jika ya, maka anda adalah pengaturcara prosedur. Mengaku saja. Inilah yang dikatakan oleh David West pada halaman 30 bukunya: Langkah pertama dalam mengubah pembangun prosedur yang berjaya menjadi pembangun objektif yang berjaya ialah lobotomi. Adakah anda memerlukan lobotomi? Saya pasti memerlukannya, dan saya mendapatnya semasa membaca buku West "Pemikiran Objek". Pemikiran Objektif Mula berfikir seperti objek dan anda akan segera menamakan kaedah ini. Berikut ialah perkara yang anda mungkin dapat:

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

Sekarang kami menganggap anjing itu sebagai haiwan sebenar yang boleh mengambil bola daripada kami dan boleh memberikannya semula jika kami meminta. Sekiranya berlaku, saya perhatikan bahawa anjing itu tidak boleh mengembalikan NULL. Anjing tidak tahu apa itu NULL! Pemikiran objektif (pemikiran) segera mengalih keluar rujukan NULL daripada kod anda. A Fish Called Wanda (1988) oleh Charles Crichton Selain itu, pemikiran objektif akan menghasilkan ketidakbolehubahan objek, seperti "berat anjing" dalam contoh kami. Anda akan menulis semula kod seperti ini:

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

Anjing ialah organisma hidup yang tidak boleh berubah yang tidak akan membenarkan sesiapa di luar menukar berat, atau saiz, atau nama, dsb. Dia boleh "memberitahu", atas permintaan, berat badan atau namanya. Tidak ada yang salah dengan kaedah awam yang mendedahkan pertanyaan untuk sifat "dalaman" tertentu objek. Tetapi kaedah ini bukan "getters" dan mereka tidak sepatutnya menerima awalan "get". Kami tidak "keluar" daripada anjing itu. Kami tidak mendapat namanya. Kami meminta dia memberitahu kami namanya. Adakah anda melihat perbezaannya? Kami tidak bercakap tentang semantik di sini. Kami membezakan pendekatan prosedur untuk pengaturcaraan daripada yang berorientasikan objek. Dalam pengaturcaraan prosedur, kami bekerja dengan data, memanipulasinya, mendapatkannya, menetapkannya dan memadamkannya jika perlu. Kami bertanggungjawab, dan data hanyalah komponen pasif. Anjing bukanlah apa-apa bagi kita - ia hanya "mengandungi data." Dia tidak mempunyai kehidupannya sendiri. Kita boleh bebas mendapatkan (mendapatkan) semua yang kita perlukan daripadanya dan meletakkan (menetapkan) sebarang data ke dalamnya. Beginilah cara C, COBOL, Pascal dan bahasa prosedur lain berfungsi (berfungsi). Dan keadaannya benar-benar bertentangan dalam dunia berorientasikan objek. Di sini kita menganggap objek sebagai organisma hidup, dengan tarikh lahir dan saat kematian mereka sendiri, dengan personaliti dan tabiat mereka sendiri, jika anda suka. Kami boleh meminta anjing itu memberikan kami sekeping data (contohnya, beratnya) dan ia boleh mengembalikan maklumat itu kepada kami. Tetapi sentiasa ingat bahawa anjing adalah komponen aktif. Dia memutuskan apa yang berlaku selepas permintaan itu. Dan itulah sebabnya adalah salah untuk kaedah objek untuk bermula dengan set atau get. Dan ini bukan tentang melanggar enkapsulasi, seperti yang difikirkan oleh ramai orang. Ini adalah mengenai hakikat bahawa sama ada anda berfikir seperti objek atau anda masih menulis COBOL dengan sintaks Java. PS . Dan ya, anda mungkin bertanya: "Bagaimana pula dengan JavaBeans, JPA, JAXB dan banyak API Java lain yang bergantung pada get/set?" Bagaimana pula dengan fungsi terbina dalam Ruby yang memudahkan untuk mencipta aksesori? Nah, apa yang boleh saya beritahu anda... anda kurang bernasib baik. Adalah lebih mudah untuk kekal dalam dunia primitif COBOL prosedur daripada memahami dan menerima dunia objek sebenar yang indah. P.P.S. _ Saya terlupa untuk mengatakan, ya, memasukkan kebergantungan melalui penetap juga merupakan anti-corak yang mengerikan. Tetapi lebih lanjut mengenainya dalam siaran seterusnya! Artikel asal