Pengambil/Penyetel. Kejahatan. Dan titik

Artikel oleh Egor Bugaenko 19 September 2014 | Diposting di: Core Java Perdebatan lama ini dimulai oleh Allen Holub dalam artikelnya yang terkenal, pada tahun 2003, Mengapa metode pengambil dan penyetel itu jahat - apakah pengambil/penyetel merupakan anti-pola dan haruskah kita menghindarinya, atau apakah itu sesuatu yang kita' pasti diperlukan dalam pemrograman berorientasi objek. Saya akan menambahkan dua sen saya ke diskusi ini. Inti dari teks di bawah ini adalah: getter dan setter adalah praktik yang buruk; mereka yang menggunakannya tidak punya alasan. Namun sekali lagi, untuk menghindari kesalahpahaman, saya sama sekali tidak menyarankan penggunaan get/set sedapat mungkin dihindari. TIDAK. Saya mengatakan bahwa Anda bahkan tidak membiarkan mereka mendekati kode Anda . Apa pendapat Anda tentang pernyataan ini? Layak untuk diperhatikan? Apakah Anda telah menggunakan pola get/set selama 15 tahun dan apakah Anda seorang arsitek Java yang disegani? Dan Anda bahkan tidak ingin mendengarkan omong kosong dari orang asing ini? Baiklah... aku mengerti perasaanmu. Saya merasakan hal yang sama sampai saya menemukan buku David West "Object Thinking" - ini adalah buku terbaik tentang pemrograman berorientasi objek yang pernah saya baca. Jadi tolong. Tenanglah dan cobalah memahami apa yang ingin saya jelaskan. Subyek Kontroversi Ada beberapa argumen yang menentang "aksesor" (nama lain untuk getter dan setter) dalam dunia berorientasi objek. Dan itu semua adalah argumen yang sangat benar. Mari kita lihat sekilas. Tanya, Jangan Katakan : Allen Holub mengatakan, "Jangan meminta informasi yang Anda perlukan untuk melakukan suatu pekerjaan; 'tanyakan' entitas yang memiliki informasi tersebut untuk melakukan pekerjaan itu untuk Anda." Prinsip Enkapsulasi yang Dilanggar : Suatu objek dapat dibongkar oleh objek lain karena mereka dapat menyematkan data apa pun ke dalam objek tersebut, melalui setter. Sebuah objek tidak bisa mengenkapsulasi keadaannya dengan cukup aman karena siapa pun dapat mengubah keadaan tersebut. Detail Implementasi Terungkap : Jika Anda bisa mendapatkan satu objek dari objek lain, maka kami terlalu mengandalkan detail implementasi objek pertama. Jika besok berubah (misalnya tipe hasil), maka kita harus mengubah kodenya. Semua pembenaran di atas tentu saja masuk akal, namun ini melenceng dari poin terpenting. Kesalahpahaman Dasar Kebanyakan programmer percaya bahwa suatu objek adalah struktur data dengan metode. Saya mengutip artikel Bozhidar Bozhanov: Getter dan Setter tidak jahat. Namun sebagian besar objek yang getter dan setternya dibuat hanya berisi data. Kesalahpahaman ini adalah akibat dari kesalahpahaman yang sangat besar! Objek tidak "hanya menyimpan data". Objek bukanlah struktur data dengan metode terlampir. Konsep "penyimpanan data" ini berasal dari pemrograman berorientasi objek dan bahasa prosedural, khususnya C dan COBOL. Saya ulangi lagi: suatu objek bukan sekedar kumpulan elemen data dan fungsi yang memanipulasinya. Objek bukanlah objek data. Lalu bagaimana? Bola dan Anjing Dalam pemrograman berorientasi objek yang sebenarnya, objek adalah makhluk hidup, sama seperti Anda dan saya. Mereka adalah organisme hidup, dengan perilaku, sifat, dan siklus hidupnya sendiri. Bisakah organisme hidup memiliki setter? Bisakah Anda memasang (“meletakkan”) bola ke seekor anjing? Jangan berpikir. Namun itulah yang dilakukan oleh potongan kode di bawah ini:

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

Jadi bagaimana kamu menyukainya? Bisakah Anda mengeluarkan (“mengeluarkan”) bola dari anjing? Baiklah, anggap saja Anda bisa. Seandainya dia memakannya dan Anda melakukan operasi padanya. Dalam hal ini, ya, Anda akan bisa mendapatkan (“mendapatkan”) bola dari anjing. Inilah yang saya bicarakan:

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

Atau contoh yang lebih konyol lagi:

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

Dapatkah Anda membayangkan hal ini dalam kehidupan nyata? Apakah sepertinya Anda menulis setiap hari? Jika ya, maka Anda adalah seorang programmer prosedural. Akui saja. Inilah yang dikatakan David West di halaman 30 bukunya: Langkah pertama dalam mengubah pengembang prosedural yang sukses menjadi pengembang objektif yang sukses adalah lobotomi. Apakah Anda memerlukan lobotomi? Saya benar-benar membutuhkannya, dan saya mendapatkannya saat membaca buku West "Object Thinking". Berpikir Objektif Mulailah berpikir seperti sebuah objek dan Anda akan segera mengganti nama metode ini. Inilah yang mungkin Anda dapatkan:

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

Sekarang kita memperlakukan anjing sebagai hewan nyata yang dapat mengambil bola dari kita dan mengembalikannya jika kita memintanya. Untuk berjaga-jaga, saya perhatikan bahwa anjing tidak dapat mengembalikan NULL. Anjing tidak tahu apa itu NULL! Pemikiran objektif (berpikir) segera menghapus referensi NULL dari kode Anda. Seekor Ikan Bernama Wanda (1988) oleh Charles Crichton Selain itu, pemikiran objektif akan mengarah pada kekekalan suatu objek, seperti “berat anjing” dalam contoh kita. Anda akan menulis ulang kode seperti ini:

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

Seekor anjing adalah organisme hidup yang tidak dapat diubah yang tidak mengizinkan siapa pun di luar mengubah berat, ukuran, nama, dll. Dia dapat "mengetahui", berdasarkan permintaan, berat atau namanya. Tidak ada yang salah dengan metode publik yang mengekspos pertanyaan untuk properti "internal" tertentu dari suatu objek. Namun metode ini bukanlah “pengambil” dan tidak boleh menerima awalan “dapatkan”. Kita tidak “keluar” dari anjing itu. Kami tidak mengetahui namanya. Kami memintanya untuk memberi tahu kami namanya. Apakah Anda melihat perbedaannya? Kami bahkan tidak membicarakan semantik di sini. Kami membedakan pendekatan prosedural pemrograman dari pendekatan berorientasi objek. Dalam pemrograman prosedural, kita bekerja dengan data, memanipulasinya, mendapatkannya, mengaturnya, dan menghapusnya jika perlu. Kami yang bertanggung jawab, dan data hanyalah komponen pasif. Seekor anjing tidak ada artinya bagi kita - ia hanya “berisi data”. Dia tidak memiliki kehidupannya sendiri. Kita dapat dengan bebas mendapatkan (mendapatkan) semua yang kita butuhkan darinya dan memasukkan (mengatur) data apa pun ke dalamnya. Beginilah cara kerja (berhasil) C, COBOL, Pascal, dan bahasa prosedural lainnya. Dan situasinya sangat bertolak belakang dengan dunia berorientasi objek. Di sini kita memperlakukan objek sebagai organisme hidup, dengan tanggal lahir dan momen kematiannya sendiri, dengan kepribadian dan kebiasaannya sendiri, jika Anda mau. Kita dapat meminta anjing untuk memberi kita sepotong data (misalnya, berat badannya) dan ia dapat mengembalikan informasi tersebut kepada kita. Namun selalu ingat bahwa anjing adalah komponen aktifnya. Dia memutuskan apa yang terjadi setelah permintaan itu. Dan itulah mengapa sangat salah jika metode suatu objek dimulai dengan set atau get. Dan ini bukan tentang pelanggaran enkapsulasi, seperti yang dipikirkan banyak orang. Ini tentang fakta bahwa Anda berpikir seperti sebuah objek atau Anda masih menulis dalam COBOL dengan sintaksis Java. PS . Dan ya, Anda mungkin bertanya: "Bagaimana dengan JavaBeans, JPA, JAXB dan banyak Java API lainnya yang bergantung pada get/set?" Bagaimana dengan fungsi bawaan di Ruby yang memudahkan pembuatan pengakses? Nah, apa yang bisa saya katakan... Anda kurang beruntung. Jauh lebih mudah untuk tetap berada di dunia primitif COBOL prosedural daripada memahami dan menerima dunia objek nyata yang menakjubkan. PPS _ Saya lupa mengatakan, ya, memasukkan dependensi melalui setter juga merupakan anti-pola yang buruk. Namun lebih lanjut tentang itu di postingan berikutnya! Artikel asli