Apakah OOP keras karena tidak alami?

Orang sering dapat mendengar bahwa OOP secara alami sesuai dengan cara orang berpikir tentang dunia. Tetapi saya akan sangat tidak setuju dengan pernyataan ini: Kami (atau paling tidak saya) mengonseptualisasikan dunia dalam hal hubungan antara hal-hal yang kami temui, tetapi fokus OOP adalah merancang kelas individu dan hierarki mereka.

Perhatikan bahwa, dalam kehidupan sehari-hari, hubungan dan tindakan sebagian besar ada di antara objek yang akan menjadi contoh kelas yang tidak terkait dalam OOP. Contoh hubungan tersebut adalah: "layar saya ada di atas meja"; "Aku (manusia) sedang duduk di kursi"; "mobil ada di jalan"; "Saya mengetik di keyboard"; "mesin kopi mendidihkan air", "teks ditampilkan di jendela terminal."

Kami berpikir dalam hal kata kerja bivalen (kadang-kadang trivalen, seperti, misalnya dalam, "Saya memberi Anda bunga") di mana kata kerja adalah tindakan (relasi) yang beroperasi pada dua objek untuk menghasilkan beberapa hasil / tindakan. The Fokus adalah pada tindakan, dan dua (atau tiga) [tata bahasa] benda memiliki sama pentingnya.

Bandingkan dengan OOP di mana Anda pertama kali harus menemukan satu objek (kata benda) dan katakan padanya untuk melakukan beberapa tindakan pada objek lain. Cara berpikir dialihkan dari tindakan / kata kerja yang beroperasi pada kata benda ke kata benda yang beroperasi pada kata benda - seolah-olah semuanya dikatakan dengan suara pasif atau refleksif, misalnya, "teks ditampilkan oleh jendela terminal". Atau mungkin "teks menarik dirinya di jendela terminal".

Tidak hanya fokus dialihkan ke kata benda, tetapi salah satu kata benda (sebut saja subjek tata bahasa) diberikan "kepentingan" yang lebih tinggi daripada yang lain (objek tata bahasa). Jadi seseorang harus memutuskan apakah akan mengatakan terminalWindow.show (someText) atau someText.show (terminalWindow). Tetapi mengapa membebani orang dengan keputusan sepele seperti itu tanpa konsekuensi operasional ketika orang benar-benar bermaksud menunjukkan (terminalWindow, someText)? [Konsekuensinya secara operasional tidak signifikan - dalam kedua kasus teks ditampilkan pada jendela terminal - tetapi bisa sangat serius dalam desain hierarki kelas dan pilihan "salah" dapat menyebabkan kode berbelit-belit dan sulit dipertahankan.]

Oleh karena itu saya berpendapat bahwa cara utama melakukan OOP (berbasis kelas, pengiriman tunggal) sulit karena itu TIDAK UNATRAL dan tidak sesuai dengan bagaimana manusia berpikir tentang dunia. Metode generik dari CLOS lebih dekat dengan cara berpikir saya, tetapi, sayangnya, ini bukan pendekatan luas.

Mengingat masalah-masalah ini, bagaimana / mengapa hal itu terjadi sehingga cara OOP saat ini menjadi populer? Dan apa, jika ada, yang bisa dilakukan untuk menurunkannya?

OOP tidak wajar untuk beberapa masalah. Begitu juga prosedural. Jadi fungsional. Saya pikir OOP memiliki dua masalah yang benar-benar membuatnya tampak sulit.

1. Beberapa orang bertindak seperti itu adalah Satu Cara Sejati untuk memprogram dan semua paradigma lainnya salah. IMHO semua orang harus menggunakan bahasa multi-paradigma dan memilih paradigma terbaik untuk subproblem yang sedang mereka kerjakan. Beberapa bagian dari kode Anda akan memiliki gaya OO. Beberapa akan berfungsi. Beberapa akan memiliki gaya prosedural yang lurus. Dengan pengalaman, menjadi jelas paradigma apa yang terbaik untuk apa:

   Sebuah. OO umumnya paling baik untuk ketika Anda memiliki perilaku yang sangat terkait dengan negara tempat mereka beroperasi, dan sifat tepat dari negara adalah detail implementasi, tetapi keberadaannya tidak dapat dengan mudah diabstraksi. Contoh: Kelas koleksi.

   b. Prosedural adalah yang terbaik untuk ketika Anda memiliki banyak perilaku yang tidak sangat digabungkan ke data tertentu. Misalnya, mungkin mereka beroperasi pada tipe data primitif. Paling mudah untuk memikirkan perilaku dan data sebagai entitas yang terpisah di sini. Contoh: Kode numerik.

   c. Fungsional adalah yang terbaik ketika Anda memiliki sesuatu yang cukup mudah untuk ditulis secara deklaratif sehingga keberadaan negara apa pun adalah detail implementasi yang dapat dengan mudah diabstraksi. Contoh: Peta / Kurangi paralelisme.

2. OOP umumnya menunjukkan kegunaannya pada proyek-proyek besar di mana memiliki potongan-potongan kode yang dienkapsulasi sangat diperlukan. Ini tidak terjadi terlalu banyak dalam proyek pemula.

IMHO itu adalah masalah selera pribadi dan cara berpikir. Saya tidak punya banyak masalah dengan OO.

Kami (atau setidaknya saya) membuat konsep dunia dalam hal hubungan antara hal-hal yang kami temui, tetapi fokus OOP adalah merancang kelas individu dan hierarki mereka.

IMHO ini tidak begitu, meskipun mungkin persepsi umum. Alan Kay, penemu istilah OO, selalu menekankan pesan yang dikirim antara objek, bukan objek itu sendiri. Dan pesan-pesannya, setidaknya bagi saya, menunjukkan hubungan.

Perhatikan bahwa, dalam kehidupan sehari-hari, hubungan dan tindakan sebagian besar ada di antara objek yang akan menjadi contoh kelas yang tidak terkait dalam OOP.

Jika ada hubungan antara objek, maka mereka terkait, per definisi. Dalam OO Anda bisa mengekspresikannya dengan asosiasi / agregasi / ketergantungan penggunaan antara dua kelas.

Kami berpikir dalam hal kata kerja bivalen (kadang-kadang trivalen, seperti, misalnya dalam, "Saya memberi Anda bunga") di mana kata kerja adalah tindakan (relasi) yang beroperasi pada dua objek untuk menghasilkan beberapa hasil / tindakan. Fokusnya adalah pada tindakan, dan dua (atau tiga) objek [tata bahasa] memiliki kepentingan yang sama.

Tetapi mereka masih memiliki peran yang jelas dalam konteks: subjek, objek, tindakan, dll. "Aku memberimu bunga" atau "Kamu memberiku bunga" tidak sama (belum lagi "Bunga memberimu kepadaku": -)

Bandingkan dengan OOP di mana Anda pertama kali harus menemukan satu objek (kata benda) dan katakan padanya untuk melakukan beberapa tindakan pada objek lain. Cara berpikir dialihkan dari tindakan / kata kerja yang beroperasi pada kata benda ke kata benda yang beroperasi pada kata benda - seolah-olah semuanya dikatakan dengan suara pasif atau refleksif, misalnya, "teks ditampilkan oleh jendela terminal". Atau mungkin "teks menarik dirinya di jendela terminal".

Saya tidak setuju dengan ini. IMHO kalimat bahasa Inggris "Bill, go to hell" membaca lebih alami dalam kode program bill.moveTo(hell)daripada move(bill, hell). Dan yang pertama sebenarnya lebih analog dengan suara aktif asli.

Jadi seseorang harus memutuskan apakah akan mengatakan terminalWindow.show (someText) atau someText.show (terminalWindow)

Sekali lagi, tidak sama untuk meminta terminal untuk menampilkan beberapa teks, atau meminta teks untuk menunjukkan terminal. IMHO itu cukup jelas mana yang lebih alami.

Mengingat masalah-masalah ini, bagaimana / mengapa hal itu terjadi sehingga cara OOP saat ini menjadi populer?

Mungkin karena mayoritas pengembang OO melihat OO berbeda dari Anda?

Beberapa programmer menemukan OOD sulit karena programmer-programmer itu suka berpikir tentang bagaimana menyelesaikan masalah untuk komputer, bukan tentang bagaimana masalah itu harus diselesaikan.

... tetapi fokus OOP adalah mendesain kelas individu dan hierarki mereka.

OOD BUKAN tentang itu. OOD adalah tentang mencari tahu bagaimana hal-hal berperilaku dan berinteraksi.

Kami berpikir dalam hal kata kerja bivalen (kadang-kadang trivalen, seperti, misalnya dalam, "Saya memberi Anda bunga") di mana kata kerja adalah tindakan (relasi) yang beroperasi pada dua objek untuk menghasilkan beberapa hasil / tindakan. Fokusnya adalah pada tindakan, dan dua (atau tiga) objek [tata bahasa] memiliki kepentingan yang sama.

Fokus pada OOD selalu pada tindakan, di mana tindakan adalah perilaku objek. Objek bukan apa-apa tanpa perilaku mereka. Satu-satunya kendala objek OOD adalah bahwa segala sesuatu harus dilakukan oleh sesuatu.

Saya tidak melihat pelaku sebagai hal yang lebih penting daripada hal yang dilakukan sesuatu terhadapnya.

Tetapi mengapa membebani orang dengan keputusan sepele seperti itu tanpa konsekuensi operasional ketika orang benar-benar bermaksud menunjukkan (terminalWindow, someText)?

Bagi saya itu hal yang sama dengan notasi yang berbeda. Anda masih harus memutuskan siapa yang tampil dan siapa yang tampil. Begitu Anda tahu itu, maka tidak ada keputusan dalam OOD. Windows menampilkan teks -> Window.Tampilkan (teks).

Banyak hal di luar sana (terutama di daerah warisan) mengatakan itu adalah OO ketika tidak. Misalnya ada sejumlah besar kode C ++ yang tidak menerapkan ara OOD.

OOD mudah setelah Anda keluar dari pola pikir bahwa Anda sedang memecahkan masalah untuk komputer. Anda sedang memecahkan masalah untuk hal-hal yang melakukan hal-hal.

Mungkin, saya tidak bisa mengerti intinya, tetapi:

Membaca buku pertama tentang OOP (awal 90-an, manual tipis Borland untuk Pascal) saya cukup kagum dengan kesederhanaan dan potensinya. (Sebelumnya, saya telah menggunakan Cobol, Fortran, bahasa Assembly dan hal-hal prasejarah lainnya.)

Bagi saya, Cukup jelas: seekor anjing adalah seekor binatang, seekor binatang harus makan, anjing saya adalah seekor anjing, jadi ia harus makan ...

Di sisi lain, pemrograman itu sendiri pada dasarnya tidak alami (yaitu buatan). Pidato manusia adalah buatan (jangan salahkan saya, kita semua telah belajar bahasa kita dari orang lain, tidak ada yang tahu orang yang menemukan bahasa Inggris) juga. Menurut beberapa ilmuwan, pikiran manusia dibentuk oleh bahasa yang telah ia pelajari terlebih dahulu.

Saya akui, beberapa konstruksi dalam bahasa OO modern sedikit canggung, tetapi ini adalah evolusi.

Satu hal yang menyulitkan saya adalah berpikir bahwa OOP adalah tentang memodelkan dunia. Saya berpikir bahwa jika saya tidak melakukannya dengan benar, sesuatu mungkin akan datang dan menggigit saya (sesuatu itu benar atau tidak). Saya sangat menyadari masalah bahwa berpura-pura semuanya adalah objek atau entitas. Ini membuat saya sangat ragu-ragu dan kurang percaya diri tentang pemrograman di OOP.

Kemudian saya membaca SICP dan sampai pada pemahaman baru bahwa itu benar-benar tentang tipe data dan mengendalikan akses kepada mereka. Semua masalah yang saya lenyapkan karena didasarkan pada premis yang salah, bahwa dalam OOP Anda menjadi model dunia.

Saya masih kagum pada kesulitan besar yang diberikan premis palsu ini kepada saya (dan bagaimana saya membiarkan diri saya terikat padanya).

Ya, OOP itu sendiri sangat tidak wajar - dunia nyata tidak sepenuhnya terbuat dari taksonomi hierarkis. Beberapa bagian kecil darinya terbuat dari benda-benda itu, dan bagian itu adalah satu-satunya hal yang dapat diekspresikan secara memadai dalam hal OO. Semua yang lain tidak bisa secara alami cocok dengan cara berpikir sepele dan terbatas. Lihat ilmu alam, lihat berapa banyak bahasa matematika yang berbeda telah diciptakan untuk mengekspresikan kompleksitas dunia nyata yang paling sederhana atau setidaknya dapat dipahami. Dan hampir tidak satu pun dari mereka dapat dengan mudah diterjemahkan ke dalam bahasa objek dan pesan.

Kami (atau setidaknya saya) membuat konsep dunia dalam hal hubungan antara hal-hal yang kami temui, tetapi fokus OOP adalah merancang kelas individu dan hierarki mereka.

Anda mulai dari (IMO) premis palsu. Hubungan antara objek bisa dibilang lebih penting daripada objek itu sendiri. Ini adalah hubungan yang memberikan struktur program berorientasi objek. Warisan, hubungan antara kelas, tentu saja penting karena kelas objek menentukan apa yang bisa dilakukan objek itu. Tapi itu hubungan antara objek individu yang menentukan apa objek sebenarnya dalam batas-batas yang ditentukan oleh kelas, dan karena itu bagaimana program berperilaku.

Paradigma berorientasi objek mungkin sulit pada awalnya bukan karena sulit untuk memikirkan kategori objek baru, tetapi karena sulit untuk membayangkan grafik objek dan memahami apa hubungan antara mereka seharusnya, terutama ketika Anda tidak memiliki cara untuk menggambarkan hubungan tersebut. Inilah sebabnya pola desain sangat berguna. Pola desain hampir seluruhnya tentang hubungan antar objek. Pola memberi kita kedua blok bangunan yang bisa kita gunakan untuk merancang hubungan objek di tingkat yang lebih tinggi dan bahasa yang bisa kita gunakan untuk menggambarkan hubungan itu.

Hal yang sama berlaku di bidang kreatif yang bekerja di dunia fisik. Siapa pun dapat mengumpulkan sekelompok kamar dan menyebutnya sebuah bangunan. Kamar-kamar bahkan mungkin sepenuhnya dilengkapi dengan semua perlengkapan terbaru, tetapi itu tidak membuat bangunan bekerja. Tugas seorang arsitek adalah untuk mengoptimalkan hubungan antara kamar-kamar tersebut sehubungan dengan persyaratan orang-orang yang menggunakan kamar-kamar itu dan lingkungan bangunan. Memperbaiki hubungan itu adalah apa yang membuat bangunan bekerja baik dari perspektif fungsional maupun estetika.

Jika Anda kesulitan membiasakan diri dengan OOP, saya mendorong Anda untuk lebih memikirkan tentang bagaimana benda-benda Anda bersatu dan bagaimana tanggung jawab mereka diatur. Jika Anda belum melakukannya, bacalah tentang pola desain - Anda mungkin akan menyadari bahwa Anda telah melihat pola-pola yang Anda baca, tetapi memberi mereka nama akan membuat Anda melihat bukan hanya pohon, tetapi juga tribun, pepohonan, belukar, kayu, kebun, tempat kayu, dan akhirnya hutan.

Ini hanya sebagian dari apa yang salah dengan OOP.

Pada dasarnya, fungsi menjadi warga negara kelas dua, dan ini buruk.

Bahasa modern (ruby / python) tidak mengalami masalah ini dan menyediakan fungsi sebagai objek kelas satu, serta memungkinkan Anda membuat program tanpa membangun hierarki kelas apa pun.

OOP tidak sulit. Apa yang membuatnya sulit untuk digunakan dengan baik adalah pemahaman yang dangkal tentang apa gunanya, di mana programmer mendengar maksim acak, dan mengulanginya untuk diri mereka sendiri untuk menerima berkah dari Geng Empat Dewa, Martin Fowler yang diberkati, atau siapa pun yang mereka baca.

Diedit

Pertama-tama saya ingin mengatakan bahwa saya tidak pernah menemukan OOP keras, atau lebih sulit daripada paradigma pemrograman lainnya. Pemrograman pada dasarnya sulit karena mencoba memecahkan masalah dari dunia nyata dan dunia nyata sangat kompleks. Di sisi lain, ketika saya membaca pertanyaan ini saya bertanya pada diri saya sendiri: Apakah OOP "lebih alami" daripada paradigma lain? Dan karenanya lebih efektif?

Saya pernah menemukan artikel (saya berharap bisa menemukannya lagi sehingga saya bisa mempostingnya sebagai referensi) tentang studi perbandingan antara pemrograman imperatif (IP) dan pemrograman berorientasi objek (OOP). Mereka pada dasarnya mengukur produktivitas programmer profesional yang menggunakan IP dan OOP di berbagai proyek, dan hasilnya adalah mereka tidak melihat perbedaan besar. Jadi, klaimnya adalah bahwa tidak ada perbedaan besar dalam produktivitas antara kedua kelompok, dan yang benar-benar diperhitungkan adalah pengalaman.

Di sisi lain, para pendukung objek-orientasi mengklaim bahwa, sementara selama pengembangan awal sistem OOP bahkan mungkin memakan waktu lebih lama daripada keharusan, dalam jangka panjang kode lebih mudah untuk mempertahankan dan memperluas karena integrasi yang erat antara data dan operasi.

Saya telah bekerja terutama dengan bahasa OOP (C ++, Java) tetapi saya sering merasa bahwa saya bisa seproduktif menggunakan Pascal atau Ada walaupun saya tidak pernah mencobanya untuk proyek besar.

Bandingkan dengan OOP di mana Anda pertama kali harus menemukan satu objek (kata benda) dan katakan padanya untuk melakukan beberapa tindakan pada objek lain.

[memotong]

Oleh karena itu saya berpendapat bahwa cara utama melakukan OOP (berbasis kelas, pengiriman tunggal) sulit karena itu TIDAK UNATRAL dan tidak sesuai dengan bagaimana manusia berpikir tentang dunia. Metode generik dari CLOS lebih dekat dengan cara berpikir saya, tetapi, sayangnya, ini bukan pendekatan luas.

Ketika saya membaca paragraf terakhir ini dengan lebih hati-hati, saya akhirnya mengerti poin utama pertanyaan Anda dan saya harus menulis ulang jawaban saya dari awal. :-)

Saya tahu proposal OO lain di mana banyak objek menerima pesan, bukan hanya satu, yaitu beberapa objek memainkan peran simetris ketika menerima pesan. YA, ini sepertinya pendekatan OOP yang lebih umum dan mungkin lebih alami (kurang ketat) bagi saya.

Di sisi lain, "pengiriman ganda" dapat dengan mudah disimulasikan menggunakan "pengiriman tunggal" dan "pengiriman tunggal" lebih mudah untuk diterapkan. Mungkin ini adalah salah satu alasan mengapa "pengiriman ganda" belum menjadi arus utama.

Berhentilah mencari paradigma OOP eksklusif dan coba beberapa JavaScript.

Saat ini saya memiliki sesuatu skema yang bekerja di mana objek UI saya beroperasi di bawah antarmuka yang digerakkan oleh peristiwa. Dengan kata lain, saya akan memiliki apa yang tampak seperti metode publik umum yang ketika dipecat menghasilkan tindakan yang ditentukan secara internal. Tetapi ketika dipecat, apa yang sebenarnya terjadi adalah saya memicu suatu kejadian pada objek itu sendiri dan handler yang telah didefinisikan sebelumnya di dalam objek itu merespon. Acara ini dan objek acara yang bisa Anda lampirkan properti yang diteruskan ke pendengar lain dapat didengar oleh apa pun yang peduli untuk mendengarkan. Anda dapat mendengarkan objek secara langsung, atau Anda dapat mendengarkan secara umum untuk jenis acara tersebut (acara juga dipicu pada objek umum yang dapat didengarkan oleh semua objek yang dibuat oleh pabrik). Jadi sekarang misalnya, saya punya kotak kombo tempat Anda memilih item baru dari daftar dropdown.

Jika Anda mau, (dan saya terkejut menemukan bahwa saya biasanya tidak mau - ini adalah masalah keterbacaan ketika Anda tidak dapat melihat dari mana acara itu berasal) Anda dapat memiliki decoupling objek yang lengkap dan membangun konteks melalui objek event yang dilewati. Apa pun itu, Anda masih menghindari pengiriman tunggal dengan bisa mendaftarkan banyak responden.

Tapi saya tidak melakukan ini dengan OOP sendirian dan JS bahkan tidak 'benar' OOP oleh beberapa definisi, yang menurut saya lucu. Tepat, untuk tingkat pengembangan aplikasi yang lebih tinggi menurut saya, memiliki kekuatan untuk mengubah paradigma ke arah apa pun yang sesuai dengan situasi Anda dan kami dapat meniru kelas dengan baik jika kami mau. Tapi dalam kasus ini, saya mencampur aspek fungsional (melewati penangan sekitar) dengan OOP.

Lebih penting lagi, apa yang saya rasakan cukup kuat. Saya tidak berpikir dalam hal satu objek bertindak pada yang lain. Saya pada dasarnya memutuskan objek apa yang peduli, memberi mereka alat yang mereka butuhkan untuk memilah-milah dan hanya menjatuhkan mereka ke dalam mixer dan membiarkan mereka bereaksi satu sama lain.

Jadi saya kira apa yang saya katakan adalah ini: itu bukan jenis pernyataan saklar. Ini campuran dan cocok. Masalahnya adalah bahasa dan mode yang ingin Anda percaya bahwa itu adalah satu hal yang paling penting. Bagaimana seorang pengembang java junior, misalnya, benar-benar menghargai OOP ketika mereka berpikir mereka selalu melakukannya dengan benar secara default?

Cara itu dijelaskan kepada saya adalah dengan pemanggang roti dan mobil. Keduanya memiliki pegas, jadi Anda akan memiliki objek "pegas" dan mereka akan memiliki ukuran, kekuatan, dan apa pun yang berbeda, tetapi keduanya akan menjadi "pegas" dan kemudian memperluas metafora itu ke mobil, jika Anda memiliki banyak roda (Roda, jelas, ditambah setir, dll) dan itu sangat masuk akal.

Anda kemudian dapat menganggap program sebagai daftar objek, dan itu jauh lebih mudah untuk divisualisasikan daripada "Ini daftar hal-hal yang melakukan hal-hal, jadi tidak seperti daftar instruksi yang Anda lihat sebelumnya"

Saya pikir masalah sebenarnya dengan OOP adalah bagaimana hal itu dijelaskan kepada orang-orang. Seringkali (di kelas saya) saya melihatnya dijelaskan dengan mengatakan "ini tentang banyak kelas yang melakukan hal-hal kecil, dan Anda dapat membuat objek dari itu" dan itu semua membingungkan banyak orang, karena menggunakan apa yang pada dasarnya abstrak istilah untuk menjelaskan konsep-konsep ini, daripada ide-ide konkret yang orang pahami ketika mereka berusia 5 tahun bermain dengan lego.

Ini adalah cara alami untuk memikirkan dunia melalui kategorisasi. Itu kurang lebih tentang OO. OOP sulit karena pemrograman sulit.

Saya pikir beberapa kesulitan muncul ketika orang mencoba menggunakan OOP untuk mewakili kenyataan. Semua orang tahu bahwa mobil memiliki empat roda dan mesin. Semua orang tahu bahwa mobil bisa Start(), Move()dan SoundHorn().

Lampu menyala di kepala saya ketika saya menyadari saya harus berhenti berusaha melakukan ini sepanjang waktu. Objek bukanlah benda yang dibagikan namanya. Objek adalah (yaitu harus) partisi data yang cukup rinci yang relevan dengan ruang lingkup masalah. Untuk oughtmemiliki apa yang dibutuhkan oleh solusi untuk masalah itu, tidak lebih dan tidak kurang. Jika membuat objek yang bertanggung jawab untuk beberapa perilaku menghasilkan lebih banyak baris kode daripada perilaku yang sama menjadi pekerjaan pihak ketiga yang samar-samar (beberapa mungkin menyebutnya 'poltergeist') maka poltergeist mendapatkan chip-nya.

Untuk mengelola kompleksitas, kita perlu mengelompokkan fungsi ke dalam modul, dan ini merupakan masalah yang sulit secara umum. Ini seperti pepatah lama tentang kapitalisme, OOP adalah sistem terburuk untuk mengatur perangkat lunak di luar sana, kecuali untuk semua hal lain yang telah kami coba.

Alasan kami mengelompokkan interaksi di dalam kata benda, meskipun sering ada ambiguitas tentang mana dari kedua kata benda yang dikelompokkan, adalah bahwa jumlah kata benda yang terjadi bekerja untuk kelas ukuran yang dapat dikelola, sedangkan pengelompokan dengan kata kerja cenderung menghasilkan kelompok yang sangat kecil seperti sekali saja, atau kelompok yang sangat besar untuk acara seperti pertunjukan . Penggunaan kembali konsep seperti pewarisan juga terjadi dengan lebih mudah ketika dikelompokkan berdasarkan kata benda.

Juga, pertanyaan untuk memutuskan apakah akan menampilkan dengan jendela atau teks hampir selalu lebih jelas dalam praktik daripada dalam teori. Misalnya, hampir semua grup toolkit GUI menambahkan dengan wadah, tetapi tampil dengan widget. Jika Anda mencoba menulis kode dengan cara lain, alasannya menjadi cukup jelas, meskipun memikirkannya secara abstrak kedua metode tersebut tampaknya dapat dipertukarkan.

Tidak ada . Ada beberapa cara untuk menyelesaikan masalah menggunakan Pemrograman: fungsional, Prosedural, logis, OOP, lainnya.

Di dunia nyata, kadang-kadang, orang menggunakan paradigma fungsional, dan kadang-kadang, kita menggunakan paradigma prosedural, dan sebagainya. Dan terkadang kita campur aduk. Dan akhirnya kami mewakili mereka sebagai gaya atau paradigma pemrograman tertentu.

Ada juga paradigma "semuanya adalah daftar atau item", yang digunakan dalam LISP. Saya suka menyebutkan sebagai hal yang berbeda dari pemrograman fungsional . PHP menggunakannya dalam array asosiatif.

OOP dan paradigma "Semuanya adalah daftar atau item" dianggap 2 dari gaya pemrograman LEBIH BANYAK ALAMI , seperti yang saya ingat dalam beberapa kelas Kecerdasan Buatan.

Kedengarannya aneh bagi saya, "OOP tidak alami", mungkin cara Anda belajar, atau cara Anda telah diajarkan tentang OOP salah, tetapi bukan OOP itu sendiri.

Mengingat masalah-masalah ini, bagaimana / mengapa hal itu terjadi sehingga cara OOP saat ini menjadi populer? Dan apa, jika ada, yang bisa dilakukan untuk menurunkannya?

OOP menjadi populer karena ia menawarkan alat untuk mengatur program Anda pada tingkat abstraksi yang lebih tinggi daripada bahasa prosedural populer yang mendahuluinya. Itu juga relatif mudah untuk membuat bahasa yang memiliki struktur prosedural di dalam metode, dan struktur berorientasi objek di sekitarnya. Ini memungkinkan para programmer yang sudah tahu cara memprogram secara prosedural mengambil prinsip-prinsip OO satu per satu. Ini juga menyebabkan banyak program OO-in-name-only yang merupakan program prosedural yang dibungkus dalam satu atau dua kelas.

Untuk melucuti OO, bangun bahasa yang memudahkan transisi secara bertahap dari apa yang diketahui sebagian besar programmer saat ini (kebanyakan prosedural, dengan sedikit OO,) ke paradigma pilihan Anda. Pastikan itu menyediakan API yang nyaman untuk melakukan tugas-tugas umum, dan mempromosikannya dengan baik. Orang-orang akan segera membuat program X-in-name-only dalam bahasa Anda. Maka Anda dapat mengharapkannya butuh bertahun-tahun bagi orang untuk menjadi baik dalam benar-benar melakukan X.

Saya pikir bahasa OOP dan OOP memiliki masalah juga.

Jika memahaminya dengan benar, OOP adalah tentang kotak hitam (objek) yang memiliki tombol tekan pada mereka yang dapat didorong (metode). Kelas ada di sana untuk membantu mengatur kotak hitam ini.

Satu masalah adalah ketika programmer menempatkan tombol pada objek yang salah. Terminal tidak dapat menampilkan teks pada dirinya sendiri, teks tidak dapat menampilkan dirinya pada terminal. Komponen window manager dari sistem operasi yang dapat melakukan itu. Jendela dan teks terminal hanyalah entitas pasif. Tetapi jika kita berpikir dengan cara ini kita menyadari entitas yang paling adalah hal-hal pasif dan kita hanya akan memiliki beberapa objek yang benar-benar melakukan sesuatu (atau hanya satu: komputer ). Memang ketika Anda menggunakan C Anda mengaturnya menjadi modul, modul ini mewakili beberapa objek.

Poin lain adalah bahwa komputer hanya menjalankan instruksi secara berurutan. Mari kita asumsikan Anda memiliki VCRdan Televisionobjek, bagaimana Anda memutar video? Anda mungkin menulis sesuatu seperti ini:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

Ini akan sesederhana ini, tetapi Anda membutuhkan setidaknya 3 prosesor ( atau proses ) untuk itu: yang satu memainkan peran Anda, yang kedua adalah VCR, yang ketiga adalah TV. Tetapi biasanya Anda hanya memiliki satu inti (setidaknya tidak cukup untuk semua objek Anda). Di perguruan tinggi, banyak teman sekelas saya tidak mengerti mengapa GUI membeku ketika tombol menekan melakukan operasi yang mahal.

Jadi saya pikir desain berorientasi objek dapat menggambarkan dunia dengan cukup baik, tapi itu bukan abstraksi terbaik untuk komputer.

Lihatlah DCI (data, konteks dan interaksi) yang ditemukan oleh penemu pola MVC.

Tujuan DCI adalah (dikutip dari Wikipedia):

• Berikan perilaku sistem status kelas pertama, objek di atas (kata benda).
• Untuk memisahkan kode untuk perilaku sistem yang berubah dengan cepat (apa yang dilakukan sistem) dari kode untuk mengubah pengetahuan domain secara perlahan (apa sistem itu), alih-alih menggabungkan keduanya dalam satu antarmuka kelas.
• Untuk mendukung gaya berpikir objek yang dekat dengan model mental masyarakat, daripada gaya berpikir kelas.

Berikut ini adalah artikel yang bagus oleh penulis dan ini adalah contoh implementasi kecil (.NET) jika Anda ingin melihat beberapa kode. Ini jauh lebih sederhana daripada kedengarannya, dan terasa sangat alami.

Orang sering dapat mendengar bahwa OOP secara alami sesuai dengan cara orang berpikir tentang dunia. Tapi saya akan sangat tidak setuju dengan pernyataan ini (...)

Karena sudah diinjili dalam buku-buku dan di tempat lain selama beberapa dekade, saya juga tidak setuju. Namun demikian, saya pikir Nygaard dan Dahl adalah orang-orang yang mengatakannya, dan saya pikir mereka berfokus pada bagaimana lebih mudah untuk berpikir tentang merancang simulasi dibandingkan dengan alternatif saat itu.

(...) tetapi fokus OOP adalah mendesain kelas individu dan hierarki mereka.

Penegasan ini memasuki wilayah yang masuk akal mengingat betapa populernya kesalahpahaman tentang OOP, dan seberapa sensitif OO terhadap definisi. Saya memiliki lebih dari sepuluh tahun di lapangan, melakukan pekerjaan industri dan penelitian akademik tentang prog. bahasa, dan saya dapat memberitahu Anda bahwa saya menghabiskan bertahun-tahun belajar "mainstream OO" karena saya mulai memperhatikan betapa berbedanya (dan lebih rendah) dari apa yang bertujuan pencipta sebelumnya. Untuk pengobatan modern, terkini tentang subjek, saya akan merujuk pada upaya W. Cook baru-baru ini:

"Sebuah Proposal untuk Definisi Modern" Modern "dan" Object Oriented " http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Mengingat masalah-masalah ini, bagaimana / mengapa hal itu terjadi sehingga cara OOP saat ini menjadi populer?

Mungkin alasan yang sama keyboard QWERTY menjadi populer atau alasan yang sama sistem operasi DOS menjadi populer. Segala sesuatunya naik kendaraan populer, terlepas dari propertinya, dan menjadi populer sendiri. Dan kadang-kadang, versi yang mirip tetapi lebih buruk dari sesuatu dianggap sebagai hal yang sebenarnya.

Dan apa, jika ada, yang bisa dilakukan untuk menurunkannya?

Tulis sebuah program menggunakan pendekatan yang unggul. Tulis program yang sama menggunakan pendekatan OO. Perlihatkan yang pertama memiliki sifat yang lebih baik daripada yang kedua dalam setiap aspek yang signifikan (baik sifat dari sistem itu sendiri maupun sifat rekayasa). Tunjukkan bahwa program yang dipilih relevan dan pendekatan yang diusulkan mempertahankan kualitas properti yang tinggi jika diterapkan pada jenis program lainnya. Jadilah teliti dalam analisis Anda dan gunakan definisi yang tepat dan diterima bila perlu.

Akhirnya, bagikan temuan Anda dengan kami.

Ambil Java: objek adalah semacam bottleneck abstraksi, sebagian besar "benda" adalah sub-komponen objek atau menggunakan objek sebagai sub-komponennya. Objek harus multiguna untuk seluruh lapisan abstraksi di antara kedua jenis hal ini - muti-purpose berarti tidak ada satu metafora yang mereka wujudkan. Khususnya Java membuat objek (& kelas) sebagai satu-satunya lapisan tempat Anda memanggil / mengirim kode. Jumlah benda yang diwujudkannya membuat mereka, sejujurnya, terlalu rumit. Setiap uraian yang berguna dari mereka harus dibatasi untuk beberapa bentuk khusus atau terbatas.

Warisan & hierarki antarmuka adalah "hal" yang menggunakan objek sebagai sub-komponen. Ini adalah salah satu cara khusus untuk menggambarkan objek, bukan cara untuk memperoleh pemahaman umum tentang objek.

"Objek" dapat dikatakan memiliki atau menjadi banyak hal karena mereka adalah abstraksi multi-tujuan yang lebih atau kurang universal dalam "OO Langauge". Jika mereka digunakan untuk mengandung keadaan bisa berubah lokal atau untuk mengakses beberapa negara dunia eksternal maka mereka sangat mirip "kata benda".

Sebaliknya, objek yang mewakili proses, misalnya "mengenkripsi" atau "kompres" atau "mengurutkan", terlihat seperti "kata kerja".

Beberapa objek digunakan untuk peran mereka sebagai namespace, misalnya tempat untuk meletakkan fungsi "statis" di Jawa.

Saya cenderung setuju dengan argumen bahwa Java terlalu berat pada panggilan metode objek, dengan pengiriman pada objek. Ini mungkin karena saya lebih suka kelas tipe Haskell untuk mengendalikan pengiriman. Ini adalah batasan pengiriman dan merupakan fitur Java tetapi tidak sebagian besar bahasa, atau bahkan sebagian besar bahasa OA.

Saya telah menyaksikan dan berpartisipasi dalam banyak debat online tentang OOP. Para pendukung OOP biasanya tidak tahu bagaimana menulis kode prosedural yang tepat. Dimungkinkan untuk menulis kode prosedural yang sangat modular. Dimungkinkan untuk memisahkan kode dan data dan memastikan bahwa fungsi hanya dapat menulis ke penyimpanan data mereka sendiri. Dimungkinkan untuk menerapkan konsep pewarisan dengan menggunakan kode prosedural. Lebih penting lagi, kode prosedural lebih ramping, lebih cepat dan lebih mudah untuk di-debug.

Jika Anda membuat modul file tunggal dengan konvensi penamaan yang ketat, kode prosedural lebih mudah untuk ditulis dan dipelihara daripada OO dan itu akan melakukan hal yang sama atau lebih dan lebih cepat. Dan jangan lupa bahwa ketika aplikasi Anda berjalan, itu selalu prosedural tidak peduli berapa banyak kelas fitur dalam skrip Anda.

Kemudian Anda memiliki masalah bahasa seperti PHP, yang tidak benar-benar Berorientasi Objek dan mengandalkan peretasan untuk hal-hal palsu seperti pewarisan berganda. Bidikan besar yang memengaruhi arah bahasa telah mengubah PHP menjadi tambalan aturan yang tidak konsisten yang telah menjadi terlalu besar untuk apa yang awalnya dimaksudkan. Ketika saya melihat pengembang menulis kelas templating besar untuk apa yang dimaksudkan sebagai bahasa temporal prosedural, saya tidak bisa menahan senyum.

Jika Anda membandingkan kode OO yang ditulis dengan benar dengan kode prosedural yang ditulis dengan buruk, maka Anda akan selalu sampai pada kesimpulan yang salah. Sangat sedikit proyek yang membutuhkan desain Berorientasi Objek. Jika Anda adalah IBM dan mengelola proyek besar yang perlu dipertahankan selama bertahun-tahun oleh banyak pengembang, gunakan Object Oriented. Jika Anda menulis blog kecil atau situs web belanja untuk klien, pikirkan dua kali.

Untuk menjawab pertanyaan awal, OOP sulit karena tidak menyelesaikan dilema pemrograman kehidupan nyata tanpa menggunakan solusi yang 100 kali lebih rumit dari yang seharusnya. Salah satu solusi paling kuat untuk banyak masalah pemrograman adalah penggunaan data global secara bijaksana. Namun lulusan universitas gelombang baru akan memberi tahu Anda bahwa itu adalah no-no besar. Data yang tersedia secara global hanya berbahaya jika Anda adalah kelinci pemrograman yang canggung. Jika Anda memiliki seperangkat aturan ketat di tempat dan konvensi penamaan yang tepat, Anda bisa mendapatkan semua data Anda secara global.

Seharusnya merupakan persyaratan wajib bagi setiap programmer Berorientasi Objek untuk mengetahui cara menulis aplikasi bermain catur di assembler untuk memori maksimum yang tersedia 16K. Mereka kemudian akan belajar bagaimana memotong lemak, memotong kemalasan dan menghasilkan solusi yang cerdas.