it-swarm-id.com

Apakah OOP memenuhi janji penggunaan kembali kode? Apa alternatif yang ada untuk mencapai penggunaan kembali kode?

Mungkin janji terbesar menggunakan paradigma berorientasi objek adalah penggunaan kembali kode. Beberapa membantah bahwa ini tercapai. Mengapa itu (tidak) tercapai?

Apakah kode digunakan kembali sebagai OOP mendefinisikannya, membuat proyek lebih produktif?

Atau lebih mudah dikelola? Atau lebih mudah dirawat? Atau dengan kualitas lebih?

Mungkin kita semua sepakat bahwa penggunaan kembali kode adalah hal yang baik, tetapi ada beberapa cara untuk mencapai tujuan ini. Pertanyaannya adalah tentang metode penggunaan kembali kode yang ditawarkan oleh OOP. Apakah itu hal yang baik? Apakah ada metode yang lebih baik untuk mencapai penggunaan kembali kode daripada orientasi objek, sub-klasifikasi, polimorfisme, dll? Cara apa yang lebih baik? Kenapa?

Ceritakan pengalaman Anda dengan OOP reuse atau paradigma lain reuse.

56
Maniero

Penggunaan kembali kode adalah ide yang cukup bagus. Bukan yang hebat.

Saya memiliki perspektif yang diambil dari sekitar 30 tahun rekayasa perangkat lunak, mencoba "menggunakan kembali".

Saya mulai menyelidiki "penggunaan kembali kode" sebagai topik penelitian di tahun 80-an, setelah menemukan saya telah menggunakan kembali desain satu OS yang saya bangun pada awal 70-an, untuk OS lain yang saya bangun pada akhir 70-an.

Bagian yang baik dari penggunaan kembali kode adalah kemampuan untuk terkadang menggunakan kembali kode yang sudah ada sebelumnya yang jujur. Tetapi dunia adalah penuh kode; bagaimana bisa menemukan yang Anda inginkan? Inilah yang saya sebut Kutukan Penggunaan Kembali :

Saya Sinterklas (Open Source ok), dan saya memiliki 1 miliar komponen perangkat lunak. Anda dapat memiliki salah satunya.

Semoga beruntung memilih.

Untuk memecahkan masalah penggunaan kembali dengan baik:

  • pengguna harus entah bagaimana menentukan apa yang dia butuhkan (fungsional, kinerja, bahasa target, asumsi lingkungan, ...)
  • harus ada perpustakaan kode "dapat digunakan kembali" yang telah diindeks dengan berbagai cara oleh kriteria potensial ini
  • beberapa mekanisme harus ada untuk memilih elemen kandidat (pada satu miliar elemen, Anda tidak dapat melihat semuanya secara pribadi)
  • perlu ada cara untuk menentukan seberapa jauh dari spesifikasi kandidat yang dipilih
  • beberapa proses reguler harus ada untuk memungkinkan reuser untuk memodifikasi kode yang dapat digunakan kembali yang dipilih (di sini adalah kontribusi terbesar OOP: Anda dapat mengedit komponen/objek yang ada dengan menimpa slotnya. OOP tidak menyediakan bantuan lainnya).
  • semua ini jelas lebih murah daripada hanya pengodean ulang itu

Sebagian besar yang telah ditemukan selama bertahun-tahun adalah agar kode dapat digunakan kembali, itu semacam harus dirancang untuk tujuan itu, atau mengandung terlalu banyak asumsi implisit. Pustaka penggunaan kembali kode yang paling sukses sebenarnya cukup kecil. Pustaka dan kerangka kerja bisa dibilang adalah kode yang "dapat digunakan kembali" dan sangat sukses; Java dan C # berhasil bukan karena mereka adalah bahasa komputer yang cukup bagus, tetapi karena mereka memiliki perpustakaan yang dirancang, diimplementasikan, dan didokumentasikan dengan sangat baik. Tetapi orang-orang tidak melihat kode sumber di perpustakaan, mereka hanya memanggil API yang terdokumentasi dengan baik (dirancang untuk dapat digunakan secara umum).

Apa yang tidak digunakan kembali oleh kode (OOP) tidak memberikan perintah peningkatan besar dalam kemampuan kami untuk kode sistem.

Saya pikir kekurangan utama adalah jenis penggunaan kembali kode pada dasarnya terbatas karena kode memiliki terlalu banyak asumsi bawaan . Jika Anda membuat kode kecil, Anda meminimalkan asumsi, tetapi kemudian biaya untuk membangun dari awal tidak terlalu besar dan keuntungan penggunaan kembali tidak efektif. Jika Anda membuat potongan kode besar, mereka cukup berguna dalam konteks baru. Seperti Gulliver, mereka terikat ke pantai oleh sejuta string kecil, dan Anda tidak bisa memotong semuanya.

Apa yang harus kita kerjakan adalah penggunaan kembali pengetahuan untuk membuat kode . Jika kita dapat melakukan ini, maka kita dapat menerapkan pengetahuan itu untuk membuat kode yang kita butuhkan, menangani sekumpulan asumsi saat ini.

Untuk melakukan ini, kita masih memerlukan kemampuan spesifikasi yang sama untuk mengkarakterisasi komponen perangkat lunak (Anda masih harus mengatakan apa yang Anda inginkan!). Tetapi kemudian Anda menerapkan pengetahuan "konstruksi" ini pada spesifikasi untuk menghasilkan kode yang Anda inginkan.

Sebagai sebuah komunitas, kami belum begitu pandai dalam hal ini. Tetapi orang-orang melakukannya sepanjang waktu; mengapa kita tidak bisa mengotomatiskannya? Ada banyak penelitian, dan ini menunjukkan hal itu dapat dilakukan dalam banyak keadaan.

Satu bagian penting dari mesin yang diperlukan untuk ini adalah alat mekanis untuk menerima "deskripsi komponen" (ini hanya dokumen formal dan dapat diuraikan seperti bahasa pemrograman) dan berlaku transformasi program = untuk mereka.

Compiler sudah melakukan ini: -} Dan mereka sangat bagus di kelas masalah yang mereka tangani.

Model UML dengan pembuatan kode adalah salah satu upaya untuk melakukan ini. Bukan usaha yang sangat bagus; cukup banyak yang dikatakan dalam kebanyakan model UML adalah "Saya punya data yang terlihat seperti ini". Cukup sulit untuk menghasilkan program nyata jika fungsinya ditinggalkan.

Saya mencoba membangun sistem transformasi program praktis, alat yang disebut DMS . Sudah cukup terganggu dengan menerapkan transformasi program tidak begitu banyak untuk spesifikasi abstrak untuk menghasilkan kode, tetapi lebih ke kode lama untuk membersihkannya. (Ini adalah masalah yang sama dalam abstrak!). (Untuk membangun alat seperti itu membutuhkan banyak waktu; Saya telah melakukan ini selama 15 tahun dan sementara itu Anda harus makan).

Tetapi DMS memiliki dua sifat utama yang saya jelaskan di atas: kemampuan untuk memproses spesifikasi formal yang sewenang-wenang, dan kemampuan untuk menangkap "pengetahuan pembuatan kode" sebagai transformasi, dan menerapkannya sesuai permintaan. Dan yang luar biasa, kami menghasilkan dalam beberapa kasus khusus, beberapa kode yang agak menarik dari spesifikasi; DMS sebagian besar dibangun menggunakan dirinya sendiri untuk menghasilkan implementasinya. Itu telah mencapai bagi kita setidaknya beberapa janji penggunaan kembali (pengetahuan): peningkatan produktivitas yang sangat signifikan. Saya memiliki tim yang terdiri dari sekitar 7 orang teknis; kami telah menulis mungkin 1-2 MSLOC "spesifikasi" untuk DMS, tetapi memiliki 10MSLOC kode yang dihasilkan.

Ringkasan: penggunaan kembali pengetahuan generasi adalah kemenangan, bukan penggunaan kembali kode.

35
Ira Baxter

Penggunaan kembali kode dicapai dalam OOP tetapi juga dicapai dalam pemrograman fungsional. Setiap kali Anda mengambil blok kode dan membuatnya dapat dihubungi oleh seluruh kode Anda sehingga Anda dapat menggunakan fungsi ini) di tempat lain kode digunakan kembali.

Jenis penggunaan kembali kode ini juga membuat kode lebih mudah dikelola karena mengubah blok yang dapat dipanggil ini mengubah semua tempat yang disebutnya. Saya akan mengatakan hasil ini juga meningkatkan kualitas dan keterbacaan.

Saya tidak yakin OOP ada hanya untuk menyediakan penggunaan kembali kode. Saya melihat OOP sebagai lebih banyak cara untuk berinteraksi dengan objek dan abstrak jauh rincian dari struktur data.

Dari Wikpedia:

Pemrograman berorientasi objek memiliki akar yang dapat dilacak hingga 1960-an. Karena perangkat keras dan lunak menjadi semakin kompleks, pengelolaan seringkali menjadi perhatian. Para peneliti mempelajari cara-cara untuk menjaga kualitas perangkat lunak dan mengembangkan pemrograman berorientasi objek sebagian untuk mengatasi masalah-masalah umum dengan sangat menekankan unit-unit logika pemrograman yang dapat digunakan kembali [rujukan?]. Teknologi ini berfokus pada data daripada proses, dengan program yang terdiri dari modul mandiri ("kelas"), yang setiap contohnya ("objek") berisi semua informasi yang diperlukan untuk memanipulasi struktur datanya sendiri ("anggota"). Ini berbeda dengan pemrograman modular yang sudah ada yang telah dominan selama bertahun-tahun yang berfokus pada fungsi modul, daripada khusus data, tetapi sama-sama disediakan untuk penggunaan kembali kode, dan unit logika pemrograman yang dapat digunakan sendiri secara mandiri, memungkinkan kolaborasi melalui penggunaan modul tertaut (subrutin). Pendekatan yang lebih konvensional ini, yang masih bertahan, cenderung mempertimbangkan data dan perilaku secara terpisah.

36
Chris

Ya dan Tidak

Penggunaan kembali kode adalah istilah umum untuk semua kegiatan yang berbeda.

  1. Kode digunakan kembali dalam satu proyek. OO sangat cocok untuk ini, aplikasi yang dirancang dengan baik akan memetakan hubungan dunia model dengan erat, sehingga menghilangkan kode duplikat sebisa mungkin dan disarankan. Namun, Anda dapat berargumen bahwa teknologi pra-OO dapat mencapai hal yang sama, yang benar, tetapi OO dalam banyak hal lebih nyaman.
  2. Perpustakaan pihak ketiga Ini tampaknya berfungsi sama baiknya dengan atau tanpa OO.
  3. Cross-purpose code reuse Janji penggunaan kembali kode terbesar dari OO adalah kode itu, setelah ditulis untuk satu aplikasi nantinya dapat digunakan kembali untuk yang lain, yang tidak telah dirancang khusus untuk. Ini adalah semua kemarahan ketika gagasan OO disaring melalui pintu kantor manajemen yang lebih tinggi, dan OO benar-benar gagal mencapainya. Ternyata tujuan itu adalah aspek krusial dari desain OO (dan mungkin semua kode prosedural, tapi itu hanya teori saya) dan upaya repurposing code berakhir dengan bencana pemeliharaan. (Antipatternsof yang terkenal itu) kerangka kerja lama yang tidak seorang pun berani untuk memodifikasi dan temannya, kerangka kerja yang sedikit berbeda untuk setiap aplikasi biasanya berasal dari sini.)
15
biziclop

Saya setuju dengan Chris, pemrograman fungsional adalah cara yang baik untuk menggunakan kembali kode.

Banyak program memiliki struktur kode yang berulang. Untuk ini beberapa pola desain digunakan dalam dunia OOP, tetapi ini dapat dicapai dengan fungsi rekursif dan pencocokan pola dalam bahasa pemrograman fungsional. Untuk lebih lanjut tentang ini lihat bab pertama di Pemrograman Fungsional Dunia Nyata .

Saya pikir warisan yang dalam di OOP dapat menyesatkan dalam banyak kasus. Anda memiliki kelas dan banyak metode yang terkait erat diimplementasikan dalam file yang berbeda. Sebagai Joe Armstrong mengatakan tentang OOP:

Masalah dengan bahasa berorientasi objek adalah mereka memiliki semua lingkungan implisit yang mereka bawa. Anda menginginkan pisang, tetapi yang Anda dapatkan adalah gorila yang memegang pisang dan seluruh hutan.

Fungsi pesanan tinggi juga sangat berguna dalam hal penggunaan kembali kode mis. map dan foldr itu adalah dasar untuk Google MapReduce .

Melewati pesan tidak sinkron juga merupakan cara yang baik untuk mengatur perangkat lunak yang kompleks, dan beberapa ilmuwan komputer menyatakan bahwa objek diasumsikan berkomunikasi dengan satu sama lain secara tidak sinkron seperti pada Katakan, jangan tanya OOP prinsip. Lihat lebih lanjut tentang ini di Pemrograman Berorientasi Objek: The Wrong Path? were Joe Armstrong dikutip:

Saya mulai bertanya-tanya tentang apa itu pemrograman berorientasi objek dan saya pikir Erlang tidak berorientasi objek, itu adalah bahasa pemrograman fungsional. Kemudian, pembimbing tesis saya berkata, "Tapi Anda salah, Erlang sangat berorientasi objek". Dia mengatakan bahasa berorientasi objek tidak berorientasi objek. Saya mungkin berpikir, meskipun saya tidak begitu yakin apakah saya percaya ini atau tidak, tetapi Erlang mungkin satu-satunya bahasa berorientasi objek karena 3 prinsip pemrograman berorientasi objek didasarkan pada pesan lewat , bahwa Anda memiliki isolasi antara objek dan memiliki polimorfisme .

Pesan asinkron yang lewat seperti pada sistem yang didorong oleh kejadian dan di Erlang juga merupakan cara yang sangat baik untuk memisahkan sistem dan kopling longgar penting dalam sistem yang kompleks. Dengan sistem yang cukup terpisah Anda dapat mengembangkan sistem saat sedang berjalan, mungkin pada node yang berbeda. Unibet membuat presentasi hebat tentang ini: Domain Event Driven Architecture

Namun saya pikir sebagian besar penggunaan kembali kode dilakukan dengan menggunakan pustaka dan kerangka kerja.

13
Jonas

Saya akan mengirim jawaban panjang tapi mengapa? Udi Dahan menjelaskannya lebih baik daripada yang saya bisa.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Inilah awal tulisan:

Industri ini dipenuhi dengan penggunaan kembali.

Ada keyakinan bahwa jika kita hanya menggunakan kembali lebih banyak kode, semuanya akan lebih baik.

Beberapa orang bahkan mengatakan bahwa seluruh titik orientasi objek digunakan kembali - bukan, enkapsulasi adalah hal besar. Setelah itu komponen-orientasi adalah hal yang seharusnya digunakan kembali. Tampaknya itu tidak berjalan dengan baik karena di sini kita sekarang menaruh harapan kita pada orientasi layanan.

Seluruh buku pola telah ditulis tentang cara mencapai penggunaan kembali dengan orientasi hari itu. Layanan telah diklasifikasikan dengan segala cara untuk mencapai hal ini, dari layanan entitas dan layanan aktivitas, melalui layanan proses dan layanan orkestrasi. Menulis layanan telah disebut-sebut sebagai kunci untuk menggunakan kembali, dan menciptakan layanan yang dapat digunakan kembali.

Saya mungkin juga membiarkan Anda masuk pada rahasia kecil-kotor:

Penggunaan kembali adalah kesalahan

13
Tony

Pipa unix sederhana telah melakukan lebih banyak untuk menggunakan kembali kode daripada apa pun yang telah datang dan pergi. Objek baru saja terjadi menjadi cara intuitif menyusun kode ketika mereka datang dan kemudian orang mulai menempel pada apa saja dan segala sesuatu di atasnya. Secara umum objek adalah untuk enkapsulasi dan bukan untuk penggunaan kembali kode, penggunaan kembali kode membutuhkan sesuatu yang lebih dan hierarki pewarisan kelas adalah pengganti yang buruk untuk apa seharusnya mekanisme penggunaan kembali kode.

6
davidk01

OOP tidak istimewa; Anda dapat membuat kode yang dapat digunakan kembali dengan atau tanpa OOP. Fungsi murni dapat digunakan kembali: misalnya, Java.lang.math.sqrt(double) mengambil angka dan memberikan nomor. Tidak ada OOP, tetapi jelas lebih dapat digunakan kembali daripada kebanyakan kode di luar sana.

4
Joonas Pulakka

Dari tampilan pemrograman fungsional OOP sebagian besar tentang mengelola negara.

Dalam pemrograman fungsional, Anda dapat dengan mudah memiliki ratusan fungsi yang berguna untuk daftar: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html .

Apakah Anda memiliki ratusan metode dalam kelas Daftar? Metode publik dianggap sebagai antarmuka ke keadaan internal yang Anda ingin tetap kecil.

Sayangnya, alih-alih (kembali) menggunakan banyak fungsi kecil, beberapa orang menduplikasi fungsi. Bagi saya itu karena OOP tidak mendorong penggunaan kembali kode seperti halnya pemrograman fungsional.

4
LennyProgrammers

Bagi saya, ya, tapi tidak sepanjang waktu, dan itu bisa dilakukan dengan cara lain.

Sebagian besar waktu dengan membuat kelas dasar abstrak dan membuat implementasi konkret dari kelas itu.

Juga banyak kerangka kerja yang menggunakan pewarisan untuk menyediakan penggunaan kembali kode (Delphi, Java, .Net hanyalah beberapa yang langsung muncul dalam pikiran).

Itu tidak berarti bahwa banyak perpustakaan utilitas dan cuplikan kode tidak dapat melakukan pekerjaan dengan baik, tetapi ada sesuatu yang menyenangkan tentang hierarki objek yang dirancang dengan baik.

3
Chris Buckett

Dalam pengalaman saya, saya telah lebih berhasil meningkatkan kode "dapat digunakan kembali" melalui fasilitas pemrograman generik (seperti templat C++) daripada menggunakan prinsip OOP seperti hierarki warisan.

3
Charles Salvia

OOP terlalu terbuka untuk digunakan kembali secara efektif.

Ada terlalu banyak cara untuk digunakan kembali. Setiap kelas publik bertanya: "buat instance baru saya!", setiap metode publik mengatakan: "panggil aku!", setiap metode yang diproteksi menghasilkan: = "timpa saya!" - dan semua cara penggunaan ulang ini adalah berbeda , mereka memiliki parameter yang berbeda, mereka muncul dalam berbagai konteks, semua memiliki aturan yang berbeda, bagaimana memanggil/memperluas/menimpanya.

[~ # ~] api [~ # ~] lebih baik, ini adalah subset ketat dari OOP (atau non -oop) poin, tetapi dalam kehidupan nyata, API mengalami kelebihan fungsi dan terus berkembang, masih ada terlalu banyak titik koneksi. Juga, API yang baik dapat membuat hidup lebih mudah, itu adalah cara terbaik untuk menyediakan antarmuka untuk OOP.


Paradigma datadlow menyediakan antarmuka yang ketat untuk komponen, mereka memiliki port jenis berikut:

  • konsumen (input), dan
  • produsen (keluaran).

Tergantung pada domain, ada beberapa jenis paket, sehingga konsumen dan produsen dapat terhubung jika mereka memiliki port yang sama (atau kompatibel). Bagian yang paling indah dari itu, yang dapat dilakukan secara visual, karena tidak ada parameter atau tweak pada koneksi, mereka benar-benar hanya menghubungkan konsumen dan produsen.

Saya agak tidak jelas, Anda dapat melihat tag "dataflow" pada StackOverflow , atau Wikipedia "pemrograman datafow" atau Wikipedia "pemrograman berbasis aliran " .

(Juga, saya telah menulis sistem dataflow, di C++. Jadi OOP dan DF bukan musuh, DF adalah cara organisasi tingkat yang lebih tinggi.)

2
ern0

Di CommonLisp ada banyak cara untuk mencapai penggunaan kembali:

  • pengetikan dinamis, membuat kode Anda menjadi umum secara default

  • abstraksi imperatif, yaitu subrutin

  • objek-orientasi, dengan banyak pewarisan dan beberapa pengiriman

  • sintaks-abstraksi, kemampuan untuk mendefinisikan konstruksi sintaksis baru atau menyingkat kode boiler-plate

  • abstraksi fungsional, penutup dan fungsi tingkat tinggi

Jika Anda mencoba membandingkan pengalaman CommonLisp dengan bahasa lain, Anda akan melihat bahwa fitur utama yang memudahkan penggunaan kembali kode adalah kehadiran keduanya berorientasi objek dan abstraksi fungsional. Mereka lebih komplementer daripada alternatif: tanpa salah satu dari mereka Anda terpaksa menerapkan kembali fitur yang hilang dengan cara canggung. Lihat, misalnya, kelas functor yang digunakan sebagai penutupan dan pencocokan pola untuk mendapatkan metode pengiriman non-extensible.

2
Andrea

OOP memberi Anda lebih banyak cara untuk menggunakan kembali kode. Itu semuanya.

1
Steven A. Lowe

Tidak ada yang namanya "menggunakan kembali" cara orang menggambarkannya. Penggunaan kembali adalah kebetulan properti apa pun. Sulit untuk merencanakannya. Apa yang kebanyakan orang maksudkan ketika mereka berbicara tentang "reuse" adalah "use". Ini istilah yang jauh lebih menarik dan tidak menarik. Ketika Anda menggunakan perpustakaan, Anda menggunakannya untuk apa yang dimaksudkan, biasanya. Anda tidak menggunakannya kembali kecuali Anda melakukan sesuatu yang benar-benar gila dengannya.

Dalam arti itu, penggunaan kembali di dunia nyata adalah tentang hal-hal yang bertujuan kembali. Saya dapat menggunakan kembali kursi ini di sini dan mengaturnya kembali untuk membentuk ... tempat tidur! Bukan tempat tidur yang sangat nyaman, tetapi saya bisa melakukannya. Itu bukan penggunaan utama mereka. Saya menggunakan kembali mereka di luar domain penerapan asli. [...] Besok, saya akan terbang kembali ke Inggris. Saya akan tidak menggunakan kembali pesawat. Saya hanya akan menggunakannya untuk tujuan yang dimaksudkan, tidak ada yang mewah atau menarik tentang hal itu.

- Kevlin Henney

1
fredoverflow

Penggunaan Kembali Horisontal: aspek, sifat, cangkok

Klasik OO terkadang gagal dalam penggunaan kembali kode, khususnya ketika Anda menjadi gila karena kurangnya cara yang lebih baik untuk berbagi fungsionalitas aktual antar kelas. Untuk masalah ini, mekanisme penggunaan kembali horisontal telah dibuat, seperti AOP, sifat dan cangkok.

Pemrograman Berorientasi Aspek

Saya menganggap AOP sebagai setengah oranye yang hilang dari OOP. AOP tidak benar-benar diketahui, tetapi telah membuatnya menjadi kode produksi.

Saya akan coba menjelaskannya dalam istilah sederhana: bayangkan Anda dapat menyuntikkan dan memfilter fungsionalitas dengan struktur khusus yang disebut aspek, aspek-aspek ini memiliki "metode" yang menentukan apa dan bagaimana akan dipengaruhi melalui refleksi , tetapi pada waktu kompilasi, proses ini disebut menenun .

Contoh akan menjadi aspek yang memberitahu "untuk semua metode kelas tertentu yang dimulai dengan get, program Anda akan menulis ke file log data yang didapat dan waktu mendapatkannya".

Tonton dua pembicaraan ini jika Anda ingin lebih memahami AOP:

Ciri & Graft

Traits adalah konstruksi lain untuk mendefinisikan kode yang dapat digunakan kembali yang melengkapi OOP, mereka mirip dengan mixins , tetapi lebih bersih.

Daripada menjelaskannya, ada RFC PHP hebat yang menjelaskan keduanya . Ciri datang ke PHP btw, mereka sudah berkomitmen untuk trunk.

Singkatnya

OOP adalah kunci dalam modularitas, tetap, menurut saya dan seperti yang kita kenal sekarang OOP masih belum lengkap .

1
dukeofgaming

Saya akan mengambil risiko cemoohan dan mengaku, saya hanya menggunakan OOP baru-baru ini. Itu tidak datang kepada saya secara otomatis. Sebagian besar pengalaman saya melibatkan basis data relasional, jadi saya pikir dalam tabel dan bergabung. Ada klaim bahwa lebih baik untuk mempelajarinya dari awal yang menghindari harus mengubah pemikiran Anda ketika datang ke pemrograman. Saya tidak memiliki kemewahan itu dan menolak untuk membatalkan karir saya karena teori menara gading. segalanya, saya akan mencari tahu.

Awalnya saya pikir keseluruhan konsep itu tidak masuk akal. Sepertinya tidak perlu dan terlalu banyak kesulitan. Saya tahu, ini pembicaraan gila. Jelas dibutuhkan tingkat pemahaman tertentu sebelum Anda dapat menghargai manfaat apa pun atau mengabaikannya untuk metode yang lebih baik.

Penggunaan kembali kode membutuhkan kemauan untuk tidak mengulangi kode, pemahaman tentang bagaimana mencapainya, perencanaan awal. Haruskah Anda menghindari menggunakan kembali kode ketika Anda memutuskan Anda memiliki kasus di mana itu tidak layak? Dan tidak ada bahasa yang sangat ketat OO sehingga akan menimbulkan kesalahan ketika ia berpikir Anda seharusnya mewarisi kode dari kelas lain. Paling-paling mereka menyediakan lingkungan yang kondusif untuk mengimplementasikannya.

Saya pikir manfaat terbesar dari OOP adalah penerimaan umum tentang bagaimana kode harus diatur. Yang lain adalah saus. Tim programmer mungkin tidak sepenuhnya setuju tentang bagaimana semua kelas harus disusun, tetapi mereka harus dapat menemukan kode.

Saya telah melihat kode prosedural yang cukup untuk mengetahui bahwa itu bisa di mana saja, dan kadang-kadang ada di mana-mana.

1
JeffO

Membaca posting di atas, beberapa komentar:

  • Banyak yang berpikir bahwa kode digunakan kembali dalam OOP menyiratkan pewarisan. Saya tidak setuju. Antarmuka dan kontrak adalah inti dari penggunaan kembali kode dalam OOP sistem. OOP adalah upaya kotak abu-abu dalam menciptakan teknologi komponen.
  • Perbedaan antara "kerangka" domain spesifik dan umum sebagai subjek penggunaan kembali menganggap saya terlalu abstrak. Dalam pandangan saya tentang hal-hal, komponen (kontrak antarmuka singkat, minimal dan dapat digunakan kembali dan implementasi di belakang) hanya dapat dilakukan, jika masalah yang ditangani dipahami dengan baik. Komponen khusus domain, yang memungkinkan pakar non-domain untuk melakukan pekerjaan mereka dengan sedikit pengetahuan tentang domain adalah komponen (kembali) yang bermanfaat. Pengguna perlu memahami antarmuka, kurang dari kerumitan domain masalah.
  • Tingkat penggunaan ulang yang sering dilupakan: Penggunaan kembali ide, Penggunaan ulang spesifikasi, Penggunaan kembali arsitektur/Desain, Penggunaan ulang antarmuka, Penggunaan ulang case-test. Penggunaan kembali kode tidak selalu menguntungkan. Tetapi ini adalah penghemat waktu yang besar untuk tetap berpegang pada arsitektur tertentu untuk menangani produk baru yang serupa.
  • The OOP Pola desain (Gamma et. Al) di mata saya menguraikan teknik implementasi taktis daripada menjadi bermakna dalam konteks penggunaan kembali kode pada skala yang lebih besar. Mereka membantu menulis aplikasi dengan OOP elemen, namun saya tidak akan melihatnya sebagai solusi untuk pertanyaan "penggunaan kembali kode" di luar satu aplikasi.
  • Mungkin itu tidak adil: 20 tahun pengalaman C/C++/C # dan pemrograman fungsional 6 bulan (F #). Salah satu elemen utama memungkinkan penggunaan kembali adalah: Orang perlu dengan mudah menemukan "antarmuka", mempelajarinya, memahaminya, lalu menggunakannya. Pemrograman fungsional murni tidak membuatnya mudah bagi saya untuk melihat struktur, kandidat untuk digunakan kembali atau di mana semuanya dimulai dan di mana semuanya berakhir. "Gula sintaksis" yang begitu dipuji itu seringkali adalah garam di mata saya, mencegah saya untuk dengan mudah melihat apa yang terjadi. Dengan demikian saya akan cenderung mencoba menggunakan kembali fungsional (apa itu - banyak fungsi?), Yang mungkin memiliki efek samping tersembunyi yang bahkan tidak dapat saya lihat (evaluasi malas, monad, ...). Jangan salah paham, pemrograman fungsional memiliki sisi yang sangat keren, tetapi semua kekuatan yang dicanangkan saya lihat dengan keraguan yang baik. Saya sangat ingin tahu apa yang membawa masa depan pasca-fungsional dan berharap untuk melihatnya sebelum saya pensiun;)
  • Spesifikasi, Desain, Implementasi digabungkan, namun tidak mudah dilihat traversable pada "hal yang sama". Jauh lebih penting untuk meningkatkan produktivitas di masa depan daripada paradigma pemrograman baru, untuk menutup kesenjangan, untuk meningkatkan (penalaran otomatis, ketertelusuran) saling menguntungkan antara pandangan-pandangan tersebut. Bahasa spesifikasi yang diformalkan, notasi pengujian standar (mis. Ttcn3) dan bahasa pemrograman yang mendukung verifikasi antarmuka dan kontrak dengan spesifikasi tanpa pengotoran komentar mungkin adalah hal yang paling kita butuhkan saat ini.
0
BitTickler

Masalahnya adalah imho yang lebih halus:

  1. OOP adalah metode hebat untuk menyusun kode dengan status yang bisa berubah. Dengan merangkum negara menjadi objek, kode statefull imperatif menjadi lebih dapat dimengerti karena, misalnya, jika sepotong negara dinyatakan sebagai bidang pribadi kelas, Anda tahu bahwa setidaknya bagian tertentu dari negara hanya dapat dimodifikasi dengan metode kelas ini. (Dan Anda dapat dengan mudah menghancurkan manfaat ini dengan menyalahgunakan warisan, btw.) Ini sekarang sudah cukup, tetapi waaay lebih baik daripada tidak memiliki ini.
  2. kode dengan status tidak bisa diubah secara inheren sulit untuk digunakan kembali. Jauh lebih sulit daripada kode menggunakan struktur data yang tidak berubah.

Jadi OOP itu sendiri tidak buruk dari pov membuat kode dapat digunakan kembali, tapi jenis kode yang ditulis menggunakan OOP secara inheren sulit untuk digunakan kembali.

Juga, pemrograman fungsional dapat menghasilkan kode yang lebih dapat digunakan kembali . Tetapi mendapatkan abstraksi yang tepat untuk menulis kode fungsional yang waras sambil memenuhi tenggat waktu mungkin tidak bisa dilakukan. Dan abstraksi "setengah benar" akan lebih mudah untuk mengekspresikan OOP gaya. Dan itu tidak akan cenderung menghasilkan lebih mudah untuk menggunakan kembali kode - level abstraksi yang lebih tinggi berarti bahwa pemahaman kode akan memerlukan investasi dimuka yang lebih tinggi dari kapasitas kognitif programmer yang terbatas.

Sebagai contoh praktis: Kode gim melibatkan banyak keadaan yang bisa berubah, karena ini adalah cara alami untuk berpikir tentang penyandian gim, kecuali gim ini sangat teka-teki/algoritmik, sehingga jelas terstruktur menggunakan OO. Dan tentu saja sulit untuk digunakan kembali. Tetapi kode yang sama, mengandung pengetahuan yang sama, akan lebih sulit untuk digunakan kembali tanpa OOP. Dan menulis ulang menjadi gaya fungsional mungkin perlu benar-benar mengubah cara Anda berpikir tentang kode itu, pengetahuan di baliknya. Ya, hasilnya pengetahuan di balik kode akan jauh lebih jelas setelah OO hingga FP tulis ulang mungkin ... tetapi biayanya bisa sangat besar dan mungkin jenis biaya yang juga harus dibayar oleh orang-orang ingin menggunakan kembali kode yang luar biasa cerdas dan abstrak yang Anda dapatkan , jadi secara paradoksal, orang akhirnya tidak akan menggunakan kembali kode tersebut, meskipun secara teknis lebih dapat digunakan kembali.

... yang mengarah ke kehalusan terakhir: penggunaan kembali kode adalah tentang antarmuka People | Code, bukan tentang kode saja. OOP melakukan pekerjaan yang layak untuk melayani antarmuka ini karena memetakan dengan baik dengan berapa banyak orang berpikir tentang berbagai jenis kode yang ditulis saat ini. FP mungkin lebih baik untuk kode) digunakan kembali, tetapi sebaiknya tidak untuk dengan mudah menggunakan kembali jenis kode yang sebenarnya orang perlu tulis saat ini. Ini akan berubah sebagai jenis kode yang perlu kita tulis perubahan.

P.S. Dan jika ada yang ingin mengatakan bahwa "OO bukan tentang keadaan bisa berubah, Anda juga dapat memiliki OO dengan keadaan tidak berubah" ... Saya menyebutnya "FP menggunakan kelas sebagai ruang nama". Sangat bagus ketika itu bekerja untuk Anda dan menghindari beberapa kekurangan dari sistem modul beberapa bahasa dan dapat menghasilkan kode yang lebih dapat digunakan kembali. Tapi itu tidak OO;)

0
NeuronQ

OOP Menyediakan seperangkat alat yang berguna yang memungkinkan Anda untuk menulis kode yang dapat digunakan di lebih banyak tempat daripada yang bisa Anda miliki tanpa alat itu. Jika Anda menulis fungsi PrintIt yang mengambil objek lama dan memanggil .toString() di atasnya, Anda akan menggunakan kembali kode itu segera setelah Anda memanggilnya dengan lebih dari satu jenis objek. Dengan alat-alat ini, setiap baris kode melakukan lebih banyak.

Pemrograman fungsional sangat panas sekarang di antara para hipsters. Ini memberi Anda seperangkat alat yang terpisah untuk membuat setiap baris kode berbuat lebih banyak. Mungkin tidak lebih baik atau berfungsi, tetapi menyediakan alat lain di kotak alat.

(Ada ide gila untuk seluruh tingkat tambahan penggunaan kembali berorientasi objek: Idenya adalah bahwa kita dapat mendefinisikan kelas tunggal Customer dan menggunakannya dalam setiap aplikasi yang kita tulis. Kemudian aplikasi hanya akan menjadi sedikit lem di sana-sini. Ini tidak berhasil. Tapi itu tidak berarti OO Gagal, atau bahkan Penggunaan Ulang gagal. Jenis dasar penggunaan kembali dalam aplikasi memungkinkan untuk menulis aplikasi yang melakukan lebih banyak, dan untuk menulis lebih cepat.)

0
Sean McMillan