Sudahkah benda dikirimkan dalam hal penggunaan kembali kode?


17

Saya sering mendengar dikatakan bahwa objek belum dikirim dalam hal penggunaan kembali kode. Apa kamu setuju? Jika Anda yakin belum, mengapa tidak?


4
Saya tidak pernah mendengar ada yang mengatakan bahwa ...
TheLQ

2
Aku tidak percaya aku benar - benar mendengar seseorang mengatakannya, tapi aku sudah membacanya.
George Marian

Penggunaan kembali bukan satu-satunya keuntungan dari OOP.
Tidak ada yang

2
"Sudahkah benda dikirimkan dalam bentuk penggunaan kembali kode?" -> Hanya jika Anda memercayai tenaga penjualan OOP dari masa lalu (apakah itu tahun 60-an? Saya lupa)
Steven Evers

Jawaban:


18

Tidak, belum tentu.

Objek menghasilkan semantik yang lebih baik, pengaturan kode / fungsionalitas dan, mungkin, kemudahan penggunaan.

Dirancang dengan baik perpustakaan memenuhi janji dari penggunaan kembali kode, bukan objek per se.


Baiklah. Tetapi apakah objek telah membantu perancang perpustakaan dengan memberikan mereka pilihan yang membuat perpustakaan mereka lebih mudah untuk digunakan kembali? Saya berpendapat mereka miliki, dan karena itu objek telah memberikan penggunaan kembali yang ditingkatkan.
Jules

@ Jules I juga suka berdebat hanya untuk berdebat. Saya tidak akan berdebat bahwa objek tidak membuat mendesain perpustakaan lebih mudah. Saya berpendapat bahwa penggunaan alat Anda secara tepat adalah yang mengarah pada hasil yang tepat.
George Marian

7

Jujur saya tidak yakin apakah "penggunaan kembali kode" benar-benar apa yang dicari orang (atau setidaknya, harus setelah). Filosofi saya adalah "komponen perangkat lunak", yang berarti pemeliharaan yang lebih baik melalui antarmuka yang baik dan menghindari pemasangan yang tidak perlu. "Penggunaan kembali kode" adalah salah satu hal yang jatuh keluar dari itu kadang-kadang - kode duplikat yang tidak perlu adalah tanda bahwa Anda telah mengatur hal-hal dengan cara yang salah dan tentu saja sulit untuk mempertahankannya.

Untuk menjawab pertanyaan itu sedikit lebih langsung, ada sekumpulan alat yang cukup bagus untuk menghindari pengulangan diri Anda: warisan, sifat, pendelegasian, fungsi tingkat tinggi, dll. Dari mereka, orang cenderung membingungkan warisan dengan OO secara keseluruhan - dan mereka juga cenderung terlalu sering menggunakannya, jika Anda bertanya kepada saya. Mungkin dari situlah beberapa getaran "OO sucks" berasal: menemukan warisan tersangkut di tempat yang tidak memiliki hak alami untuk menjadi :)


Penggunaan kembali kode jelas merupakan sesuatu yang bertujuan, ketika Anda dapat menghindari mengorbankan kualitas kode
Casebash

1
Penggunaan kembali kode bukanlah tujuan bagi dirinya sendiri. Penggunaan kembali adalah kata lain untuk penggandengan. Karena itu, Anda harus mendekati menggunakan kembali dengan hati-hati. Sepertinya banyak pengembang melupakan ini. Mereka menginginkan sistem yang dipisahkan, tetapi berbalik dan mencoba menggunakan kelas yang ada di mana-mana.
Andy

5

Tidak, "objek" belum membuat kode yang digunakan kembali menjadi lebih mudah atau lebih umum. Kekhawatiran yang sama yang mencegah kode dari digunakan kembali dalam program modular (merancang, menguji dan mendokumentasikan API tujuan umum memerlukan upaya di muka yang jauh lebih banyak daripada menulis rutin satu kali, dan jack semua perdagangan mungkin adalah master of none - logika yang dimaksudkan untuk digunakan kembali mungkin tidak dioptimalkan dengan baik untuk penggunaan yang sebenarnya diterapkan) berlaku untuk program OO, dengan kekhawatiran tambahan bahwa model objek yang dirancang dengan buruk dapat menghambat penggunaan kembali yang dapat digunakan kembali. kode.

OO adalah abstraksi praktis untuk banyak masalah, tetapi waspadai sensasi tahun 80-an-90-an: itu tidak secara ajaib menyelesaikan masalah mendasar perdagangan kita seperti halnya membuat wafel untuk Anda saat Anda tidur.


5

Saya tidak berharap SEMUA objek dapat digunakan kembali, tetapi kami memiliki banyak objek yang kami gunakan kembali pada banyak proyek berbeda. Kami juga memiliki objek yang baru saja digunakan kembali pada satu proyek. Kami sering akan mengkonsumsi objek bisnis yang sama (atau objek transfer data) serta objek logika bisnis dari aplikasi desktop Click-Once, aplikasi web, dan aplikasi telepon semua untuk proyek yang sama.

Di mana Anda pernah mendengar bahwa OO tidak memenuhi penggunaan kembali? Dan apa alasannya? Mungkin desain benda mereka memaksa mereka ke dalam situasi itu ...


4
Berbagai artikel. Dan dari pengalaman pribadi, membuat objek yang dapat digunakan kembali sama sekali tidak mudah
Casebash

3

Beberapa Pemrogram akan menyalin dan menempel dalam bahasa dan gaya apa pun.

Pemrogram yang benar-benar baik dapat menghindari sebagian besar copy dan paste di hampir semua bahasa.

Saya menemukan pola OO cenderung mendorong penggunaan kembali. Saya telah melihat kode Java yang ditulis dalam gaya non-OO (di mana data dipisahkan dari kode karena ORM jelek) dan penggunaan kembali benar-benar sengsara - tetapi dalam OO programmer yang sama melakukan pekerjaan yang lebih baik di desain ( dan digunakan kembali).

Juga dalam kasus di mana kita menggunakan pola non-oo atau anti-patters seperti setter / getter, pernyataan switch, kelas batin anonim, fungsi besar dan sejenisnya saya telah melihat kode menggunakan kembali turun dan boilerplate naik ... secara signifikan.

ps. Saya tahu orang akan mengalami masalah dengan paragraf sebelumnya, jadi saya akan menjelaskan sedikit.

Setter dan pengambil menyebabkan masalah OO karena memungkinkan Anda untuk beroperasi pada anggota suatu objek (objek harus memanipulasi itu anggota SENDIRI) Ini mendistribusikan kode yang beroperasi pada kelas Anda di seluruh kelas lain yang mengharuskan Anda untuk menyalin fungsionalitas di sekitar setter / pengambil . Ini berlaku untuk Properti juga - hanya karena Properti lebih mudah tidak membuat mereka "Baik" dalam semua situasi.

Kode dalam kelas dalam Anonim tidak dapat digunakan kembali sama sekali dan orang lupa bahwa banyak hal (seperti pendengar) dapat dan harus menjadi kelas penuh - ini berlaku untuk penutupan juga! Jika Anda telah menggunakan kelas dalam anonim untuk menerapkan sesuatu seperti pendengar, Anda lebih mungkin untuk hanya menyalin dan menempelkan implementasi Anda daripada mengekstrak kode ke dalam metode atau kelas itu sendiri dan menyebutnya sebagai gantinya. Penutupan juga dapat meningkatkan usabilitas ulang - hanya tergantung pada bagaimana Anda menggunakannya.

Dalam banyak kasus, fitur yang tersedia untuk Anda membentuk bagaimana Anda menyusun kode Anda. OO bahkan lebih kuat ketika datang untuk membantu Anda memvisualisasikan semua kode Anda dan bagaimana kode itu berinteraksi, tapi itu pertanyaan lain.


2

Objek tidak memiliki lebih banyak kemampuan untuk memberikan penggunaan kembali kode daripada stairclimber atau peralatan kebugaran lainnya dapat memberikan penurunan berat badan. Pengembang harus termotivasi untuk menggunakan alat dengan benar.

Setelah tim perangkat lunak memberikan nilai lebih tinggi untuk menggunakan kembali kode yang diuji daripada menjaga semua detail di kepala mereka, Anda akan melihat jauh lebih banyak objek dan metode berbutir halus dan karenanya lebih banyak menggunakan kembali kode.


2

Iya

OOP memberi Anda lebih banyak cara untuk menggunakan kembali kode

Tidak

tidak ada peluru perak

Tergantung

pada apa yang Anda masukkan ke dalamnya, dan apa yang Anda harapkan sebagai imbalan!


1

Iya. Pemrograman berorientasi objek yang baik mendorong pemisahan kekhawatiran, kopling rendah, kohesi tinggi, dan penyembunyian informasi. Semua ini penting untuk kode yang dapat digunakan kembali.

Saya berpendapat bahwa manfaat utama OOP adalah modularitas dan modifiability, daripada digunakan kembali, tapi itu pertanyaan lain.


4
Saya setuju bahwa objek membuat kode lebih bagus, tetapi sayangnya sebagian besar objek saya tidak dapat digunakan kembali. Untuk sering, membuat objek dapat digunakan kembali berarti menyederhanakan situasi
Casebash

2
@casebase +1 Namun, saya akan mengatakan bahwa membuat objek dapat digunakan kembali berarti terlalu rumit situasi (objek).
George Marian

Tidak semuanya akan dapat digunakan kembali. Kebanyakan hal tidak akan terjadi. Namun, kopling rendah, penyembunyian informasi, dll, semua adalah prasyarat untuk digunakan kembali, dan objek mempromosikannya.
Fishtoaster

2
@Fishtoaster: Anda mungkin juga mengatakan bahwa mobil Anda bergerak adalah prasyarat untuk mulai bekerja, dan jalan masuk yang landai mempromosikannya. Secara teknis itu benar, tetapi tidak mungkin untuk membuat perbedaan di luar kasus tepi: jika Anda perlu dan ingin digunakan kembali, Anda akan mendapatkannya, OO atau tidak; jika tidak, maka memiliki prasyarat tidak akan mewujudkannya secara tidak sengaja.
Shog9

@Pak. C- Saya tidak yakin saya mengikuti maksud Anda. Saya hanya menyatakan bahwa hal-hal yang dipupuk OOP (modularitas, dll) membuatnya lebih mudah untuk membuat hal-hal seperti perpustakaan. Ada banyak cara untuk membuat kode dapat digunakan kembali dengan memisahkan masalah, dll- OOP adalah satu, desain metode yang baik adalah hal lain, dekomposisi masalah yang tepat masih ada.
Fishtoaster

1

Objek memungkinkan pengkodean ulang tetapi karena itu bukan teknik yang paling untuk itu. Saya pikir penggunaan kembali kode dipromosikan melalui teknik yang berhubungan dengan objek seperti pewarisan, polimorfisme, overloading, dan templat.


1

Ya, mereka melakukannya, kemampuan untuk memperluas (mewarisi) dari cleary kelas super berkontribusi untuk menggunakan kembali kode, saya tidak yakin bagaimana orang bisa berdebat sebaliknya. Anda cukup memperluas kelas dan menimpa satu metode, saat menggunakan sisanya dari kelas super, jika ini tidak membantu dalam penggunaan kembali kode maka saya tidak tahu apa itu


0

Jika sudah apakah mereka memenuhi janji mereka untuk menggunakan kembali kode sejauh ini? Ya, jika program yang ditulis dengan OOP dalam pikiran menerapkan pola desain dengan bijak. Kalau tidak, kebanyakan tidak. Tetapi melihat popularitas program non-sepele skala besar yang sistem Adobe, Google dan sejenisnya menulis dengan C ++ atau Java atau bahasa OOP lainnya, saya akan mengatakan OOP memiliki jalan panjang sebelum dihapus secara bertahap. Waktu itu akan jauh lebih cocok untuk mengajukan pertanyaan ini dan dapat membantu menyediakan pekerjaan dasar untuk paradigma baru.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.