Apakah OOP keras karena tidak alami?


86

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 adalah untuk 'pemrograman', itu dibuat untuk dinikmati oleh kompiler. ini bukan cara untuk memodelkan dunia nyata dengan cara apa pun. Adalah umum untuk menggunakan contoh dunia nyata seperti kelas hewan dan kelas persegi panjang, selama mengajar OOP tetapi ini hanya contoh untuk menyederhanakan konsep. Sayangnya, bahasa pemrograman dan paradigma 'terjadi' secara non-evolusioner dan non-ilmiah. Dengan beberapa pengecualian, proses desain bahasa biasanya anak dari tebakan terbaik beberapa orang!
NoChance

3
Saya akan tidak setuju dengan klaim "fokus OOP adalah merancang kelas individu dan hierarki mereka." karena maybie itu adalah fokus implementasi OOP tertentu, tetapi saya misalnya telah menemukan bahwa bahasa OOP dinamis biasanya tidak memiliki hierarki besar, atau bahkan kelas. Nah, definisi OOP dapat berubah di masa depan, ada upaya untuk mengubah bahkan Object one wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html
Azder

1
OOP mengidentifikasi objek dalam sistem dan membangun kelas berdasarkan objek tersebut. Bukan sebaliknya. Inilah sebabnya saya juga tidak setuju dengan "fokus OOP adalah merancang kelas individu dan hierarki mereka".
Radu Murzea


1
Saya pikir ini adalah pertanyaan yang sangat subyektif dan penuh dengan asumsi aneh tentang OOP dan apa "dunia nyata" itu dan bagaimana orang berpikir tentang masalah. Dan akhirnya ia bahkan bertanya, "Dan apa, jika ada, yang bisa dilakukan untuk menurunkannya?" yang benar-benar menunjukkan bahwa OP memiliki pendapat yang sangat kuat tentang hal ini. Jika Anda "religius" tentang paradigma pemrograman, saya kira Anda tidak memerlukan jawaban ... Anda sudah tahu apa yang ingin Anda dengar. Jika saya tahu tentang pertanyaan ini ketika pertama kali ditanyakan, saya mungkin akan memilih untuk menutupnya ...
Simon Lehmann

Jawaban:


97

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.


4
Saya pikir poin penting dalam pertanyaan itu bukanlah apakah OOP itu alami, tetapi apakah pendekatan arus utama terhadap OOP adalah pendekatan OOP yang paling alami. (Jawaban yang bagus.)
Giorgio

11
"OOP umumnya menunjukkan kegunaannya pada proyek-proyek besar di mana memiliki potongan-potongan kode yang benar-benar diperlukan.": Tetapi ini bukan properti spesifik dari OOP, karena ada konsep modul yang baik juga untuk bahasa pemrograman imperatif, fungsional, ... pemrograman .
Giorgio

2
OOP benar-benar pada poros yang berbeda dengan prosedural / fungsional; itu menangani bagaimana mengatur dan merangkum kode, bukan bagaimana menggambarkan operasi. (Anda selalu bermitra dengan OOP dengan paradigma eksekusi. Ya, ada bahasa fungsional OOP +.)
Donal Fellows

1
Tidak bisakah dikatakan bahwa OOP hanyalah kotak tempat kita meletakkan barang prosedural?
Erik Reppen

Di OOP, Anda masih bisa menulis metode. Apa yang membuat OOP lebih lemah dari pemrograman Prosedural?
Mert Akcakaya

48

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?


15
+1 untuk secara langsung menyebutkan bahwa pesan antara objek dan kepentingannya dari Alan Kay
bunglestink

3
@zvrba, memang, ada perintis OO lain juga, tapi itu intinya diskusi ini. "Hal yang paling alami adalah meminta teks untuk ditampilkan." - sekarang Anda menggunakan suara pasif yang sama dengan yang Anda klaim sangat "tidak alami" di OOP.
Péter Török

5
@zvrba, Anda mengatakan 'selalu ada "agen" [...] melakukan beberapa hal', namun memprotes pendekatan OO untuk mengidentifikasi dan memberi nama agen (objek), dan menangani mereka sebagai warga negara kelas satu dalam bahasa tersebut . Bagi saya ini adalah bagian dari pemodelan domain masalah - Anda tetap harus melakukan itu, hanya kemudian memetakan model domain yang dihasilkan ke kode dengan cara yang berbeda, tergantung pada apakah bahasa Anda OO atau tidak.
Péter Török

6
@ zvrba, ini bukan OO sendiri, tetapi pengembang / perancang yang memutuskan tentang peran dan tanggung jawab berbagai objek. Menggunakan pendekatan OO dapat menghasilkan model dan desain domain baik atau buruk, sama seperti menggunakan pisau dapat membuat Anda sepotong roti halus, atau jari berdarah - masih kami tidak menyalahkan pisau, karena itu hanya alat. Perhatikan juga bahwa konsep / objek / agen dalam model adalah abstraksi dari hal-hal di dunia nyata, dan karena itu selalu terbatas dan terdistorsi, hanya berfokus pada aspek "menarik" tertentu saja.
Péter Török

6
@ zvrba, mobil memang tidak memulai atas kehendaknya sendiri - seperti halnya Carobjek start()hanya ketika metodenya secara eksplisit dipanggil oleh seseorang.
Péter Török

10

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.


10
Saya tidak suka OOD karena saya lebih suka memikirkan bagaimana menyelesaikan masalah, titik. Saya tidak ingin memikirkan bagaimana menerjemahkan bahasa alami dari domain masalah ke dunia benda asing, pesan, warisan, dan sebagainya. Saya tidak ingin menemukan taksonomi hirarki di mana mereka tidak ada secara alami. Saya ingin menggambarkan masalah dalam bahasa aslinya dan menyelesaikannya dengan cara termudah. Dan, omong-omong, dunia tidak hanya terbuat dari "hal-hal yang melakukan hal-hal". Pandangan Anda tentang realitas sangat sempit.
SK-logic

7
@ Matt Ellen, saya menulis program yang memodelkan perilaku entites yang bukan "hal" dan yang tidak "melakukan" hal "apa pun". Setiap berubah entitas tidak melakukan apa-apa. Fungsi murni matematika apa pun tidak melakukan apa pun - itu hanyalah pemetaan dari satu set ke set lainnya, dan dunia ini sebagian besar dijelaskan oleh fungsi-fungsi tersebut. Formalisme logis apa pun tidak "melakukan" apa pun. Ya, OOD tidak akan membantu saya, karena saya dapat menggunakan abstraksi dan model yang jauh lebih kuat. Kembali ke OOD yang primitif, terbatas, terbatas akan membuat saya cacat berat.
SK-logic

2
@ Matt Ellen, ya, saya ingin melihat referensi yang mendukung klaim aneh bahwa dunia lebih baik dilihat sebagai kumpulan "hal-hal yang melakukan hal-hal", atau "objek yang berinteraksi melalui pesan". Ini sama sekali tidak wajar. Ambil teori ilmiah apa saja (karena mereka semua mendekati pemodelan dunia nyata yang dimungkinkan pada tahap ini), dan cobalah untuk menulis ulang menggunakan terminologi Anda. Hasilnya akan canggung dan canggung.
SK-logic

4
@ Antonio2011a, tidak ada paradigma pemrograman atau pemodelan tunggal yang dapat mencakup semua domain masalah yang mungkin secara efisien. OOP, fungsional, aliran data, logika orde pertama, apa pun - semuanya adalah paradigma masalah-domain spesifik dan tidak lebih. Saya hanya menganjurkan keragaman dan pendekatan terbuka untuk pemecahan masalah. Mempersempit pemikiran Anda menjadi satu paradigma hanya bodoh. Hal yang paling dekat dengan pendekatan universal, tidak membatasi Anda pada kerangka semantik tunggal, adalah en.wikipedia.org/wiki/Language-oriented_programming
SK-logic

3
@Calmarius mengapa Anda membuat pemrograman lebih mudah untuk komputer? Itu konyol. Manusialah yang harus melakukan pekerjaan lebih keras.
Matt Ellen

7

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.


1
Apa sebenarnya pekerjaan Anda bagi Anda untuk pindah dari cobol ke fortran, lalu ke perakitan (dan sisanya)?
Benteng

1
Pesanan salah. Sebenarnya, saya sudah mulai dengan Basic, kemudian pindah ke Fortran dan kemudian ke Assembly dan Cobol (ya, itu adalah urutan yang benar: Assembly first). Komputer pertama dalam hidup saya adalah mainframe "raksasa", memori 256kB, mesin tik konsolnya, memberinya makan dengan kartu punch, karena saya adalah operatornya. Ketika saya cukup bangkit untuk menjadi pemrogram sistem, sesuatu yang dicurigai bernama PC-AT telah mendarat di meja saya. Jadi saya terjun ke GW-Basic, Turbo-Pascal, ... dan seterusnya.
Nerevar

1
Saya tidak mengacu pada itu. Lebih banyak ke domain pekerjaan Anda; karena saya tidak tahu banyak orang (siapa pun benar-benar) yang berurusan dengan COBOL (berorientasi bisnis), fortran (domain ilmiah), assembler (lebih berorientasi cs) dan kemudian yang lainnya. Meskipun demikian mereka menjadi programmer profesional atau tidak.
Benteng

1
Tidak ada misteri: bergabung dengan tim dan proyek di mana keputusan tentang pendekatan laguage telah dibuat sebelumnya. Dan beberapa tingkat keingintahuan non-sepele tentang alat yang mereka gunakan.
Nerevar

6

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


Terima kasih telah menunjukkan bahaya mencoba menjadi model dunia.
Sean McMillan

4

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.


5
Ya, itu sama benarnya dengan segala jenis notasi formal yang mencoba menggambarkan dunia nyata secara tepat.
Péter Török

1
@ Péter Török, tepatnya maksud saya. Tidak ada formalisme tunggal yang mencakup segalanya. Anda harus menggunakan semuanya, di semua kerumunan mereka yang menakutkan. Dan itulah alasan mengapa saya percaya pada pemrograman berorientasi bahasa - memungkinkan untuk mengadopsi berbagai formalisme yang seringkali tidak kompatibel menjadi entitas kode yang solid.
SK-logic

1
Semuanya dapat dikategorikan ke dalam taksonomi hirarkis. Triknya adalah dengan skema yang masuk akal. Warisan berganda sering kali dilibatkan. Perbedaan besar antara perangkat lunak dan dunia nyata adalah bahwa di dunia nyata, kita sering harus menyimpulkan atau menemukan skema kategorisasi; dalam perangkat lunak, kami menciptakannya.
Caleb

1
Dengan menggunakan istilah seperti "taksonomi hierarkis", saya pikir Anda berpikir tentang warisan. Warisan memang sulit dipikirkan. Itu sebabnya orang menyarankan menggunakan komposisi di atas warisan.
Frank Shearar

1
@ Frank: Ada banyak jenis taksonomi hierarkis di dunia nyata, yang warisannya hanya satu. Melakukan semua ini dengan benar membutuhkan alat yang lebih baik daripada OOP (misalnya, penalaran ontologis) dan telah menyebabkan masalah bagi para filsuf selama ribuan tahun ...
Donal Fellows

4

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.


3

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 tampaknya sangat alami bagi saya, sebenarnya sulit bagi saya untuk memikirkan tugas pemrograman dengan cara lain. Namun, selama bertahun-tahun saya memahami bahwa OOP cenderung terlalu menekankan kata benda daripada kata kerja. Kata
Jim In Texas

3

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.


3

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.


3

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?


2

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.


2
Mata air muncul dalam jutaan bentuk, yang semuanya melakukan fungsi serupa . Saya akan mengatakan ini adalah contoh sempurna untuk pemrograman fungsional.
l0b0

2

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


Tetapi apakah Anda mengelompokkan menurut apakah beberapa objek memiliki atribut yang sama atau perilaku yang sama? Apakah semua yang memiliki nama dan nama keluarga seseorang? Apakah semua yang berjalan seekor binatang?
zvrba

Ketika datang ke kategorisasi, mampu melakukan perilaku tertentu adalah atribut. Zebra dan kuda bisa berkembang biak, tetapi keturunannya adalah hibrida. Sangat sulit untuk memprediksi hasil ini berdasarkan pada memiliki fungsi kawin kecuali Anda tahu mereka bukan spesies yang sama.
JeffO

1
@zvrba: Jawaban saya untuk pertanyaan yang diajukan dalam komentar adalah itu it doesn't matter. Segala sesuatu yang memiliki nama dan nama keluarga adalah orang untuk setiap program yang hanya peduli pada orang. Untuk program apa pun yang tidak memiliki pengetahuan orang atau non-orang, itu adalah IHasNameAndSurname. Objek hanya perlu menyelesaikan masalah yang ada.
Tom W

@ Jeff O Bahkan dalam spesies / breed / populasi yang sama ada variasi dan tidak ada contoh ideal (penting). Jadi, ya OO tidak seperti alam sebenarnya, tapi itu cocok dengan cara manusia berpikir secara alami.
Tom Hawtin - tackline

2

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.


1

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.


2
Pernahkah Anda melihat sistem modul yang tepat ? Bagaimana Anda bisa mengatakan bahwa OOP adalah hal terbaik yang tersedia? Modul SML jauh, jauh lebih kuat. Tapi, bahkan paket Ada sudah cukup untuk sebagian besar kasus, bahkan tanpa sedikitpun tanda OOP.
SK-logic

@ SK-logika, saya pikir Anda terpaku pada definisi yang terlalu tepat. Dengan OOP, maksud saya bukan kelas , maksud saya secara logis mengelompokkan "kata kerja" dengan "kata benda" yang mereka operasikan, dan dapat menggunakan kembali dan mengkhususkan kata kerja tersebut berdasarkan kata benda tertentu tempat mereka beroperasi. Kelas kebetulan merupakan implementasi yang paling terkenal dari itu, tetapi bukan satu - satunya implementasi. Saya mengakui ketidaktahuan modul SML, tetapi contoh pertama yang saya lihat ketika saya melihatnya adalah implementasi antrian yang bisa saja berasal dari buku desain OO mana pun dengan perubahan sintaksis agar berfungsi.
Karl Bielefeldt

tidak adil memberikan OOP yang disayangkan terlalu banyak untuk sesuatu yang bukan miliknya. Modul adalah penemuan hebat. Modul kelas satu sangat fantastis. Tapi OOP tidak ada hubungannya sama sekali dengan mereka. Beberapa bahasa OOP mengadopsi beberapa fitur modul (terutama - ruang nama), tetapi modul jauh lebih umum dan konsep yang kuat daripada kelas. Anda mengatakan bahwa kelas adalah "yang terbaik", yang jauh dari kebenaran. Modul kelas satu jauh lebih baik. Dan, tentu saja, sistem tipe jauh lebih luas dan lebih dalam daripada hanya OO dengan subtyping-nya.
SK-logic

1
"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.": Mungkin kami belum mencoba cukup lama. :-)
Giorgio

1
Saya pikir maksud Anda 'demokrasi': quotationspage.com/quote/364.html
nicodemus13

1

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.


1

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.


OP tidak berpendapat bahwa OO buruk pada umumnya dan harus diturunkan dari jabatannya tetapi bahwa "cara arus utama melakukan OOP" bukan yang paling alami (dibandingkan dengan "pengiriman ganda").
Giorgio

OP juga tampaknya terlalu fokus pada pendefinisian hierarki jenis, di mana program OO terbaik cenderung lebih mengandalkan antarmuka dan komposisi. Jika pengiriman ganda adalah X, maka membuat bahasa yang memungkinkan orang secara bertahap mempelajari keterampilan yang terkait dengan pengiriman ganda masih merupakan kunci untuk mengubah lingkungan.
Sean McMillan

1

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.


0

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.


0

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.


-1

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.


-3

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.

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.