it-swarm-id.com

Keuntungan pemrograman berorientasi objek

Catatan : pertanyaan ini adalah kutipan yang diedit dari posting blog Saya menulis beberapa bulan yang lalu. Setelah menempatkan tautan ke blog dalam komentar pada Programmers.SE seseorang meminta saya mengirim pertanyaan di sini sehingga mereka dapat menjawabnya. Posting ini adalah yang paling populer, karena orang-orang sepertinya mengetik "Saya tidak mendapatkan pemrograman berorientasi objek" ke Google banyak. Jangan ragu untuk menjawab di sini, atau dalam komentar di Wordpress.

Apa itu pemrograman berorientasi objek? Tidak ada yang memberi saya jawaban yang memuaskan. Saya merasa seperti Anda tidak akan mendapatkan definisi yang baik dari seseorang yang berkeliling mengatakan "objek" dan "berorientasi objek" dengan hidungnya di udara. Anda juga tidak akan mendapatkan definisi yang baik dari seseorang yang tidak melakukan apa pun selain pemrograman berorientasi objek. Tidak ada orang yang mengerti pemrograman prosedural dan berorientasi objek yang pernah memberi saya ide yang konsisten tentang apa yang sebenarnya program berorientasi objek.

Dapatkah seseorang tolong beri saya ide-ide mereka tentang manfaat pemrograman berorientasi objek?

35
Joel J. Adamson

Pikirkan perangkat lunak sebagai mesin atau jalur Perakitan yang ada di dalam komputer. Beberapa bahan baku dan komponen dimasukkan ke dalam mesin, dan mengikuti serangkaian prosedur untuk memprosesnya menjadi beberapa produk akhir. Prosedur diatur untuk melakukan operasi tertentu pada beberapa bahan mentah atau komponen ke serangkaian parameter tertentu (misalnya, waktu, suhu, jarak, dll) dalam urutan tertentu. Jika detail operasi yang dilakukan salah, atau sensor mesin tidak dikalibrasi dengan benar, atau jika beberapa bahan baku atau komponen tidak sesuai dengan standar kualitas yang diharapkan, itu dapat mengubah hasil operasi dan produk tidak akan berubah seperti yang diharapkan.

Mesin seperti itu sangat kaku dalam operasinya dan input yang dapat diterima. Mesin tidak mempertanyakan kecerdasan desainer atau lingkungan operasinya saat ini. Itu akan terus mengikuti prosedur selama itu diarahkan. Bahkan jika perubahan bahan baku atau komponen dapat memiliki efek dramatis pada apa yang terjadi di operasi selanjutnya, mesin tetap akan melakukan prosedurnya. Proses tersebut perlu ditinjau untuk melihat perubahan apa pada prosedur yang diperlukan untuk mengkompensasi dan menghasilkan hasil yang diinginkan. Perubahan pada desain atau konfigurasi produk mungkin juga memerlukan perubahan signifikan pada operasi yang dilakukan atau pesanan mereka. Meskipun mereka yang bertanggung jawab atas produksi dengan cepat mempelajari pentingnya mengisolasi operasi sebanyak mungkin untuk mengurangi efek yang tidak diinginkan di antara mereka, banyak asumsi dibuat dari komponen kondisi saat mereka menjalani pemrosesan; asumsi yang mungkin tidak terdeteksi hingga produk akhir ada di tangan pengguna di beberapa lingkungan operasi yang berbeda.

Seperti itulah pemrograman prosedural itu.

Apa yang diberikan orientasi objek adalah cara untuk menghilangkan asumsi kondisi komponen; dengan demikian, operasi yang akan dilakukan pada komponen itu dan bagaimana mengintegrasikannya ke dalam produk akhir. Dengan kata lain, OOP seperti mengambil detail proses untuk berurusan dengan beberapa komponen tertentu dan memberikannya kepada mesin yang lebih kecil untuk dikerjakan. Mesin yang lebih besar yang bertanggung jawab atas proses tersebut memberitahu mesin khusus komponen yang operasi yang diharapkan dilakukan tetapi meninggalkan detail untuk langkah-langkah yang harus ditangani oleh mesin khusus komponen.

Adapun keuntungan dari orientasi objek daripada perangkat lunak yang tidak berorientasi objek:

  • perilaku spesifik-komponen - membuat perincian tentang bagaimana menangani komponen tertentu, tanggung jawab mesin spesifik-komponen yang lebih kecil memastikan setiap saat komponen ditangani, mesinnya akan melakukannya dengan tepat;
  • ekspresi polimorfik - karena mesin khusus komponen melakukan operasi yang disesuaikan dengan komponen khususnya, pesan yang sama dikirim ke mesin yang berbeda dapat bertindak berbeda;
  • type abstraction - sering masuk akal untuk beberapa jenis komponen untuk menggunakan kosakata yang sama untuk operasi yang dilakukan mesin mereka;
  • pemisahan masalah - meninggalkan detail spesifik komponen ke mesin mereka berarti mesin proses hanya perlu menangani masalah yang lebih umum, lebih besar dari prosesnya dan data yang diperlukan untuk mengelolanya; ditambah lagi, kecil kemungkinannya akan terpengaruh oleh perubahan komponen lain;
  • kemampuan beradaptasi - komponen yang fokus pada bidang spesialisasi mereka dapat disesuaikan dengan penggunaan yang tidak terduga hanya dengan mengubah komponen yang digunakannya, atau membuatnya tersedia untuk mesin proses lain;
  • code reuse - komponen dengan fokus yang sempit dan kemampuan beradaptasi yang lebih besar dapat meningkatkan biaya pengembangannya dengan lebih sering digunakan.
7
Huperniketes

Dari blog Anda, tampaknya Anda terbiasa dengan pemrograman imperatif dan fungsional, dan bahwa Anda terbiasa dengan konsep dasar yang terlibat dalam pemrograman berorientasi objek, tetapi Anda tidak pernah benar-benar memilikinya "klik" untuk apa membuatnya bermanfaat. Saya akan mencoba menjelaskan dalam hal pengetahuan itu, dan berharap itu membantu Anda.

Pada intinya, OOP adalah cara untuk menggunakan paradigma imperatif untuk mengelola tingkat kompleksitas yang lebih tinggi dengan menciptakan struktur data "pintar" yang memodelkan domain masalah. Dalam (prosedur non-objek prosedural standar) -berorientasi), Anda punya dua hal dasar: variabel, dan kode yang tahu apa yang harus dilakukan dengan mereka.Kode ini mengambil input dari pengguna dan berbagai sumber lain, menyimpannya dalam variabel, beroperasi di dalamnya, dan menghasilkan data output yang masuk ke pengguna atau berbagai lokasi lainnya.

Pemrograman berorientasi objek adalah cara untuk menyederhanakan program Anda dengan mengambil pola dasar itu dan mengulanginya dalam skala yang lebih kecil. Sama seperti sebuah program adalah kumpulan besar data dengan kode yang tahu apa yang harus dilakukan dengannya, setiap objek adalah sepotong kecil data yang terikat pada kode yang tahu apa yang harus dilakukan dengannya.

Dengan memecah domain masalah menjadi potongan-potongan kecil dan memastikan sebanyak mungkin data terikat langsung ke kode yang tahu apa yang harus dilakukan dengan itu, Anda membuatnya lebih mudah untuk alasan tentang proses secara keseluruhan dan juga tentang sub- masalah yang membentuk proses.

Dengan mengelompokkan data ke dalam kelas objek, Anda dapat memusatkan kode yang terkait dengan data itu, membuat kode yang relevan lebih mudah ditemukan dan di-debug. Dan dengan merangkum data di belakang penentu akses dan hanya mengaksesnya melalui metode, (atau properti, jika bahasa Anda mendukungnya), Anda sangat mengurangi potensi korupsi data atau pelanggaran invarian.

Dan dengan menggunakan warisan dan polimorfisme, Anda dapat menggunakan kembali kelas yang sudah ada, menyesuaikannya agar sesuai dengan kebutuhan spesifik Anda, tanpa harus memodifikasi yang asli atau menulis ulang semuanya dari bawah ke atas. (Yang merupakan hal yang tidak boleh Anda lakukan , jika Anda bisa menghindarinya.) Hati-hati Anda memahami objek dasar Anda, atau Anda bisa berakhir dengan kanguru pembunuh .

Bagi saya, ini adalah prinsip dasar pemrograman berorientasi objek: manajemen kompleksitas, pemusatan kode dan pemodelan masalah-domain yang ditingkatkan melalui penciptaan kelas objek, pewarisan dan polimorfisme, dan peningkatan keamanan tanpa mengorbankan kekuatan atau kontrol melalui penggunaan enkapsulasi dan properti. Saya harap ini membantu Anda memahami mengapa begitu banyak programmer menganggapnya berguna.

EDIT: Menanggapi pertanyaan Joel di komentar,

Bisakah Anda menjelaskan apa yang berisi "program berorientasi objek" (selain definisi-definisi mewah yang telah Anda uraikan) yang secara fundamental berbeda dari program imperatif? Bagaimana Anda "membuat bola bergulir?"

Penafian kecil di sini. Model "program berorientasi objek" saya pada dasarnya adalah model Delphi, yang sangat mirip dengan model C # /. NET karena dibuat oleh mantan anggota tim Delphi. Apa yang saya katakan di sini mungkin tidak berlaku, atau tidak berlaku banyak, dalam bahasa lain OO.

Program berorientasi objek adalah program di mana semua logika disusun di sekitar objek. Tentu saja ini harus di-boot di suatu tempat. Program Delphi khas Anda berisi kode inisialisasi yang membuat objek tunggal yang disebut Application. Pada awal program, ia memanggil Application.Initialize, lalu panggilan ke Application.CreateForm untuk setiap formulir yang ingin Anda muat ke dalam memori dari awal, dan kemudian Application.Run, yang menampilkan form utama di layar dan memulai input/event loop yang membentuk inti dari setiap program komputer interaktif.

Aplikasi dan polling formulir Anda untuk acara yang masuk dari OS dan menerjemahkannya menjadi panggilan metode pada objek Anda. Satu hal yang sangat umum adalah penggunaan event handler, atau "delegate" di .NET-speak. Objek memiliki metode yang mengatakan, "lakukan X dan Y, tetapi juga periksa untuk melihat apakah event handler khusus ini ditugaskan, dan panggil jika ada." Event handler adalah penunjuk metode - penutupan yang sangat sederhana yang berisi referensi ke metode dan referensi ke instance objek - yang digunakan untuk memperluas perilaku objek. Sebagai contoh, jika saya memiliki objek tombol pada formulir saya, saya menyesuaikan perilakunya dengan melampirkan pengendali event OnClick, yang menyebabkan beberapa objek lain mengeksekusi metode ketika tombol diklik.

Jadi dalam program berorientasi objek, sebagian besar pekerjaan dilakukan dengan mendefinisikan objek dengan tanggung jawab tertentu dan menghubungkannya bersama-sama, baik melalui pointer metode atau dengan satu objek langsung memanggil metode yang didefinisikan dalam antarmuka publik objek lain. (Dan sekarang kita kembali ke enkapsulasi.) Ini adalah ide bahwa saya tidak memiliki konsep kembali sebelum saya mengambil OOP kelas di perguruan tinggi.

46
Mason Wheeler

Saya pikir OOP pada dasarnya hanya nama yang diberikan untuk sesuatu yang mungkin tergoda untuk Anda lakukan, seperti saya sebelumnya.

Kembali ketika saya masih seorang programmer bayi, bahkan di Fortran, ada yang namanya pointer ke subrutin. Sangat berguna untuk dapat melewatkan pointer ke subrutin sebagai argumen ke subrutin lainnya.

Maka hal berikutnya yang akan sangat berguna adalah menyimpan pointer ke subrutin di dalam catatan struktur data. Dengan begitu, Anda bisa mengatakan catatan "tahu" bagaimana melakukan operasi itu sendiri.

Saya tidak yakin apakah mereka pernah membangunnya menjadi Fortran, tetapi mudah dilakukan di C dan turunannya.

Jadi di bawahnya, itu adalah ide yang sederhana dan berguna bahwa Anda mungkin tergoda untuk melakukannya sendiri, dan lebih mudah dilakukan dalam bahasa yang lebih baru, bahkan jika beberapa orang mengubahnya menjadi kereta musik raksasa yang penuh dengan kata-kata yang menyeramkan.

6
Mike Dunlavey

Ada berbagai macam sistem OO, dan sulit untuk mendapatkan definisi yang disetujui semua orang. Daripada mencoba menunjukkan bagaimana Java OO mirip dengan Common Sistem Objek LISP, saya akan mulai dengan sesuatu yang lebih konvensional, langkah demi langkah.

Misalkan Anda memiliki banyak objek yang ada sebagai data yang tersebar. Poin, misalnya, mungkin elemen dalam array X, Y, dan Z. Untuk mempertimbangkan hal itu sendiri, masuk akal untuk menarik semua data menjadi sesuatu seperti C struct.

Sekarang, untuk objek data apa pun, kami mengumpulkan semua data. Namun, dalam program prosedural, kode tersebut tersebar. Misalkan kita berurusan dengan bentuk geometris. Ada fungsi besar untuk menggambar bentuk, dan perlu tahu tentang semua bentuk. Ada fungsi besar untuk menemukan area, dan lainnya untuk perimeter. Kode untuk lingkaran tersebar melalui beberapa fungsi, dan untuk menambahkan tipe bentuk lain kita perlu tahu fungsi mana yang harus diubah. Dalam sistem berorientasi objek, kami mengumpulkan fungsi ke dalam jenis yang sama (class) sebagai data. Oleh karena itu, jika kita ingin melihat semua kode lingkaran, itu ada di definisi Circle, dan jika kita ingin menambahkan Quartercircle kita cukup menulis kelasnya dan kita punya kodenya .

Satu sisi manfaat dari ini adalah bahwa kita dapat mempertahankan invarian kelas, hal-hal yang benar tentang setiap anggota kelas. Dengan membatasi kode di luar kelas agar tidak langsung mengacaukan anggota data kelas, kami memiliki semua kode yang dapat mengubah data kelas di satu tempat, dan kami dapat mengonfirmasi bahwa itu tidak melakukan apa pun yang kacau (seperti memiliki segitiga dengan satu kaki) lebih lama dari dua lainnya digabungkan). Ini berarti kita dapat mengandalkan beberapa properti dari setiap anggota kelas, dan tidak perlu memeriksa untuk melihat apakah suatu objek waras setiap kali kita menggunakannya.

Manfaat utama datang dengan warisan dan polimorfisme. Dengan mendefinisikan semua berbagai bentuk ini sebagai subkelas dari kelas yang disebut Shape, kita dapat meminta kode kita memanipulasi Shapes, dan tugas sub-objek bentuk untuk melakukan apa pun yang dipanggil oleh manipulasi . Ini berarti kita tidak perlu menyentuh kode lama yang diuji ketika kita menambahkan bentuk baru atau memperbaiki perilaku yang lama. Kami secara otomatis memiliki kode lama yang dapat langsung memanfaatkan kode baru. Alih-alih membuat kode pengendali menyadari semua bentuk yang berbeda, dan harus mempertahankan fungsi yang menyadari semua bentuk yang berbeda, kami hanya berurusan dengan bentuk dan propertinya, sambil mempertahankan subclass Shape. Ini menyederhanakan kode pengendali.

Kami memiliki beberapa keunggulan di sini. Karena kita memiliki invarian kelas, kita dapat berargumen tentang objek data yang lebih besar dengan cara yang sama kita berargumen tentang tipe bawaan, yang berarti kita sering dapat membagi konsep kompleks menjadi yang lebih sederhana. Karena kode lingkaran sebagian besar terkandung dalam Circle, kami telah meningkatkan lokalitas. Karena tidak ada konsep lingkaran yang tersebar melalui beberapa fungsi yang berbeda di tempat yang berbeda, kami mendapatkan lebih sedikit sambungan di antara rutinitas, dan tidak perlu khawatir tentang menjaga mereka tetap sinkron. Karena kelas, pada dasarnya, tipe, kita dapat mengambil keuntungan dari sistem tipe yang ada untuk menangkap penggunaan kelas yang tidak kompatibel.

5
David Thornley

OO memiliki banyak definisi berbeda, ya. Saya yakin Anda dapat menemukan ini sendiri. Saya pribadi suka Rees Re: OO sebagai cara untuk memahami mereka. Saya kira Anda sudah membaca itu sejak Anda mengutip Paul Graham. (Saya merekomendasikannya kepada siapa pun yang tertarik pada OO.) Saya akan sedikit banyak mengadopsi Java definisi di sini {1,2,3,7,8,9}).

Pertanyaan tentang kegunaan OO, terutama cara saya mendekatinya, layak mendapatkan jawaban yang jauh lebih besar dengan beberapa ribu baris kode (sebagian agar tidak hanya menjadi sekumpulan pernyataan). Namun, inilah ringkasan dari dokumen hipotetis itu.

Saya tidak berpikir OO sangat berguna pada skala kecil, katakanlah, sekitar beberapa ratus baris. Khususnya, OO bahasa tanpa pengaruh fungsional yang baik cenderung untuk membuatnya benar-benar menyakitkan untuk menyelesaikan hal-hal sederhana dengan segala jenis koleksi atau apa pun yang membutuhkan banyak tipe data. Di sinilah sebagian besar pola desain berperan; mereka adalah band-aids dengan daya rendah yang mendasarinya bahasa .

Pada sekitar seribu baris, itu mulai menjadi lebih sulit untuk melacak semua operasi dan struktur data dan bagaimana mereka berhubungan. Ini membantu, pada titik ini, untuk memiliki cara untuk secara eksplisit mengatur struktur data dan operasi, untuk menggambar batas-batas modul dan mendefinisikan tanggung jawab, dan untuk memiliki cara yang mudah untuk memahami definisi-definisi tersebut ketika Anda mencoba untuk memprogramnya.

Java-ish OO adalah solusi setengah jalan untuk masalah-masalah ini yang kebetulan telah memenangkan kontes popularitas. Karena itu adalah mekanisme yang sama yang Java orang berlaku untuk yang kecil masalah skala yang diciptakan oleh bahasa yang kurang bertenaga, cenderung mulai terlihat lebih seperti solusi ajaib untuk segalanya daripada hanya cara untuk tetap terorganisir. Orang yang akrab dengan pemrograman fungsional cenderung lebih suka solusi lain, seperti CLOS atau kelas jenis Haskell, atau templat metaprogramming saat terjebak di C++, atau yang lain (seperti saya, bekerja setiap hari di C #) menggunakan OO tetapi hanya tidak mendapatkan semua yang bersemangat tentang hal itu.

3
Jesse Millikan

OOP = struktur data + pesan yang lewat + warisan, yang semuanya adalah evolusi logis dalam model pemrograman.

OOP dapat dipahami (oleh programmer) dalam waktu sekitar 90 detik (lihat profil saya untuk tautan). Konsepnya sangat sederhana.

Cara menerapkannya adalah masalah lain. Hanya karena Anda tahu cara mengayunkan palu tidak berarti Anda tahu cara mendesain dan membangun rumah. ;-)

1
Steven A. Lowe

OOP berupaya memodelkan konsep dunia nyata dalam hal objek dan interaksi di antara mereka. Sebagai manusia, kita cenderung memproses dunia dari segi objek. Dunia ini penuh dengan objek yang memiliki sifat tertentu dan dapat melakukan hal-hal seperti berinteraksi dengan objek lain. OOP memungkinkan untuk memodelkan dunia dengan istilah yang serupa. Misalnya,

  • Orang adalah Obyek. Seseorang memiliki beberapa sifat, seperti usia dan jenis kelamin. Seseorang dapat melakukan sesuatu: makan, tidur, mengendarai mobil.
  • Mobil juga merupakan Obyek (walaupun berbeda jenis). Ini juga memiliki sifat seperti make, model, dan tahun. Mobil dapat melakukan banyak hal: bergerak.

Tetapi sebuah mobil tidak dapat bergerak sendiri, ia membutuhkan seseorang untuk mengendarainya - interaksi antara Objek.

1
ysolik

Karena Anda memahami struct, dan Anda memahami pointer fungsi, dan Anda memahami struct dengan pointer fungsi, dari perspektif Anda, saya akan mendefinisikan pemrograman berorientasi objek hanya sebagai "pemrograman, dengan banyak penggunaan struct yang memiliki pointer fungsi". Itu masih pemrograman dalam pengertian tradisional - itu semua data, dan kode yang bertindak atas data. Perbedaannya hanyalah bagaimana semua informasi itu didefinisikan dan bagaimana Anda mendekati mendefinisikannya.

Mungkin penyederhanaan berlebihan adalah bahwa pemrograman tradisional adalah "kode, dengan beberapa struktur data", dan pemrograman berorientasi objek adalah "struktur data, dengan beberapa kode". Keduanya masih memiliki struktur data, dan keduanya masih memiliki kode. Pemrograman berorientasi objek, kemudian, tidak lebih dari tindakan mendefinisikan jenis data di muka, dan menegakkan kontrak untuk bagaimana mereka berkomunikasi melalui serangkaian fungsi.

Seperti yang telah Anda amati, ada sejumlah besar aplikasi yang ini bukan cara yang bagus untuk mengimplementasikan solusi. Anda tampaknya hidup di dunia yang sebagian besar terdiri dari aplikasi semacam itu. Dalam posting blog Anda, Anda menyebutkan melihat implementasi dari masalah "99 botol bir" ("showcase pemrograman favorit Anda"). 99 botol bir tentu merupakan bagian dari kategori itu. Mencoba memahami pemrograman berorientasi objek dengan melihat implementasi 99 botol bir adalah sedikit seperti mencoba memahami arsitektur bangunan tinggi dengan melihat rumah pohon. Bahkan rumah pohon yang dibangun dengan sangat baik hanya bisa mengajarimu begitu banyak.

TL; DR: OO pemrograman seperti pemrograman tradisional, kecuali Anda lebih memfokuskan upaya Anda dalam mendefinisikan struktur data di muka, dan Anda memiliki struktur data yang berkomunikasi satu sama lain melalui pointer fungsi.

0
Bryan Oakley

Cara saya pertama kali memahaminya adalah:

Sebelum pemrograman berorientasi objek, Anda memiliki pemrograman terstruktur . Semuanya berpusat di sekitar proses. Pertanyaan pertama yang harus Anda tanyakan pada diri sendiri adalah " Apa yang ingin saya lakukan dengan informasi itu? ".

Dengan pemrograman berorientasi objek, itu berpusat di sekitar data. Pertanyaan pertama yang harus Anda tanyakan pada diri sendiri adalah " Informasi penyihir yang perlu saya tangani? ". Ini membuat abstraksi lebih mudah.

0
DavRob60

Saya menulis posting blog beberapa waktu lalu yang mungkin Anda temukan membantu: Prosedural vs. OOP Dijelaskan .

0
VirtuosiMedia