Apakah OOP model pemrograman yang dominan di dunia nyata?


20

Objek Tidak Pernah? Yah, Hampir Tidak Pernah

Di bagian VIEWPOINT Komunikasi ACM, saya menemukan artikel menarik berjudul " Objek Tidak Pernah? Yah, Hampir Tidak Pernah ". Ini perspektif yang sangat berbeda dari objek-pertama atau objek-terlambat. Dia menyarankan "benda-tidak pernah" atau mungkin "benda-lulusan sekolah".

Penulis berbicara tentang OOP dan membuat pertanyaan tentang bagaimana OOP digunakan dalam lingkungan pemrograman dunia nyata. Dia berpikir bahwa OOP bukan model pemrograman yang dominan. Misalnya, ia mengklaim, 70% dari pemrograman dilakukan untuk Sistem Tertanam di mana OOP tidak benar-benar cocok.

Ketika beberapa profesor di universitas ingin berbicara tentang manfaat OOP, mereka berbicara tentang penggunaan kembali kode. Sebagai contoh lain, sekali lagi, katanya, ini bukan kasus nyata di dunia nyata. penggunaan kembali kode lebih sulit daripada yang diklaim di universitas:

Saya mengklaim bahwa penggunaan OOP tidak lazim seperti yang diyakini kebanyakan orang, bahwa itu tidak sesukses yang diklaim oleh para pendukungnya, dan, oleh karena itu, tempat sentralnya dalam kurikulum CS tidak dibenarkan.

Sangat menarik bagi saya untuk mengetahui bagaimana orang-orang di stack-overflow berpikir tentang ini? Apakah OOP model pemrograman yang dominan dari sudut pandang programmer?

Jika saya harus memilih / belajar / menggunakan hanya satu pendekatan, apakah itu OOP atau tidak? Mengapa?


26
"70% pemrograman dilakukan untuk Sistem Tertanam"? Apakah itu per proyek, per pengembang atau per LOC? Saya merasa bahwa 70% dari "semua prorgammings" dilakukan di Excel. Bahkan spreadsheet program yang bukan pemrogram.
LennyProgrammers

1
@ Lenny222: Jika Anda ingin tebakan saya, 70% dari salinan program yang didistribusikan dalam perangkat lunak tertanam, atau sesuatu seperti itu. Sekarang, beberapa hal yang disematkan dilakukan dalam C ++, dan seringkali versi yang diretas yang meninggalkan C dan objek, sehingga tampaknya tidak jujur ​​untuk berpendapat bahwa yang disematkan tidak pernah berorientasi objek.
David Thornley

9
Saya pikir model pemrograman yang dominan telah lama dan akan menjadi bola besar lumpur.
whatsisname

Artikel itu membuat perbedaan yang aneh antara "kelas" dan "subsistem" yang bahkan tidak saya mengerti. Ini berbicara tentang bagaimana DiskBrake extends Brakecara OOP tidak baik untuk mobil, karena di "dunia nyata" komunikasi ini dilaksanakan "oleh sinyal jaringan dan protokol bus" - seperti apa DiskBrake implements BrakeInterface?! Mungkin itu pengalaman saya sendiri << 43 tahun, tetapi contoh-contoh bagi saya benar-benar gagal mendukung klaim penulis.
OJFord

2
Tautan sekarang berada di belakang paywall. Bagaimanapun, OOP adalah semacam kurang didefinisikan dan dinilai berlebihan untuk sebagian besar. Tapi katakan saja "sebagian besar" program baru di luar sana kemungkinan sedang ditulis dalam beberapa cara OOP yang diilhami Jawa dengan getter dan setter, dan kelas yang bernama SessionManager
Charles Salvia

Jawaban:


19

Di bagian VIEWPOINT Komunikasi ACM

Jika Anda tertarik pada pemrograman praktis , proses ACM dan sejenisnya adalah sumber terakhir yang ingin Anda baca. Ini sering kali [pseudo] publikasi ilmiah tanpa aplikasi di dunia nyata. Ini adalah opini yang sering tidak lazim dibuat untuk publisitas, bagi penulis untuk membedakan dirinya dari orang banyak dan mempromosikan dirinya sendiri.

Saya mengklaim bahwa penggunaan OOP tidak lazim seperti yang diyakini kebanyakan orang, bahwa itu tidak sesukses yang diklaim oleh para pendukungnya, dan, oleh karena itu, tempat sentralnya dalam kurikulum CS tidak dibenarkan.

Saya cenderung tidak setuju dengan poin Anda. OOP tersebar luas dan berfungsi dengan baik. Dengan jumlah proyek berbasis OOP kemungkinan telah melampaui perkembangan yang dilakukan dengan strategi lain (mari kita bicara tentang waktu modern, 15-20 tahun).

Namun OOP bukan peluru perak. Ini bekerja untuk beberapa perkembangan, tidak bekerja untuk yang lain. Sama seperti pendekatan lainnya.

Tetapi satu hal yang perlu saya sebutkan adalah bahwa kurikulum harus mengkomunikasikan pengetahuan tentang pendekatan yang berbeda. Jika berbasis OOP, itu salah. Jika berbasis FP, itu salah. Itu harus mencakup semuanya atau tidak menyentuh topik ini sama sekali.

PS Mengapa peduli tentang apa yang dominan dan apa yang tidak? Ambil saja apa yang cocok untuk proyek yang ada dan tinggalkan angkanya kepada "peneliti".


3
Mereka adalah makalah penelitian di bidang Komputer yang belum menjadi arus utama. Dibutuhkan bertahun-tahun bagi akademisi untuk menyaring ke dunia nyata biasanya, meskipun secara teratur.
Orbling

4
@DeveloperArt: Harap dicatat bahwa penulis kertas memiliki pengalaman 43 tahun dalam pengembangan perangkat lunak!
Ehsan

6
Alan Kay menambahkan komentar, di cacm.acm.org/magazine/2010/9/… - 'Sebaliknya, saya tidak pernah menganggap bahwa kebanyakan sistem yang menyebut diri mereka "berorientasi objek" bahkan dekat dengan makna saya ketika saya awalnya menciptakan syarat.' - yang berhubungan erat dengan posting saya - "OO? OO siapa?"
Frank Shearar

9
@Developer Art: Apa yang memberi saya (sedikit) tentang posting Anda adalah bagian "peneliti". Akademisi terkutuk itu. Apa yang mereka lakukan untuk kita? Oh Kalkulus lambda, penutupan, benda, pemrograman fungsional, ... Tapi lain dari itu, apa yang telah para akademisi yang pernah dilakukan bagi kita?
Frank Shearar

4
-1 Periset ilmu komputer membutuhkan kutipan menakut-nakuti? ACM menerbitkan pseudo-science? Serius?
jprete

17

Jika OOP adalah satu - satunya paradigma yang Anda tahu, mungkin Anda harus belajar lebih banyak. Tapi sungguh, apa sebenarnya yang dimaksud dengan OOP? Apakah ini berarti Java atau C ++? Apakah ini berarti Smalltalk? Apakah ini berarti slot nilai dan penutupan yang dapat diselesaikan? (Hai, Skema!) Apakah ini berarti pengiriman pesan? (Hai, Erlang!)

Singkatnya, tampaknya pertanyaan yang tidak menarik untuk ditanyakan. "Apakah OO berguna ?" adalah pertanyaan yang lebih baik. Dan, sepertinya begitu. (Tentu itu untuk saya.)


6
+1 Saya menduga bahwa dalam praktiknya OOP telah berhenti berarti apa pun selain "cara yang baik untuk menulis kode yang menggunakan hal-hal yang disebut objek."
Larry Coleman

Artikel yang dirujuk tidak berpikir penggunaan bahasa OO adalah jaminan penggunaan dan pertanyaan apakah harus ada paradigma sama sekali karena mereka tidak ada dalam disiplin ilmu teknik lainnya.
JeffO

Mungkin penulis harus membaca William Cook dan Matthias Felleisen, yang menghabiskan banyak waktu berbicara tentang apa yang ada dan tidak sama dalam pemrograman.
Frank Shearar

9

Di mana semua pengembang melakukan "70% pemrograman" itu? dari semua pengembang yang saya tahu kurang dari 1% bekerja pada sistem Tertanam.

Jadi, kami memiliki 3 opsi:

  1. Saya unik dan semua teman Anda benar-benar melakukan pemrograman tertanam
  2. Ada tentara pengembang terkunci di ruang bawah tanah di suatu tempat melakukan 70% itu
  3. statistik ini dibuat dan artikelnya adalah omong kosong

kecuali saya melihat beberapa bukti bahwa opsi 1 atau 2 sebenarnya benar saya akan dengan opsi 3.

(BTW, saya tidak menganggap pemrograman tertanam pengembangan ponsel modern, dan pengembangan seluler sering OO, setelah semua Apple memaksa Anda untuk menggunakan * Objective * C untuk mengembangkan untuk iPhone)


FWIW, saya mengambil beberapa detik, dan muncul dengan setengah lusin kemungkinan langkah untuk "70% dari pemrograman". Penulis mungkin menggunakan ketujuh. (Juga, programmer tertanam ada di luar sana, mereka cenderung tidak bergaul di tempat yang sama, dan sering menganggap diri mereka insinyur listrik atau sesuatu seperti itu daripada programmer.)
David Thornley

1
@ David Thornley - berbohong dengan statistik masih berbohong, penulis jelas mengklaim bahwa sebagian besar pemrograman di dunia saat ini adalah untuk sistem embedded - dan saya katakan ini adalah total bulls # @ $ t, saya yakin saya dapat menciptakan ukuran yang menunjukkan bahwa sebagian besar pemrograman di dunia dilakukan di ruangan tempat saya berada sekarang (yang saya bagikan hanya dengan satu pengembang lainnya) - tetapi setiap kesimpulan yang saya buat di atas pengamatan ini akan sama tidak berharganya dengan ukuran yang dibuat. .
Nir

1
Saya seorang pria yang tertanam. Saya telah melihat beberapa laporan bahwa sekitar 99% dari prosesor yang diproduksi / dikirim adalah untuk sistem embedded (jika itu benar-benar diperlukan, saya dapat kembali & mengutip laporan tersebut). Karena itu, saya yakin bahwa hampir 70% dari semua pemrograman dilakukan untuk embedded system. Saya pikir sekitar 50% dari semua prosesor yang dikirim adalah 4-bit & 8-bit, tetapi ini mungkin merupakan 0,1% (atau kurang) dari semua pemrograman. Seperti yang dikatakan David, ada banyak cara untuk menghasilkan "70% program". Saya tidak akan terkejut jika jumlahnya 20-25%.
Radian

+1 untuk "berbohong dengan statistik masih berbohong"; sangat benar, sangat benar ...
Donal Fellows

8

Saya tidak punya fakta untuk menindaklanjutinya, tetapi OOP bukan model pemrograman yang dominan. Bayangkan saja semua aplikasi internal yang dikembangkan oleh seseorang yang mengambil kursus visual basic, atau melakukan beberapa pemrograman makro di Excel.

Banyak aplikasi hanya melakukan pemrograman imperatif di mana semua logika ditumpuk dalam satu kelas atau tampilan. Ini mungkin sebagian besar aplikasi sederhana internal yang berjalan di seluruh perusahaan.

Tidak ada yang salah dengan itu, ada beberapa cara untuk menyelesaikan masalah yang sama. Beberapa lebih cocok daripada yang lain.

Juga seperti yang Anda tunjukkan, OOP tidak berguna untuk semua skenario. Ada model lain juga.


Kemudian lagi, mungkin ada pertanyaan apa yang perlu dijelaskan sebagai model dominan. Apakah itu "jumlah aplikasi yang dikembangkan dengan model X" atau itu "jumlah kode yang dikembangkan dengan model X"? Either way saya masih berpikir bahwa OOP tidak akan menjadi model yang dominan.
Morten

1
+1 Untuk mengemukakan poin bahwa, sementara OOP mungkin berada di dekat mana-mana dengan profesional terlatih, industri di seluruh dunia tidak cukup mencerminkan hal ini dan ada banyak kode imperatif langsung di luar sana.
Orbling

5

Apakah atau tidak OOP adalah model pemrograman dominan tidak relevan, cukup masukkan model yang berbeda sesuai dengan kasus yang berbeda.

Tidak ada peluru perak.

Apa yang diperdebatkan Moti Ben Ari adalah pernyataan akademis, yang sudah tidak ada artinya. Namun, dia menyatakan dirinya bahwa dia tidak pernah menemukan OOP untuk "masuk akal", jelas itu berlaku untuk ribuan pengembang dan insinyur perangkat lunak dan telah digunakan di banyak sistem ...

Tetapi, inti dari jawaban saya adalah ini, apa gunanya menyatakan bahwa satu model atau lainnya dominan atau tidak, apakah itu alasan yang baik untuk menggunakannya secara membuta? Tentu saja tidak.


Jika banyak orang mengklaim menggunakan satu model dan tidak, itu masalah. Pertanyaannya adalah oop yang lazim seperti yang muncul dan bukan tentang menjadi dominan / lebih baik.
JeffO

4

Ini sebenarnya adalah pertanyaan yang sulit dijawab dengan andal. Alasan terbesar adalah orang-orang seperti saya, yang bekerja di aplikasi in-house khusus, di mana kode tidak pernah meninggalkan gedung kami. Apakah kita menggunakan OO di sini? Aku tidak berbicara. Berapa banyak programmer lain yang memiliki pekerjaan serupa? Mereka juga tidak mengatakan. Kami memang memiliki situs pekerjaan, tetapi tidak semua pekerjaan diposting, dan tidak semua posting adalah pekerjaan nyata, bukan perekrut yang mencoba mengumpulkan daftar nama.

Bahkan jika saya mengatakan kita menggunakan OO di mana saya bekerja, apakah itu berarti definisi tradisional dari artikel yang ditautkan: Objects, Classes, Inheritance? Atau apakah itu berarti bahwa saya menggunakan objek terutama sebagai alat mengatur kode? Atau apakah itu berarti saya benar-benar hanya memprogram untuk antarmuka dan hampir tidak menggunakan warisan sama sekali? Saya masih tidak mengatakan, tetapi yang mana yang benar-benar dianggap sebagai OO?

Bahkan tidak berarti bertanya apakah OO berguna sampai pertanyaan-pertanyaan di atas dijawab, apalagi dominan.


2

Tentu saja, karena itu adalah kata kunci terbaru yang diikat oleh manajemen. Ini juga menawarkan enkapsulasi dan abstraksi yang lebih baik daripada pemrograman imperatif, jadi saya pikir lompatan dari oop ke apa pun yang terjadi berikutnya mungkin bahkan lebih lama daripada keharusan untuk mengambil.

PS2: Jika saya harus memilih / belajar / menggunakan hanya satu pendekatan, apakah itu OOP atau tidak? Mengapa?

Jika Anda hanya akan mempelajarinya, Anda harus memilih bidang yang berbeda.

Anda harus belajar tentang jenis dan enkapsulasi dan semua manfaat lain dari OOP, dan kemudian belajar bagaimana mencapai hal-hal yang sama menggunakan gaya fungsional pemrograman.


Memberi +1 pada komentar untuk memilih bidang yang berbeda jika Anda berencana untuk mempelajari satu pendekatan. Itu gila.
Mat Nadrofsky

1

OOP jelas merupakan salah satu model pemrograman yang lebih dominan di dunia nyata.

Mari kita hadapi itu, bahkan orang-orang yang merancang perangkat keras digital, desainer chip sendiri, membuat transisi ke duo SystemVerilog dan SystemC. Ini adalah bahasa pemrograman berorientasi objek.

Di mana OOP tidak akan digunakan? Nah jika Anda mengkode driver perangkat sulit untuk membayangkan mengapa Anda akan memerlukan pemrograman generik atau pewarisan berganda ATAU jika Anda melakukan teknik pemrograman fungsional AI membuatnya lebih mudah di kepala. Ada banyak situasi lain juga, cukup untuk mengatakan bahwa OOP adalah tempat yang cukup kuat untuk berada di dunia pemrograman oligopolistik.


1

Saya akan mengatakan tidak.

Saya mengerti ada sejumlah besar kode di luar sana yang ditulis menggunakan bahasa 'berorientasi objek', tetapi secara umum saya menemukan bahwa kode tersebut hanya prosedural yang terbungkus dalam kelas. (Bukan berarti ini hal yang buruk). Kode yang saya lihat yang ditulis lebih banyak OO dalam bahasa-bahasa ini cenderung menjadi kekacauan ketergantungan yang mengerikan antara kelas-kelas yang biasanya tidak dapat dipertahankan.

OO seharusnya tentang pesan yang lewat di antara objek yang sepenuhnya mandiri, dan kita melihat itu dalam kode hari ini, tetapi pada tingkat yang jauh lebih besar - yaitu kita melihat objek ini diimplementasikan sebagai dll atau rakitan atau objek COM. 'Komponen' Saya pernah mendengarnya digambarkan sebagai.

jadi, saya pikir itu tidak masalah jika OO digunakan atau tidak - jika kode dapat dipelihara selama masa pakai, dapat digunakan kembali sejauh dirancang, dan cepat berkembang, maka saya tidak peduli jika itu murni prosedural atau semi-berorientasi objek atau OO sepenuhnya. Saya ragu ada yang bisa memberi tahu Anda apakah gaya yang dominan adalah salah satunya, tetapi saya akan menebak bahwa gaya prosedural akan menjadi yang paling umum, bahkan jika itu dicincang ke dalam kelas alih-alih fungsi.


0

Saya pikir penting untuk membedakan solusi yang diperoleh dengan menerapkan Pendekatan Berorientasi Objek dan solusi yang diimplementasikan MENGGUNAKAN Paradigma Berorientasi Objek. Pendapat saya tentang perangkat lunak berorientasi objek yang baik adalah untuk menggabungkan kedua solusi. Jika Anda berpikir dalam objek dan Anda menghormati definisi objek dan interaksi, dan masalah Anda dapat disesuaikan untuk menggunakan struktur ini, maka Anda akan memiliki kode yang fleksibel dan kuat. Tetapi jika Anda menggunakan objek untuk memecahkan kode menggunakan paradigma prosedural, Anda akan berakhir dengan campuran jahat yang tidak akan mengambil keuntungan dari kelebihan Objects.

Saya benar-benar lebih suka kode saya menjadi Object Oriented, dan saya mulai menyadari bahwa pada awalnya mungkin sedikit lebih menyebalkan untuk membuat struktur yang baik, tetapi ketika berhadapan dengan fleksibilitas dan persyaratan klien flash hari ini, saya pikir itu sepadan dengan upaya.


0

Saya tidak berpura-pura tahu angka pastinya, atau bahkan membuat perkiraan kasar, tetapi ada banyak proyek pemrograman yang tidak melibatkan OOP. Saya bekerja dengan robot industri. Program cenderung kode prosedur yang cukup sederhana dan lurus ke depan. Sistem operasi robot yang sebenarnya bahkan lebih dari itu.

Banyak "alat" yang kami gunakan berbasis OOP, tetapi berjalan di PC dan bukan pengontrol robot. Ini termasuk editor, simulasi, dan utilitas.

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.