Apakah OOP model pemrograman yang dominan di dunia nyata?

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?

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".

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.)

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)

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.

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.

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.

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.

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.

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.

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.

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.