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


56

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

Apakah kode digunakan kembali ketika 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? Adakah metode yang lebih baik untuk mencapai penggunaan kembali kode daripada orientasi objek, sub-klasifikasi, polimorfisme, dll.? Cara apa yang lebih baik? Mengapa ?

Ceritakan pengalaman Anda dengan OOP reuse atau paradigma lain reuse.



7
Ini komplementer, bukan duplikat tepat. Saya ulangi untuk lebih memahami perbedaannya.
Maniero

Jika Anda dapat memilih dan berpikir ini adalah pertanyaan yang berguna atau memiliki jawaban yang berguna di bawah ini, silakan pilih. Situs StackExchange membutuhkan suara untuk membangun komunitas yang baik. Anda dapat memberikan 30 suara per hari, jangan sia-siakan. Khusus pengguna dengan reputasi tinggi dan penghitungan suara rendah diberikan, harap baca ini: meta.programmers.stackexchange.com/questions/393/…
Maniero


2
@j_random_hacker: baca komentar.
Maniero

Jawaban:


34

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 ini penuh dengan kode; bagaimana bisa menemukan yang Anda inginkan? Inilah yang saya sebut Kutukan Penggunaan Kembali :

Saya Santa Claus (ok Open Source), dan saya memiliki 1 miliar komponen perangkat lunak. Anda dapat memiliki salah satu dari mereka.

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 memberikan bantuan lain).
  • semua ini jelas lebih murah daripada hanya pengodean ulang itu

Sebagian besar yang telah ditemukan selama bertahun-tahun adalah bahwa 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 jadi 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 dengan baik, diimplementasikan dan didokumentasikan. Tetapi orang-orang tidak melihat kode sumber di perpustakaan; mereka hanya memanggil API yang terdokumentasi dengan baik (dirancang agar 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 kuncinya adalah bahwa segala jenis penggunaan kembali kode pada dasarnya terbatas karena kode memiliki terlalu banyak asumsi . 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 diikat 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.

Salah 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 menerapkan transformasi program pada mereka.

Compiler sudah melakukan ini: -} Dan mereka benar-benar 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 sudah 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 dari "spesifikasi" untuk DMS, tetapi memiliki 10MSLOC kode yang dihasilkan.

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


4
IMHO, Jawaban terbaik. Yang penting diketahui / ide digunakan kembali, bukan kode.
kravemir

4
Mostly what has been discovered over the years is that for code to be reusable, it sort of has to be designed for that purpose, or it contains too many implicit assumptions.Saya telah mencapai kesimpulan yang sama tetapi saya tidak bisa mengungkapkannya dengan ringkas.
biziclop

36

Penggunaan kembali kode dicapai dalam OOP tetapi juga dicapai dalam pemrograman fungsional. Kapan saja Anda mengambil blok kode dan membuatnya dapat dihubungi oleh seluruh kode Anda sehingga Anda dapat menggunakan fungsi ini di tempat lain adalah penggunaan kembali kode.

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 di sana hanya untuk menyediakan kembali kode. Saya melihat OOP sebagai lebih dari cara untuk berinteraksi dengan objek dan abstrak jauh rincian 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 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 mandiri dari logika pemrograman yang dapat digunakan sendiri, memungkinkan kolaborasi melalui penggunaan modul terkait (subrutin). Pendekatan yang lebih konvensional ini, yang masih bertahan, cenderung mempertimbangkan data dan perilaku secara terpisah.


9
+1 pemrograman fungsional mungkin merupakan cara untuk menggunakan kembali kode.
Jonas

1
@ Matthieu M .: Ya, bagaimana bisa digunakan kembali double sqrt (double x)? Fungsi murni adalah pola dasar penggunaan kembali.
Joonas Pulakka

3
@Joonas: double sqrt(double x), float sqrt(float x), int sqrt(int x)Anda dapat menentukan banyak dari mereka, sementara dengan bahasa Pemrograman Generik Anda harus Number sqrt(Number x)dan dilakukan dengan hal itu.
Matthieu M.

1
@ Matthieu M .: Memang, obat generik mengurangi replikasi kode, jadi "lebih bisa digunakan kembali", ya. Namun, saya pikir kunci nyata untuk usabilitas adalah mendefinisikan fungsi-fungsi sederhana, kecil, waras, murni (ini adalah arah "pemrograman fungsional"), dan meneruskannya, yang mungkin dalam C. Ini lebih tentang gaya pemrograman umum daripada tentang kemampuan bahasa itu sendiri.
Joonas Pulakka

1
@ Joonas: Ah, saya telah melewatkan kata murni , Anda benar, membuat fungsi murni kecil sangat bagus, dan bahkan fitur C pointer ke fungsi untuk itu.
Matthieu M.

15

Iya 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 cermat, sehingga menghilangkan kode duplikat sebanyak mungkin dan disarankan. Namun, Anda dapat berpendapat 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. Penggunaan kembali kode lintas-tujuan Janji penggunaan kembali kode terbesar dari OO adalah kode itu, setelah ditulis untuk satu aplikasi nantinya dapat digunakan kembali untuk aplikasi lain, yang tidak dirancang khusus untuk itu. Ini semua adalah kemarahan ketika gagasan OO disaring melalui pintu kantor manajemen yang lebih tinggi, dan OO benar-benar gagal mencapainya. Ternyata tujuan itu adalah aspek penting dari desain OO (dan mungkin semua kode prosedural, tapi itu hanya teori saya) dan upaya repurposing code berakhir dengan bencana pemeliharaan. (Antipatterns yang terkenal dari kerangka kerja lama yang tidak seorang pun berani untuk memodifikasi dan temannya, kerangka kerja yang sedikit berbeda untuk setiap aplikasi biasanya berasal dari sini.)

13

Saya akan mengirim jawaban yang panjang tetapi 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 bahkan melangkah lebih jauh dengan mengatakan bahwa seluruh titik orientasi objek digunakan kembali - bukan, enkapsulasi adalah hal besar. Setelah itu komponen-orientasi adalah hal yang seharusnya digunakan kembali. Rupanya itu tidak berjalan dengan baik karena di sini kita sekarang menggantungkan harapan kita yang reuseful 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


4
-1. Pak Dahan sibuk dengan sedotan; tidak ada yang serius menggunakan kembali kode non-generik seperti yang ia maksudkan, dan jika Anda menghapus argumen itu dari artikelnya, ia sebenarnya mendukung atau menggunakan kembali kode dengan tepat .
Steven A. Lowe

3
@ Sebelas A. Lowe Ya saya berharap itu benar. Saya berharap saya beruntung karena saya telah melihat kode digunakan kembali dalam bentuk non-generik. Itu tidak cantik.
Tony

1
Saya yakin itu bukan - tetapi apakah mereka serius ? dilbert.com/strips/comic/1996-01-31
Steven A. Lowe

1
Setuju, biaya membuat kode dapat digunakan kembali benar-benar tinggi, sehingga tidak membuahkan hasil kecuali Anda berbicara tentang skala kelas dasar Java atau .NET. Lihat youtube.com/watch?v=aAb7hSCtvGw
Andomar

13

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 di dunia OOP, tetapi ini dapat dicapai dengan fungsi rekursif dan pencocokan pola dalam bahasa pemrograman fungsional. Untuk lebih lanjut tentang ini, lihat bab pertama dalam Pemrograman Fungsional Dunia Nyata .

Saya pikir warisan dalam OOP bisa menyesatkan dalam banyak kasus. Anda memiliki kelas dan banyak metode terkait erat diimplementasikan dalam file yang berbeda. Seperti yang dikatakan Joe Armstrong 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 misalnya mapdan foldritu adalah dasar untuk Google MapReduce .

Melewati pesan asinkron 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 Tell, jangan tanyakan prinsip OOP. Lihat lebih lanjut tentang ini di Pemrograman Berorientasi Objek: The Wrong Path? adalah Joe Armstrong adalah 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 yakin apakah saya percaya ini atau tidak, tetapi Erlang mungkin satu-satunya bahasa berorientasi objek karena 3 prinsip pemrograman berorientasi objek adalah bahwa itu didasarkan pada pesan yang lewat , bahwa Anda memiliki isolasi antara objek dan memiliki polimorfisme .

Melewati pesan yang tidak sinkron seperti pada sistem yang digerakkan oleh peristiwa dan di Erlang juga merupakan cara yang sangat baik untuk memisahkan sistem dan pelepasan longgar adalah 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 yang luar biasa tentang ini: Domain Event Driven Architecture

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


2
Saya suka kutipan Gorilla itu. ^^
gablin

Saya pikir pertanyaannya adalah tentang penggunaan kembali kode, bukan semantik yang bagus ..?
Daniel Lubarov

6

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 ke dalamnya. 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.


4

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


4

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 sebanyak pemrograman fungsional.


1
Kesimpulan Anda semua salah, @ Lenny222. Tidak ada apa-apa tentang OOP yang mengharuskan kelas untuk mempertahankan status. Itu pertanyaan arsitekturnya apakah ia menyimpan state secara internal atau, seperti kelas Integer Smalltalk, membuat objek baru dengan state baru.
Huperniketes

1
Saya menyesal karena saya belum menyatakan diri saya dengan cara yang telah mencegah kesalahpahaman ini: apa yang saya maksudkan adalah bahwa perbedaan antara OOP dan FP bukan karena kode OOP ecourages menggunakan kembali lebih dari FP (apa yang tersirat pada judul). Saya telah mengalami penggunaan kembali kode yang jauh lebih baik dengan FP. Jika Anda hanya memiliki kelas yang tidak berubah, Anda meniru FP, mengapa OOP di tempat pertama? Dalam POV saya ini tentang manajemen negara yang sangat penting.
LennyProgrammers

3

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 bukan untuk mengatakan bahwa banyak perpustakaan utilitas dan potongan kode tidak bisa melakukan pekerjaan dengan baik, tetapi ada sesuatu yang menyenangkan tentang hierarki objek yang dirancang dengan baik.


3

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


2

OOP terlalu terbuka untuk digunakan kembali secara efektif.

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

API lebih baik, ini adalah subset ketat dari poin OOP (atau non-oop), tetapi dalam kehidupan nyata, API mengalami kelebihan kapasitas dan terus berkembang, masih ada terlalu banyak titik koneksi. Juga, API yang baik dapat membuat hidup lebih mudah, ini 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 pada tag "dataflow" di 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

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 pewarisan berganda dan pengiriman ganda

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

  • abstraksi fungsional, penutup dan fungsi tingkat tinggi

Jika Anda mencoba untuk membandingkan pengalaman CommonLisp ke bahasa lain Anda akan melihat bahwa fitur utama bahwa kode mereda reuse adalah kehadiran kedua berorientasi objek dan fungsional abstraksi. 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.


1

Tidak ada yang namanya "menggunakan kembali" cara orang menggambarkannya. Penggunaan kembali adalah properti tidak disengaja dari 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 pengertian 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 mereka di luar domain asli penerapannya. [...] Besok, saya akan terbang kembali ke Inggris. Saya tidak akan menggunakan kembali pesawat. Saya hanya akan menggunakannya untuk tujuan yang dimaksudkan, tidak ada yang mewah atau menarik tentang itu.

- Kevlin Henney


3
Orang akan percaya apa pun yang mereka lihat di media cetak Kevlin Henney salah dan mendasarkan alasannya pada kurangnya konteks historis dan interpretasi semantik yang buruk. Penggunaan kembali kode adalah prinsip pemrograman mendasar dari zaman UNIVAC dan komputer tabung hampa IBM. Menggunakan kembali kode bukan tentang mengarahkan ulang untuk beberapa fungsi selain dari yang sudah direncanakan . Anda menulis dan mengumpulkan (kemudian dikompilasi) sub-rutin Anda untuk menghasilkan kode objek yang kemudian ditautkan ke program Anda. Penggunaan kembali benar-benar berarti apa yang biasa diartikan dalam industri saat ini.
Huperniket

Jika Anda menulis dua fungsi yang melakukan hal yang persis sama, Anda TIDAK menggunakan kembali kode terlepas dari berapa kali Anda menggunakannya.
JeffO

Analogi kursi bagus dan semua itu, tetapi hanya satu kata: Lego.
biziclop

1

Saya akan mengambil risiko ejekan 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. Seperti yang lainnya, 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 begitu 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 lainnya adalah saus. Sebuah 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.


"Dan tidak ada bahasa yang begitu ketat OO sehingga akan menimbulkan kesalahan ketika ia berpikir Anda seharusnya mewarisi kode dari kelas lain" - belum, lagian!
Steven A. Lowe

1

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


OOP juga mempromosikan penggunaan kembali antarmuka dan penggunaan kembali desain.
rwong

Ini memberi saya jauh lebih sedikit cara menulis kode generik, dapat digunakan kembali, sangat abstrak daripada paradigma lain, seperti pemrograman fungsional (mind currying, perpustakaan kombinator, dll.) Dan metaprogramming. Sebenarnya, OOP tampaknya memiliki tingkat cangkir abstraksi, ketika alternatifnya tidak terbatas sama sekali.
SK-logic

@ SK-logic: orthogonal.
Steven A. Lowe

1

Penggunaan Kembali Horisontal: aspek, sifat, cangkok

Klasik OO terkadang gagal dalam penggunaan kembali kode, khususnya ketika Anda menjadi gila karena tidak memiliki 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 tenun .

Sebuah 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

Ciri - ciri adalah konstruksi lain untuk mendefinisikan kode yang dapat digunakan kembali yang melengkapi OOP, mereka mirip dengan mixin , tetapi lebih bersih.

Daripada menjelaskannya, ada PHP RFC 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 .


0

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 PrintItfungsi yang mengambil objek lama dan memanggilnya .toString(), Anda akan menggunakan kembali kode itu segera setelah Anda menyebutnya 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 satu Customerkelas dan menggunakannya dalam setiap aplikasi yang kita tulis. Kemudian aplikasi hanya akan menjadi lem kecil di sana-sini. Ini tidak berfungsi. Tetapi itu tidak berarti OO Gagal, atau bahkan Penggunaan ulang gagal. Jenis dasar penggunaan kembali dalam aplikasi memungkinkan untuk menulis aplikasi yang berbuat lebih banyak, dan untuk menulisnya lebih cepat.)


0

Membaca posting di atas, beberapa komentar:

  • Banyak yang berpikir bahwa penggunaan kembali kode dalam OOP menyiratkan pewarisan. Saya tidak setuju. Antarmuka dan kontrak adalah inti dari penggunaan kembali kode dalam sistem OOP. OOP adalah upaya kotak abu-abu dalam menciptakan teknologi komponen.
  • Perbedaan antara "kerangka kerja" 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 kembali 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.
  • Pola Desain OOP (Gamma et. Al) di mata saya menguraikan teknik implementasi taktis daripada menjadi bermakna dalam konteks kode yang digunakan kembali pada skala yang lebih besar. Mereka membantu menulis aplikasi dengan elemen OOP, 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 sering kali 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.
  • Spesifikasi, Desain, Implementasi digabungkan, namun tidak mudah ditinjau pandangan tentang "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 uji standar (misalnya ttcn3) dan bahasa pemrograman yang mendukung verifikasi antarmuka dan kontrak terhadap spesifikasi tanpa pengotoran komentar mungkin yang paling kita butuhkan saat ini.

0

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 ini hanya dapat dimodifikasi dengan metode ini. kelas. (Dan Anda dapat dengan mudah menghancurkan manfaat ini dengan menyalahgunakan warisan, btw.) Sekarang sudah cukup, tetapi mungkin lebih baik daripada tidak memiliki ini.
  2. kode dengan keadaan bisa berubah 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 , tetapi 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 gaya OOP. Dan itu tidak akan cenderung menghasilkan lebih mudah untuk menggunakan kembali kode - tingkat abstraksi yang lebih tinggi berarti bahwa pemahaman kode akan memerlukan investasi dimuka yang lebih tinggi dari kapasitas kognitif terbatas pemrogram.

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, yang berisi pengetahuan yang sama, akan lebih sulit untuk digunakan kembali tanpa OOP . Dan menulis ulang menjadi gaya fungsional mungkin perlu mengubah cara Anda berpikir tentang kode itu, pengetahuan di baliknya. Ya, pengetahuan yang dihasilkan di balik kode akan jauh lebih jelas setelah OO ke FP menulis ulang mungkin ... tapi biayanya bisa sangat besar dan mungkinjenis biaya yang juga harus dibayar oleh orang-orang yang ingin menggunakan kembali kode yang luar biasa cerdas dan abstrak yang Anda dapatkan , sehingga secara paradoksal, orang akhirnya tidak 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 hanya tentang kode. 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 menggunakan kembali kode, tetapi 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.

PS 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". Ini bagus ketika bekerja untuk Anda dan menghindari beberapa kekurangan sistem modul beberapa bahasa dan dapat menghasilkan kode yang lebih dapat digunakan kembali. Tapi itu bukan OO;)

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.