Mengapa kelas data dianggap sebagai bau kode?

18

Artikel ini mengklaim bahwa kelas data adalah "bau kode". Alasannya:

Itu hal yang normal ketika kelas yang baru dibuat hanya berisi beberapa bidang publik (dan mungkin bahkan beberapa pengambil / setter). Tetapi kekuatan sebenarnya dari objek adalah bahwa mereka dapat berisi tipe perilaku atau operasi pada data mereka.

Mengapa salah untuk objek hanya berisi data? Jika tanggung jawab inti kelas adalah untuk mewakili data, tidak akan menambahkan metode yang beroperasi pada data melanggar Prinsip Tanggung Jawab Tunggal ?

data-structures code-smell

— Sipo
sumber

1

Ini akan sangat bergantung pada fitur bahasa. Dalam Python, misalnya, tidak ada perbedaan antara "bidang" dan pengaksesnya, kecuali jika Anda tidak ingin menulis Java dengan Python .

— jscs

1

Saya pikir memiliki beberapa data hanya kelas tidak bau kode per se, tetapi jika sebagian besar kelas seperti itu maka kita berbicara tentang "domain anemia" antipattern en.wikipedia.org/wiki/Anemic_domain_model

— Tulains Córdova

1

Saya tidak melihat bagaimana pertanyaan ini merupakan duplikat. Pertanyaan lain adalah tentang penggunaan kelas data dalam OO, sementara yang satu ini adalah tentang kelemahan dari data kelas - subjek yang sama sekali berbeda.

— Milos Mrdovic

Anda mungkin ingin membaca jawaban ini di stackoverflow yang jauh lebih dibedakan dari jawaban pilihan teratas di sini yang mendalilkan inferioritas model domain kaya dan menyajikannya seperti fakta yang terbukti. stackoverflow.com/questions/23314330/…

— McLovin

31

Sama sekali tidak ada yang salah dengan memiliki objek data murni. Penulis artikel itu terus terang tidak tahu apa yang dia bicarakan.

Pemikiran seperti itu bermula dari gagasan yang lama, gagal, bahwa "OO sejati" adalah cara terbaik untuk memprogram dan bahwa "OO sejati" adalah semua tentang "model data kaya" di mana orang menggabungkan data dan fungsionalitas.

Realitas telah menunjukkan kepada kita bahwa sebenarnya yang terjadi adalah yang sebaliknya, terutama di dunia solusi multi-utas ini. Fungsi murni, dikombinasikan dengan objek data yang tidak dapat diubah, adalah cara yang lebih baik untuk kode.

— David Arno
sumber

1

Hanya ingin menambahkan bahwa objek data murni dapat sangat berharga untuk memodelkan hubungan, validasi, mengendalikan akses / perubahan.

— Adrian

2

Meskipun itu bagus jika fungsi-fungsi murni yang hanya mengambil instance dari objek data yang tidak dapat diubah sebagai argumen diimplementasikan sebagai metode pada objek data.

— RemcoGerlich

7

Jika fungsi mengambil argumen dari tipe data itu, itu sudah digabungkan ke data.

— RemcoGerlich

4

Downvoting karena ini tidak benar, atau paling tidak masalah pendapat. Dalam bahasa OO, biasanya masuk akal untuk memiliki objek yang berisi data (yang masih bisa berubah!) Dan metode yang bertindak padanya. Fungsi murni dan data terpisah sangat bagus dalam paradigma bahasa lain, tetapi jika Anda melakukan OO, lakukan OO sepenuhnya.

— Marnen Laibow-Koser

3

Realitas telah menunjukkan kepada kita banyak hal. -1 untuk pendapat dogmatis "semuanya telah gagal". Juga, penulis tidak mengatakan bahwa objek data murni adalah "salah", hanya saja mereka "bau kode" dan patut dipertanyakan. Saya hanya menyesal bahwa saya punya satu downvote untuk diberikan bagi negara saya. :-)

— user949300

7

Sama sekali tidak ada yang salah dengan memiliki objek data murni. Penulis berpendapat tidak dibagikan oleh pengembang perangkat lunak yang saya tahu.

Khusus untuk pemetaan basis data, Anda secara umum memiliki kelas entitas yang hanya berisi bidang yang disimpan dalam basis data dan getter dan setter. Hibernate Wikipedia (kerangka kerja)

Gagasan lubang kacang Jawa yang digunakan oleh banyak alat / kerangka kerja didasarkan pada kelas data yang disebut kacang yang hanya berisi bidang dan getter dan setter terkait. Wikipdia JavaBeans

Fazit:
Jika seseorang mengklaim bahwa ada sesuatu yang 'buruk' atau 'bau kode', Anda harus selalu mencari alasan yang diberikan. Jika alasannya tidak meyakinkan Anda bertanya kepada orang lain untuk alasan yang lebih baik atau pendapat yang berbeda. (Seperti yang Anda lakukan di forum ini)

— MrSmith42
sumber

Penulis tidak mengatakan bahwa objek data murni "salah". Mereka mengatakan bahwa objek data murni adalah "bau kode", yang berarti Anda harus berpikir dua kali untuk menggunakannya.

— user949300

1

@ user949300, Anda tampak bingung. Jika penulis menyebut mereka sebagai bau kode, maka ia menunjukkan mungkin ada yang salah dengan mereka. Karena mereka dikenal luas hari ini sebagai praktik yang sangat baik, mereka jelas bukan bau kode. Jadi MrSmith42 benar: sama sekali tidak ada yang salah dengan mereka.

— David Arno

4

Argumen yang bagus mengapa oleh Martin Fowler:

"Tell-Don't-Ask adalah prinsip yang membantu orang mengingat bahwa orientasi objek adalah tentang menggabungkan data dengan fungsi yang beroperasi pada data itu. Ini mengingatkan kita bahwa daripada meminta objek untuk data dan bertindak pada data itu, kita sebagai gantinya harus memberi tahu objek apa yang harus dilakukan. Ini mendorong untuk memindahkan perilaku ke objek untuk pergi dengan data. "

https://martinfowler.com/bliki/TellDontAsk.html

— Curtis Yallop
sumber

1

Masalahnya di sini adalah bahwa Fowler secara artifisial membatasi "katakan jangan tanya" dengan mengubah fungsi dari meminta lingkup yang lebih luas menjadi hanya menanyakan lingkup objek. Mereka masih bertanya. "Katakan jangan tanya" sebenarnya bisa diambil selangkah lebih maju dengan benar-benar mengatakan fungsi-fungsi itu melalui daftar argumen mereka. Dan dengan demikian kita sampai pada objek data dan fungsi terpisah (data bijaksana) menjadi implementasi sebenarnya dari "katakan jangan tanya". Jadi, alih-alih menjadi argumen yang bagus untuk klaim bahwa kelas data adalah bau kode, justru malah membuktikan sebaliknya.

— David Arno

2

@ Davidvido Anda lupa tentang enkapsulasi dan persembunyian. Anda memberi tahu objek untuk menjalankan metode anggota, dan metode anggota masuk ke kotak hitam objek dan melakukan apa pun untuk mendapatkan jawabannya. Jika Anda bertanya objek dari luar, Anda tidak memiliki akses ke negara privatnya, dan objek tersebut memperlihatkan lebih banyak keadaan daripada yang bijaksana, atau penanya harus melewati lebih banyak rintangan daripada yang seharusnya diperlukan. Saya tidak melihat mengapa Anda pernah "bertanya" objek di lingkungan OO. (Paradigma pemrograman lain mungkin memerlukan pendekatan yang berbeda, tentu saja.)

— Marnen Laibow-Koser

2

@ DavidArno Tentu saja Anda dapat mengirimkan bazsebagai parameter ke metode statis, tetapi untuk melakukan itu, Anda harus terlebih dahulu meminta objek untuk itu. Mungkin dalam paradigma pemrograman di mana metode yang utama (seperti, katakanlah, pemrograman fungsional) ini masuk akal, tetapi dalam lingkungan OO, sama sekali tidak, karena objek adalah yang utama dan harus berisi data dan fungsi untuk bertindak atasnya. Klaim Anda bahwa menghapus metode dari objek telah meningkatkan enkapsulasi juga persis mundur , sejauh yang saya tahu, karena itu berarti bahwa Anda sekarang telah bazmuncul di luar objek.

— Marnen Laibow-Koser

1

@ MarnenLaibow-Koser, saya tidak mengklaim "melakukan OO". Saya menulis kode dan saya menggunakan teknik yang baik untuk melakukannya. Apakah teknik-teknik itu berasal dari paradigma fungsional, atau paradigma OO, atau paradigma yang memberi-peduli-tidak menarik bagi saya. Memilih paradigma dan berpegang teguh padanya sebisa mungkin adalah dogma murni. Itu buruk. Itu konyol. Ini melumpuhkan Anda dan menghasilkan kode yang lebih rendah. Jangan lakukan itu.

— David Arno

1

@ Davidvido Sebaliknya, jika Anda berkomitmen penuh untuk suatu paradigma (paradigma yang layak, bukan hanya OO), Anda mendapatkan abstraksi tingkat tinggi yang kuat dan secara logis konsisten, kode yang dapat dipertahankan. Saya tidak mengatakan ini sebagai dogmatis, tetapi lebih pragmatis. Saya telah melihat dan memelihara terlalu banyak kode yang tampaknya diproduksi dengan sikap seperti milik Anda, di mana penulis tidak benar-benar berkomitmen pada konsistensi logis dari sistem yang digunakan. Sulit dimengerti, sulit dirawat, dan sulit dimodifikasi. Tidak ada paradigma yang sempurna, tetapi umumnya campuran (kecuali dipertimbangkan dengan cermat) lebih sulit untuk dipahami.

— Marnen Laibow-Koser

2

Yang perlu Anda pahami adalah bahwa ada dua jenis objek:

Objek yang memiliki perilaku . Ini harus menahan diri dari memberikan akses publik ke sebagian besar / anggota data mereka. Saya berharap hanya sedikit metode accessor yang ditentukan untuk ini.

Contohnya adalah regex yang dikompilasi: Objek dibuat untuk memberikan perilaku tertentu (untuk mencocokkan string dengan regex tertentu, dan melaporkan kecocokan (sebagian)), tetapi bagaimana regex yang dikompilasi melakukan tugasnya bukan merupakan milik pengguna bisnis.

Sebagian besar kelas yang saya tulis adalah dalam kategori ini.
Objek yang benar-benar hanya data . Ini seharusnya hanya menyatakan semua anggotanya publik (atau menyediakan set lengkap aksesor untuk mereka).

Contohnya adalah kelas Point2D. Sama sekali tidak ada invarian yang perlu dipastikan untuk anggota kelas ini, dan pengguna harus dapat mengakses data hanya melalui myPoint.xdan myPoint.y.

Secara pribadi, saya tidak menggunakan banyak kelas seperti itu, tetapi saya kira tidak ada kode yang lebih besar yang saya tulis yang tidak menggunakan kelas semacam itu di suatu tempat.

Menjadi mahir dengan orientasi objek termasuk menyadari bahwa perbedaan ini ada, dan belajar untuk mengklasifikasikan fungsi kelas menjadi salah satu dari dua kategori ini.

Jika Anda kode dalam C ++, Anda bisa membuat perbedaan ini secara eksplisit dengan menggunakan classuntuk kategori objek pertama, dan structuntuk yang kedua. Tentu saja, keduanya setara, kecuali itu classberarti bahwa semua anggota bersifat pribadi secara default, sementara structmenyatakan semua anggota publik secara default. Yang merupakan jenis informasi yang ingin Anda komunikasikan.

— cmaster - mengembalikan monica
sumber

1

Penjelasan untuk downvote akan keren ...

— cmaster - mengembalikan monica

Terima kasih atas jawabannya. Aku benci kalau orang downvote tanpa alasan. Jika Anda memiliki masalah dengan jawaban, jelaskan alasannya .

— Sipo