Mengapa OOP sulit? [Tutup]


92

Ketika saya mulai menggunakan bahasa berorientasi objek (Java), saya cukup banyak hanya pergi "Keren" dan mulai coding. Saya tidak pernah benar-benar memikirkannya sampai baru-baru ini setelah membaca banyak pertanyaan tentang OOP. Kesan umum yang saya dapatkan adalah orang-orang bergumul dengannya. Karena saya belum menganggapnya susah, dan saya tidak akan mengatakan saya jenius, saya berpikir bahwa saya pasti melewatkan sesuatu atau salah paham.

Mengapa OOP sulit dipahami? Apakah sulit dimengerti?


72
Saya menentang: Tidak sulit untuk dipahami, hanya sulit untuk dikuasai. Pemrograman secara keseluruhan adalah cara ini.
Steven Evers

2
umm, bukan? Mungkin programmer yang tidak bisa memprogram menemukan kesulitan menyalahkan oops daripada baris kode mereka? Saya tidak tahu tetapi saya tidak pernah mendengar ada yang mengatakan itu sulit dimengerti. Namun saya melihat ppl mengatakan fungsional itu aneh terutama karena mereka tidak dapat mengubah nilai variabel mereka.

5
@ acidzombie42: fungsional sama sekali tidak aneh. Anda tidak perlu menulis daftar perintah untuk mengubah konten variabel yang mewakili lokasi dalam RAM. variabel mewakili nilai, Anda tidak mengubah nilai; 42 tetap 42, x tetap x - apa pun x adalah. Anda menulis fungsi yang memetakan dari parameternya ke hasil. nilai adalah: angka, daftar nilai, fungsi dari nilai ke nilai, program yang menghasilkan efek samping dan nilai yang dihasilkan pada eksekusi, dan banyak lagi. dengan begitu, hasil dari fungsi utama akan dihitung oleh kompiler, yaitu program yang dapat dieksekusi.
comonad

5
Saya telah belajar Haskell baru-baru ini. Semakin saya belajar dan mengerti tentang pemrograman fungsional, semakin saya merasa OOP sulit. Saya pikir alasan utama untuk ini adalah OOP mencoba untuk mengikat data (objek / kelas) bersama dengan fungsi yang beroperasi pada mereka (metode). Ini adalah sumber masalah dan banyak pola desain OOP dirancang untuk menghindari pengikatan data dan fungsi secara bersamaan. Contoh, pola pabrik digunakan untuk memisahkan konstruktor (yang merupakan fungsi) dari objek aktual yang beroperasi.
ming_codes

1
Karena itu salah nama. Itu harus benar-benar pemrograman berorientasi Subjek, di mana Subjek melakukan Aksi (kata kerja) dan Objek menerima Aksi - John melempar bola. Jadi johnsBall.throw () tidak terlalu masuk akal.
Chris Cudmore

Jawaban:


120

Saya pribadi menemukan mekanisme OOP cukup mudah untuk dipahami. Bagian yang sulit bagi saya adalah "mengapa" itu. Ketika saya pertama kali terkena itu, sepertinya solusi untuk mencari masalah. Berikut adalah beberapa alasan mengapa saya pikir kebanyakan orang merasa sulit:

  1. Mengajari OO sejak awal adalah ide yang buruk. Pengkodean prosedural bukan "kebiasaan buruk" dan merupakan alat yang tepat untuk beberapa pekerjaan. Metode individual dalam program OO cenderung terlihat cukup prosedural. Selain itu, sebelum mempelajari pemrograman prosedural dengan cukup baik sehingga keterbatasannya dapat terlihat, OO tampaknya tidak terlalu berguna bagi siswa.

  2. Sebelum Anda benar-benar dapat memahami OO, Anda perlu mengetahui dasar-dasar struktur data dan fungsi pengikatan / keteraturan yang lebih tinggi. Sulit untuk grok polimorfisme (yang pada dasarnya meneruskan pointer ke data dan banyak fungsi yang beroperasi pada data) jika Anda bahkan tidak memahami konsep penataan data, bukan hanya menggunakan primitif dan melewati fungsi orde tinggi / pointer ke fungsi.

  3. Pola desain harus diajarkan sebagai sesuatu yang mendasar bagi OO, bukan sesuatu yang lebih maju. Pola desain membantu Anda melihat hutan melalui pepohonan dan memberikan contoh yang relatif konkret tentang di mana OO dapat menyederhanakan masalah nyata, dan bagaimanapun juga Anda ingin mempelajarinya. Selain itu, begitu Anda benar-benar mendapatkan OO, sebagian besar pola desain menjadi jelas di belakang.


5
jawaban yang luar biasa, terutama nomor 1. Tentu saja metode dalam OO terlihat seperti metode dalam bahasa prosedural, tetapi sekarang mereka ditempatkan di objek yang juga memiliki status.
Dan Rosenstark

3
Saya terutama menyukai poin 1 dan 3 Anda. Teman saya gaga untuk pola desain, dan saya terus mengatakan kepadanya bahwa jika Anda hanya menggunakan OOP yang baik, kebanyakan dari mereka berasal secara alami dari masalah awal.
CodexArcanum

7
+1 untuk "Bagian tersulit bagi saya adalah" mengapa "itu". Dibutuhkan waktu dan upaya untuk memahami dan menerapkan dasar-dasar bahasa (enkapsulasi) dan prinsip-prinsip desain dan metode refactoring, menuju solusi bersama (pola desain).
Belun

12
Saya setuju dengan # 1, dengan peringatan bahwa Anda perlu melakukan pekerjaan yang lebih baik dalam menjelaskan OO kepada orang-orang yang sudah tahu cara memprogram secara prosedural daripada yang dilakukan ketika saya sedang belajar. Tidak, itu tidak berguna atau informatif untuk berbicara tentang Catkelas yang diwarisi dari Mammal, gunakan contoh nyata dari program nyata yang akan kami tulis secara prosedural. Seperti struktur data sederhana.
Carson63000

4
-1 Pola desain sangat ditekankan hari ini. Mereka penting, pasti, tetapi: pertama, mereka penting untuk semua paradigma: fungsional, terstruktur, serta OO; dan kedua, mereka bukan bagian dari paradigma, hanya add-on yang nyaman yang dapat Anda gunakan, seperti banyak lainnya. @SoftwareRockstar menjelaskan ini dengan baik dalam jawabannya.
CesarGon

56

Saya pikir ada beberapa faktor yang belum disebutkan.

Pertama-tama, setidaknya dalam "OOP murni" (mis., Smalltalk) di mana semuanya adalah objek, Anda harus memutar pikiran Anda menjadi konfigurasi yang agak tidak wajar untuk memikirkan angka (hanya untuk satu contoh) sebagai objek cerdas daripada objek hanya nilai - karena dalam kenyataannya, 21(misalnya) benar - benar hanya nilai. Ini menjadi sangat bermasalah ketika di satu sisi Anda diberitahu bahwa keuntungan besar dari OOP adalah memodelkan kenyataan lebih dekat, tetapi Anda memulainya dengan mengambil apa yang tampak sangat mengerikan seperti pandangan yang diinspirasi oleh LSD bahkan pada bagian yang paling dasar dan jelas dari realitas.

Kedua, pewarisan dalam OOP juga tidak mengikuti model mental kebanyakan orang. Bagi kebanyakan orang, mengklasifikasikan hal-hal yang paling spesifik tidak memiliki aturan mutlak yang diperlukan untuk membuat hierarki kelas yang berfungsi. Secara khusus, menciptakan class Dyang diwarisi dari yang lain class Bberarti bahwa objek class Dberbagi secara mutlak, positif semua karakteristik class B. class Ddapat menambahkan karakteristik baru dan berbeda sendiri, tetapi semua karakteristik class Bharus tetap utuh.

Sebaliknya, ketika orang mengklasifikasikan sesuatu secara mental, mereka biasanya mengikuti model yang jauh lebih longgar. Sebagai contoh, jika seseorang membuat beberapa aturan tentang apa yang merupakan kelas objek, itu cukup khas bahwa hampir semua aturan dapat dilanggar selama cukup banyak aturan lain yang diikuti. Bahkan beberapa aturan yang tidak bisa benar-benar dilanggar hampir selalu bisa "ditarik" sedikit pula.

Sebagai contoh, pertimbangkan "mobil" sebagai kelas. Sangat mudah untuk melihat bahwa sebagian besar dari apa yang kebanyakan orang pikirkan sebagai "mobil" memiliki empat roda. Namun, kebanyakan orang telah melihat (setidaknya gambar) mobil dengan hanya tiga roda. Beberapa dari kita di usia yang tepat juga ingat satu atau dua mobil balap dari awal 80-an (atau lebih) yang memiliki enam roda - dan seterusnya. Ini membuat kita pada dasarnya tiga pilihan:

  1. Jangan menyatakan apa pun tentang berapa banyak roda yang dimiliki mobil - tetapi ini cenderung mengarah pada asumsi tersirat bahwa itu akan selalu 4, dan kode yang kemungkinan akan rusak untuk nomor lain.
  2. Tegaskan bahwa semua mobil memiliki empat roda, dan hanya mengklasifikasikan yang lain sebagai "bukan mobil" meskipun kita tahu sebenarnya.
  3. Rancang kelas untuk memungkinkan variasi dalam jumlah roda, untuk jaga-jaga, meskipun ada kemungkinan bagus kemampuan ini tidak akan pernah diperlukan, digunakan, atau diuji dengan benar.

Mengajar tentang OOP sering berfokus pada membangun taksonomi besar - misalnya, potongan-potongan apa yang akan menjadi hierarki raksasa dari semua kehidupan yang dikenal di bumi, atau sesuatu dengan urutan itu. Ini menimbulkan dua masalah: pertama dan terutama, cenderung mengarahkan banyak orang untuk fokus pada sejumlah besar informasi yang sama sekali tidak relevan dengan pertanyaan yang ada. Pada satu titik saya melihat diskusi yang agak panjang tentang bagaimana memodelkan jenis anjing, dan apakah (misalnya) "pudel miniatur" harus diwarisi dari "pudel ukuran penuh", atau sebaliknya, atau apakah harus ada pangkalan abstrak "Poodle". "kelas, dengan" pudel ukuran penuh "dan" pudel miniatur "keduanya mewarisi darinya. Apa yang mereka semua tampaknya mengabaikan adalah bahwa aplikasi itu seharusnya berurusan dengan melacak lisensi untuk anjing,

Kedua, dan hampir penting, ini mengarah ke fokus pada karakteristik item, daripada berfokus pada karakteristik yang penting untuk tugas yang dihadapi. Ini mengarah pada memodelkan hal-hal sebagaimana adanya, di mana (sebagian besar waktu) yang benar-benar dibutuhkan adalah membangun model paling sederhana yang akan memenuhi kebutuhan kita, dan menggunakan abstraksi agar sesuai dengan sub-kelas yang diperlukan agar sesuai dengan abstraksi yang telah kita bangun.

Akhirnya, saya akan mengatakan sekali lagi: kami perlahan mengikuti jalur yang sama yang diambil oleh database selama bertahun-tahun. Database awal mengikuti model hierarkis. Selain berfokus secara eksklusif pada data, ini adalah warisan tunggal. Untuk waktu yang singkat, beberapa database mengikuti model jaringan - pada dasarnya identik dengan multiple inheritance (dan dilihat dari sudut ini, beberapa antarmuka tidak cukup berbeda dari beberapa kelas dasar untuk diperhatikan atau diperhatikan).

Dulu, bagaimanapun, basis data sebagian besar bertemu pada model relasional (dan meskipun mereka bukan SQL, pada tingkat abstraksi ini, basis data "NoSQL" saat ini juga bersifat relasional). Keuntungan dari model relasional sudah cukup dikenal sehingga saya tidak akan repot mengulanginya di sini. Saya hanya akan mencatat bahwa analog terdekat dari model relasional yang kita miliki dalam pemrograman adalah pemrograman generik (dan maaf, tetapi terlepas dari namanya, Java generics, misalnya, tidak benar-benar memenuhi syarat, meskipun mereka adalah langkah kecil dalam arah yang benar).


Dinyatakan dengan sangat baik, dan terutama bahwa sebagian besar masalah dengan OOP yang Anda berikan bukan hanya masalah dengan pemula yang memahaminya, tetapi lebih pada masalah OOP secara umum yang dipelajari oleh sebagian besar programmer OOP. Saya telah bekerja akhir-akhir ini dengan desain game di mana model komponen bekerja dengan sangat baik, yang memetakan erat dengan gagasan model relasional daripada hierarkis.
CodexArcanum

7
Heh, aku baru memikirkan hal ini tempo hari. Bagaimana semua materi pembelajaran pertama yang saya baca di OOP tampaknya berfokus pada pewarisan, sementara pengalaman saya semakin banyak memberi tahu saya bahwa pewarisan sebagian besar tidak berguna jika tidak berbahaya.
rmac

Kedengarannya seperti Pemrograman Berorientasi Tabel , meskipun saya akan mengatakan saya menyadari lebih banyak bahwa OOP bukan peluru perak pengembangan perangkat lunak.
OnesimusUnbound

1
@OnesimusUnbound: perbedaannya adalah bahwa pemrograman generik adalah cara nyata dan praktis untuk menyelesaikan sesuatu, sementara pemrograman berorientasi tabel sebagian besar adalah omelan orang gila tentang teori tentang bagaimana sesuatu dapat bekerja (baca posting lama TopMind di comp.object, dan Anda 'akan melihat apa yang saya maksud - sebenarnya, posting mungkin tidak semua menjadi tua; untuk semua yang saya tahu, dia melanjutkan bahkan hari ini).
Jerry Coffin

3
Itu sebabnya antarmuka sangat bagus. Anda mengambil pemodelan warisan dan membalikkannya ke pendekatan bredth-first. Misalnya, dengan contoh anjing, dapat diasumsikan bahwa setiap anjing memiliki genus dan hingga dua spesies super (satu untuk setiap induk) untuk jenis tertentu. Mungkin juga ada daftar properti yang mengandung sifat-sifat tetapi kemungkinan variasi membuatnya tidak ada gunanya untuk menyemir mereka ke dalam struktur yang pasti. Lebih baik menerapkan pencarian mendalam untuk merayapi ciri-ciri dan menggabungkan breed serupa berdasarkan hasil tersebut.
Evan Plaice

26

OOP membutuhkan kemampuan untuk berpikir secara abstrak; hadiah / kutukan yang benar-benar dimiliki oleh beberapa orang, bahkan programmer profesional.


35
Semua pemrograman bersifat abstrak.
JeffO

28
@ Jeff O - Saya tidak setuju. Pemrograman hanya membutuhkan kemampuan untuk memberi tahu seseorang bagaimana melakukan sesuatu secara bertahap. Jika Anda dapat memberi tahu seseorang cara membuat sandwich selai kacang & jelly, Anda memiliki kemampuan untuk mengetik perintah ke antarmuka pemrograman. Itu adalah set keterampilan yang sama sekali berbeda dari pemodelan ap, b & j sandwich secara abstrak dan bagaimana interaksi dengan dunia.
John Kraft

16
Menyerahkan seseorang 2 pensil dan kemudian memberikan 1 pensil dan menanyakan berapa banyak pensil yang mereka miliki, adalah beton. 2 + 1 = 3 adalah abstrak.
JeffO

17
Saya setuju dengan Jeff. Pemrograman pada dasarnya adalah mengelola abstraksi. Setidaknya itu berlaku untuk apa pun kecuali aliran program yang paling mendasar (karena segala sesuatu yang lain akan terlalu rumit tanpa abstraksi). Ada fase berbeda dalam belajar memprogram ketika pemula belajar bagaimana mengontrol abstraksi. Di situlah metafora resep jatuh. Pemrograman tidak seperti memasak dan meskipun algoritma individu dapat disamakan dengan resep, pemrograman pada dasarnya berbeda dari penerapan algoritma terisolasi.
Konrad Rudolph

2
@KonradRudolph Poin bagus. +1 untuk "Segala sesuatu yang lain akan menjadi terlalu rumit tanpa abstraksi" .
Karthik Sreenivasan

21

Saya pikir Anda dapat merangkum kesulitan dasar dengan cara ini:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

Tentu, orang bisa terbiasa dengan pemetaan "kiri" sebagai 270, dan ya, mengatakan "Mobil. Hidupkan" alih-alih "putar mobil" bukanlah lompatan besar. TETAPI, untuk menangani benda-benda ini dengan baik dan menciptakannya, Anda harus membalikkan cara berpikir Anda yang biasanya.

Alih-alih memanipulasi objek, kami memberi tahu objek untuk benar-benar melakukan sesuatu sendiri. Mungkin tidak terasa sulit lagi, tetapi mengatakan jendela untuk membuka sendiri terdengar aneh. Orang-orang yang tidak terbiasa dengan cara berpikir seperti ini harus berjuang dengan keanehan itu berulang-ulang sampai akhirnya entah bagaimana menjadi alami.


7
Wawasan yang bagus. Saya pikir masalahnya adalah bahwa dalam kehidupan nyata, tidak banyak yang bisa dilakukan "objek" yang tidak berhubungan dengan objek lain. OO berfungsi dengan baik sejauh objek diberitahu untuk memodifikasi keadaan internal mereka: rectangle.enlarge (margin_in_pixels) tapi saya menyadari batasannya tahun lalu. Suatu hari kami programmer sedang menginstal perangkat keras. Seseorang telah memecahkan "screw.turn" Lucu, tetapi itu membuat saya berpikir: tentu saja, sebuah sekrup dapat mengubah orientasinya, tetapi ini benar-benar sebuah operasi antara kabinet dan sekrup; tidak ada objek yang dapat melakukan tugas itu sendiri. OO tidak cukup baik.
DarenW

3
+1, setelah bertahun-tahun menulis "substr (tanggal, 0,4)", sulit untuk menulis "date.substring (0,4)"
ern0

4
+1 untuk cuplikan kode. Ini jelas menggambarkan proses pemikiran yang sebenarnya.
Karthik Sreenivasan

2
Saya sebenarnya akan membacanya sebagai perintah yang Anda kirim. Seperti pada "beri tahu mobil untuk belok kiri". Oop didasarkan pada pengiriman pesan ke objek, jadi itulah cara saya menafsirkannya.
bunglestink

1
Insight bagus, jadi mungkin OOP lebih cocok untuk pemodelan "sistem agen"?
Qbik

21

Paradigma apa pun membutuhkan dorongan "over the edge" untuk dipahami, bagi kebanyakan orang. Menurut definisi, ini adalah cara berpikir yang baru dan oleh karena itu diperlukan sejumlah pelepasan gagasan lama dan sejumlah pemahaman sepenuhnya mengapa gagasan baru ini berguna.

Saya pikir banyak masalahnya adalah metode yang digunakan untuk mengajar pemrograman komputer secara umum sangat buruk. OOP sangat umum sekarang sehingga tidak begitu terlihat, tetapi Anda masih sering melihatnya dalam pemrograman fungsional:

  • konsep-konsep penting tersembunyi di balik nama-nama aneh (FP: Apa itu monad? OOP: Mengapa mereka menyebutnya fungsi kadang-kadang dan metode lain kali?)

  • konsep aneh dijelaskan dalam metafora alih-alih dalam hal apa yang sebenarnya mereka lakukan, atau mengapa Anda akan menggunakannya, atau mengapa ada orang yang berpikir untuk menggunakannya (FP: Monad adalah pakaian antariksa, itu membungkus beberapa kode. OOP: An objek seperti bebek, dapat membuat suara, berjalan dan mewarisi dari Hewan)

  • barang bagus bervariasi dari orang ke orang, jadi tidak jelas apa yang akan menjadi titik kritis bagi siswa mana pun, dan seringkali guru bahkan tidak dapat mengingatnya. (FP: Oh, monad membiarkan Anda menyembunyikan sesuatu dalam tipe itu sendiri dan meneruskannya tanpa harus secara eksplisit menuliskan apa yang terjadi setiap kali. OOP: Oh, objek memungkinkan Anda menyimpan fungsi untuk jenis data dengan data itu.)

Yang terburuk adalah bahwa, seperti yang ditunjukkan oleh pertanyaan, beberapa orang akan segera memahami mengapa konsep itu baik, dan sebagian lagi tidak. Itu benar-benar tergantung pada apa titik kritisnya. Bagi saya, memahami bahwa objek menyimpan data dan metode untuk data itu adalah kuncinya, setelah itu segala sesuatu yang lain hanya cocok sebagai ekstensi alami. Kemudian saya kemudian melompat seperti menyadari bahwa pemanggilan metode dari suatu objek sangat mirip dengan membuat panggilan statis dengan objek itu sebagai parameter pertama.

Lompatan kecil di kemudian hari membantu memperbaiki pemahaman, tetapi yang pertama membutuhkan seseorang dari "OOP tidak masuk akal, mengapa orang melakukan ini?" untuk "OOP adalah yang terbaik, mengapa orang melakukan hal lain?"


8
Saya terutama benci metaforisme, lebih sering daripada tidak, mereka membingungkan daripada menggambarkan.
Lie Ryan

3
"Lalu saya kemudian melompat seperti menyadari bahwa pemanggilan metode dari suatu objek sangat mirip dengan membuat panggilan statis dengan objek itu sebagai parameter pertama." Saya berharap ini lebih ditekankan dari awal, seperti dalam bahasa seperti Python.
Jared Updike

1
Masalah saya dengan menggunakan metafora untuk menjelaskan konsep adalah bahwa guru sering berhenti pada metafora, seolah-olah itu menjelaskan semuanya. Tidak, itu bukan penjelasan lengkap; itu hanya sebuah ilustrasi untuk membantu kita memahami penjelasan yang sebenarnya .
jhocking

Jawaban bagus! +1 untuk menjelaskan bahwa langkah pertama untuk memahami OOP akan lebih signifikan daripada apa yang muncul kemudian sebagai ekstensi alami dengan pemahaman yang baik tentang yayasan. : D
Karthik Sreenivasan

dittos pada pembelajaran "lompatan": Ketika saya mulai menganggap OOP sebagai "hanya" konstruksi modular / terstruktur / step-wise, tetapi pada steroid; ketika saya menulis ulang beberapa program COBOL yang sangat tua dan hancur-rawat. Meskipun ruang lingkup global COBOL saya pada dasarnya telah menerapkan prinsip-prinsip OO dengan struktur catatan kustom, variabel tujuan tunggal, dan paragraf (metode) yang terfokus, modular, & terstruktur.
radarbob

15

Karena penjelasan dasar OOP sangat, sangat sedikit hubungannya dengan bagaimana itu digunakan di lapangan. Sebagian besar program untuk mengajarinya mencoba menggunakan model fisik, seperti "Pikirkan mobil sebagai objek, dan roda sebagai objek, dan pintu, dan transmisi ...", tetapi di luar beberapa kasus pemrograman simulasi yang tidak jelas, objek jauh lebih sering digunakan untuk mewakili konsep non-fisik atau untuk memperkenalkan tipuan. Efeknya adalah itu membuat orang memahaminya secara intuitif dengan cara yang salah.

Mengajar dari pola desain adalah cara yang jauh lebih baik untuk menggambarkan OOP, karena menunjukkan kepada programmer bagaimana beberapa masalah pemodelan aktual dapat secara efektif diserang dengan objek, daripada menggambarkannya secara abstrak.


13

Saya tidak setuju dengan jawaban dsimcha untuk sebagian besar:

  1. Mengajarkan OO sejak awal bukanlah ide yang buruk dalam dirinya sendiri, juga mengajar bahasa prosedural. Yang penting adalah kami mengajar orang untuk menulis kode yang jelas, ringkas, kohesif, terlepas dari OO atau prosedural.

  2. Metode individual dalam program OO yang baik JANGAN cenderung prosedural sama sekali. Ini menjadi semakin dan semakin benar dengan evolusi bahasa OO (baca C # karena selain C ++ itulah satu-satunya bahasa OO lain yang saya tahu) dan sintaksisnya yang semakin kompleks setiap hari (lambdas, LINQ ke objek, dll.). Satu-satunya kesamaan antara metode dan prosedur OO dalam bahasa prosedural adalah sifat linear masing-masing, yang saya ragu akan berubah dalam waktu dekat.

  3. Anda tidak dapat menguasai bahasa prosedural tanpa memahami struktur data. Konsep pointer sama pentingnya untuk bahasa prosedural seperti untuk bahasa OO. Melewati parameter dengan referensi, misalnya, yang cukup umum dalam bahasa prosedural, mengharuskan Anda untuk memahami pointer sebanyak yang diperlukan untuk mempelajari bahasa OO.

  4. Saya tidak berpikir bahwa pola desain harus diajarkan di awal pemrograman OO sama sekali, karena mereka tidak mendasar sama sekali pemrograman OO. Seseorang pasti bisa menjadi programmer OO yang baik tanpa mengetahui apa pun tentang pola desain. Bahkan seseorang bahkan dapat menggunakan pola desain yang terkenal tanpa mengetahui bahwa mereka didokumentasikan dengan nama yang tepat dan bahwa buku-buku ditulis tentang mereka. Apa yang harus diajarkan secara mendasar adalah prinsip-prinsip desain seperti Tanggung Jawab Tunggal, Tutup Terbuka, dan Segregasi Antarmuka. Sayangnya, banyak orang yang menganggap diri mereka sebagai pemrogram OO akhir-akhir ini tidak mengenal konsep dasar ini atau hanya memilih untuk mengabaikannya dan itulah sebabnya kami memiliki begitu banyak kode OO sampah di luar sana.

Untuk menjawab pertanyaan poster asli, ya, OO adalah konsep yang lebih sulit untuk dipahami daripada pemrograman prosedural. Ini karena kita tidak berpikir dalam hal sifat dan metode objek kehidupan nyata. Sebagai contoh, otak manusia tidak dengan mudah menganggap "TurnOn" sebagai metode TV, tetapi melihatnya sebagai fungsi memutar manusia di TV. Demikian pula, polimorfisme adalah konsep asing bagi otak manusia yang umumnya melihat setiap objek kehidupan nyata hanya dengan satu "wajah". Warisan lagi tidak alami bagi otak kita. Hanya karena saya seorang pengembang bukan berarti anak saya akan menjadi pengembang. Secara umum, otak manusia perlu dilatih untuk belajar OO sementara bahasa prosedural lebih alami.


2
+1 - Saya juga tidak berpikir pola desain diperlukan untuk pengajaran OOP di tingkat dasar, Anda bisa menjadi programmer OOP yang baik dan tidak tahu pola desain apa pun. Di sisi lain Anda cenderung melihat pola desain yang dikenal muncul secara alami dari programmer OOP yang baik. Pola desain selalu ditemukan, bukan diciptakan.
Gary Willoughby

1
+1 - Jawaban yang bagus. Saya suka poin ke-4 yang telah Anda nyatakan. Sangat benar bahwa seseorang dapat menjadi programmer OO yang baik tanpa mengetahui apa desain sebenarnya!
Karthik Sreenivasan

Saya setuju dengan # 4 karena sebagian besar pola desain hanyalah pendekatan bubblegum / lakban untuk pengkodean secara tegas di sekitar keterbatasan bahasa. Dalam paradigma lain, pola desain mungkin sama sekali berbeda dan berdasarkan kendala mereka sendiri. Saya tidak setuju dengan 2, LINQ dan lambdas masih mengeksekusi secara prosedural mereka hanya menyediakan abstraksi tingkat tinggi yang dikemas dengan rapi. Luangkan waktu yang signifikan untuk berkembang dengan bahasa prosedural / fungsional yang diketik secara dinamis seperti JavaScript dan Anda akan melihat apa yang saya maksud.
Evan Plaice

6

Saya pikir banyak programmer mengalami kesulitan dengan desain dimuka dan perencanaan untuk memulai. Bahkan jika seseorang melakukan semua desain untuk Anda, masih mungkin untuk melepaskan diri dari prinsip-prinsip OOP. Jika saya mengambil banyak kode spageti dan membuangnya ke dalam kelas, apakah itu benar-benar OOP? Seseorang yang tidak mengerti OOP masih bisa memprogram di Jawa. Juga, jangan bingung kesulitan memahami dengan tidak mau mengikuti metode tertentu atau tidak setuju dengan itu.


5

Anda harus membaca Objects Never? Yah, Hampir Tidak Pernah. (Keanggotaan ACM diperlukan) oleh Mordechai Ben-Ari yang menyarankan bahwa OOP sangat sulit, karena itu bukan paradigma yang sebenarnya wajar untuk memodelkan apa pun. (Meskipun saya memiliki keberatan tentang artikel tersebut, karena tidak jelas kriteria apa yang menurutnya perlu dipenuhi oleh suatu program untuk mengatakan bahwa itu ditulis pada paradigma OOP sebagai lawan dari paradigma prosedural menggunakan bahasa OO.)


5

Pemrograman Berorientasi Objek itu sendiri tidak sulit.

Bagian yang sulit adalah melakukannya dengan baik. Di mana harus meletakkan potongan di antara kode sehingga Anda dapat dengan mudah memindahkan sesuatu ke objek basis umum, dan memperpanjangnya nanti? Cara membuat kode Anda dapat digunakan oleh orang lain (memperluas kelas, membungkus proxy, menimpa metode) tanpa melompat melalui lingkaran untuk melakukannya.

Itu adalah bagian yang sulit, dan jika dilakukan dengan benar bisa sangat elegan, dan jika dilakukan dengan buruk bisa sangat canggung. Pengalaman pribadi saya adalah bahwa itu memerlukan banyak latihan untuk berada dalam semua situasi di mana Anda akan BERHARAP bahwa Anda melakukannya secara berbeda, untuk melakukannya dengan cukup baik kali ini .


"Pengalaman pribadi saya adalah bahwa itu memerlukan banyak latihan untuk berada dalam semua situasi di mana Anda akan BERHARAP bahwa Anda melakukannya secara berbeda, untuk melakukannya dengan cukup baik kali ini." OOP sepertinya daftar cara yang dikodifikasikan untuk tidak melakukan kesalahan, yang tidak masuk akal sampai Anda telah melakukan kesalahan dengan semua cara itu.
Pembaruan Jared

@ Jared, tidak cukup. Bandingkan dengan memecahkan sodukus. Ada berbagai trik yang dapat Anda lakukan untuk menyelesaikannya, tetapi perlu waktu dan latihan untuk melakukannya dengan baik tanpa mundur.

Jika seseorang berpikir tentang "objek dasar yang sama" seperti leluhur yang sama maka itu menjadi jelas. Sangat sederhana. Sulit untuk memahami b / c ada begitu banyak penjelasan yang menyesatkan di luar sana dari orang-orang yang berusaha terlihat pintar.
annoying_squid

4

Saya baru saja menonton video oleh Richard Feynman yang membahas bagaimana orang-orang mungkin benar-benar memiliki metodologi yang berbeda dalam pikiran mereka ketika berpikir - maksud saya benar-benar berbeda.

Ketika saya melakukan desain tingkat tinggi, saya kebetulan memvisualisasikan objek, saya bisa melihatnya, melihat antarmuka mereka dan melihat jalur apa yang perlu dilalui informasi.

Saya juga kesulitan mengingat detail dan menemukan OO sebagai alat bantu organisasi yang hebat - jauh lebih mudah untuk menemukan fungsionalitas daripada memindai melalui daftar subrutin yang terorganisir secara longgar.

Bagi saya OO adalah manfaat besar, tetapi jika Anda tidak memvisualisasikan dengan cara yang sama atau tidak melakukan arsitektur tingkat tinggi, itu mungkin tidak ada gunanya dan menjengkelkan.


+1 Saya merasakan hal yang sama, tetapi ada banyak dorongan di arah yang berlawanan, termasuk Ruby mixins ... yang membuat Anda menyadari bahwa OO ketat bukan untuk semua orang.
Dan Rosenstark

@ Yar Yap, itu cukup banyak yang saya katakan. Walaupun secara pribadi saya tidak dapat membayangkan sesuatu yang lebih baik (dan Ruby memberi saya NUTS untuk tahun saya menggunakannya), saya mulai menerima bahwa setiap orang memiliki cara berbeda untuk melihatnya. Mungkin beberapa orang menggunakan sentuhan atau pendengaran ketika berpikir alih-alih memvisualisasikan dan OO tidak cocok untuk mereka.
Bill K

Saya pikir itu juga membantu mendorong konvensi penamaan yang lebih alami. Anda tidak perlu lagi menyandikan jenis fungsi ke dalam nama fungsi (seperti INSTR) - karena nama tersebut terlampir pada jenis fungsi (seperti string::find)
Ken Bloom

@Ken meskipun saya setuju, saya pikir itu lebih merupakan masalah pengetikan yang kuat daripada OO - Ruby memiliki OO tetapi Anda kehilangan banyak jenis info karena pengetikan bebek - Ruby cenderung hanya mengatakan "kirim (itu)" dan berharap Anda tahu metode sihir apa "itu" harus diterapkan untuk bekerja.
Bill K

@ Bill, kamu benar. Ini lebih merupakan masalah bahasa yang mendukung pemrograman generik. Anda bisa mendapatkan konvensi penamaan alami yang bagus dengan sistem modul dan typeclass seperti Haskell's, dan tidak ada yang OO tentang Haskell. Jika C mengalami kelebihan muatan, Anda bisa mendapatkan jenis nama generik yang sama dalam C.
Ken Bloom

4

Saya telah melakukan GW-Basic dan Turbo Pascal pemrograman sedikit yang adil sebelum diperkenalkan ke OO, sehingga awalnya DID melakukan kepalaku di.

Tidak tahu apakah ini yang terjadi pada orang lain, tetapi bagi saya itu seperti ini: proses pemikiran saya tentang pemrograman murni prosedural. Seperti dalam: "ini dan itu terjadi, maka ini dan itu terjadi selanjutnya", dll. Saya tidak pernah menganggap variabel dan data lebih dari sekadar aktor sekilas dalam aliran program. Pemrograman adalah "aliran tindakan".

Saya kira apa yang tidak mudah dipahami (sebodoh yang terlihat bagi saya sekarang), adalah gagasan bahwa data / variabel sebenarnya sangat penting , dalam arti yang lebih dalam daripada sekadar menjadi aktor sekilas dalam program "flow". Atau dengan kata lain: Saya terus berusaha memahaminya melalui apa yang terjadi , bukan melalui apa yang ada , yang merupakan kunci nyata untuk menggenggamnya.


Sudut pandang yang menarik. Ketika saya berjuang untuk memahami proyek C ++ besar, saya pikir saya sebaliknya, berpikir terutama dalam hal data, "jalur sinyal" bit dari beberapa "input" ke beberapa "output". Sementara saya juga banyak melakukan Basic dan Pascal, pemikiran teknis saya yang paling awal adalah di bidang elektronik.
DarenW

3

Saya tidak berpikir itu sulit untuk dipahami tetapi mungkin banyak programmer yang bertanya pada konsep baru, berasal dari bahasa prosedural.

Dari apa yang saya lihat / baca banyak orang (di forum setidaknya) mencari 'hasil' dari OOP. Jika Anda seorang programmer prosedural yang tidak kembali dan memodifikasi memperpanjang kode mereka mungkin sulit untuk memahami manfaatnya.

Juga, ada banyak OOP buruk di luar sana, jika orang membaca / melihat itu maka mudah untuk melihat mengapa mereka merasa kesulitan.

IMO Anda harus menunggu sampai 'klik' atau diajarkan oleh seseorang dengan pengetahuan nyata, saya tidak berpikir Anda bisa terburu-buru.


5
Jika Anda berasal dari lingkungan akademis, jenis-jenis program mainan yang Anda tulis di sana juga benar-benar tidak berguna di OOP. Saya mulai belajar C di perguruan tinggi, dan itu cukup mudah untuk dipahami karena setiap program adalah 1 halaman, kurang dari 100 baris. Kemudian Anda mencoba mempelajari OOP dan itu membutuhkan semua barang bawaan dan benda-benda di atas hanya untuk melakukan hal yang sama, dan sepertinya tidak ada gunanya. Tetapi sampai Anda telah menulis sebuah program di banyak file dan beberapa ribu baris, sulit untuk melihat mengapa gaya pemrograman apa pun bermanfaat.
CodexArcanum

3

Saya pikir alasan OOP sulit bagi banyak orang adalah karena alat tidak benar-benar memfasilitasi itu.

Bahasa komputer saat ini adalah abstraksi dari apa yang terjadi di komputer.

OOP adalah cara abstrak untuk mewakili abstraksi.

Jadi kami menggunakan abstraksi untuk membangun abstraksi dengan abstraksi. Tambahkan ke ini bahwa apa yang kita abstraksi biasanya interaksi fisik / sosial yang sangat kompleks dan, yah, tidak heran.


2

Saya sebenarnya memiliki sebuah blog bernama "Perjuangan dalam Pemrograman Berorientasi Objek," yang lahir dari beberapa perjuangan saya untuk mempelajarinya. Saya pikir itu sangat sulit bagi saya untuk mengerti karena saya menghabiskan begitu banyak waktu menggunakan pemrograman prosedural, dan saya memiliki waktu yang sulit mendapatkan kepala saya di sekitar gagasan bahwa suatu objek dapat diwakili oleh kumpulan atribut dan perilaku (saya terbiasa hanya kumpulan variabel dan metode).

Juga, ada banyak konsep yang membuat objek bahasa berorientasi - pewarisan, antarmuka, polimorfisme, komposisi, dll. Ada banyak hal yang perlu dipelajari tentang teori itu sebelum Anda benar-benar dapat menulis kode secara efektif, dan dalam objek-berorientasi cara, sedangkan dengan pemrograman prosedural, itu hanya masalah memahami hal-hal seperti alokasi memori untuk variabel, dan panggilan titik masuk ke metode lain.


Setuju - banyak kesulitan yang orang miliki dengan OO adalah mereka telah melatih diri mereka untuk berpikir 'secara prosedural'. Tidak ada yang secara inheren sulit tentang OO tetapi jika Anda 'tahu' teknik prosedural maka akan cukup mengejutkan melihat cara lain untuk menyusun berbagai hal.
Kirk Broadhurst

Tidak diragukan lagi itu adalah cara berpikir yang sama sekali berbeda dari pemrograman prosedural. Tetapi bertentangan dengan apa yang dikatakan banyak orang, itu bukan A) cara berpikir yang tidak wajar, dan B) rumit. Saya hanya berpikir itu tidak diajarkan dengan baik.
annoying_squid

2

Motivasi. Lebih sulit untuk mempelajari sesuatu ketika Anda tidak melihat mengapa, dan juga ketika Anda tidak dapat melihat apa yang Anda lakukan dan mencari tahu apakah Anda melakukannya dengan benar atau tidak.

Yang dibutuhkan adalah proyek kecil yang menggunakan OO untuk melakukan hal-hal yang bermanfaat. Saya sarankan melihat-lihat buku tentang pola desain dan menghasilkan yang jelas berguna dan bekerja dengan baik dengan OO. (Saya menggunakan Strategi saat saya mencobanya. Sesuatu seperti Flyweight atau Singleton akan menjadi pilihan yang buruk, karena mereka cara menggunakan objek secara umum, tidak menggunakan objek untuk mencapai sesuatu.)


Orang-orang selalu membicarakan Singleton, tetapi kemudian dia selalu diundang ke pesta itu. Tapi itu benar, dia adalah OO DP non-OO.
Dan Rosenstark

-1

Saya pikir itu tergantung pada usia (usia sebagai proxy untuk pengalaman) dan, yang lebih penting, minat. Jika Anda "muda" (yaitu, hijau, mungkin) dan Anda tidak pernah berpikir dengan cara lain, sepertinya cukup mudah. Di sisi lain, jika Anda pikir itu hal paling keren yang pernah Anda lihat - terjadi pada saya pada usia 28 atau sesuatu - mudah grok.

Di sisi lain, jika Anda berpikir, seperti yang dilakukan oleh banyak siswa Java saya, "mengapa kita belajar ini, itu hanya iseng," praktis tidak mungkin untuk belajar. Ini berlaku untuk sebagian besar teknologi.


1
Oo fad? Berapa usia murid-murid Anda - saya kira "mode" ini lebih tua dari mereka (OO pertama yang saya lakukan - yang saya tahu saya lakukan - adalah Simula sekitar tahun 1983/4 dan Simula bukan orang baru pada saat itu)
Murph

@Murph Ini sekitar tahun 2004-2005 dan para siswa pasti lebih dari 45-50 (programmer profesional di Iberia).
Dan Rosenstark

ok, saya bisa melihat bagaimana mereka mungkin melewatkan awal hal OO. Tetapi pada tahun 2004/5 kami berada di dalam. NET yang merupakan dinding ke dinding OO (-: Ada beberapa hal dalam pengembangan yang dapat digambarkan sebagai mode tetapi hal-hal yang tidak gagal dengan cepat cenderung berkembang menjadi hal yang baik
Murph

1
@ Murph jujur ​​orang-orang ini adalah programmer mainframe yang mereka coba konversi ke Jawa. Itu sebenarnya pengalaman yang lucu dan unik (bukan tarif normal untuk hari-hari Java Trainer saya). Ini adalah benar, bagaimanapun, bahwa mereka telah melihat banyak hal datang dan pergi, tapi jelas OO lebih dari iseng-iseng. Pada catatan terpisah: Saya agak berharap hal Unit Testing ini akan reda sebagai mode, tapi sekarang saya menemukan bahwa saya memiliki banyak unit test untuk ditulis ... :)
Dan Rosenstark

-1

Apa pun paradigma (OOP, fungsional, dll) yang Anda pilih, untuk menulis program komputer, Anda perlu mengetahui langkah-langkah apa yang akan dilakukan program Anda.

Cara alami mendefinisikan suatu proses adalah menuliskan langkah-langkahnya, untuk tugas yang lebih besar Anda memecah tugas menjadi langkah-langkah yang lebih kecil. Ini adalah cara prosedural, ini adalah cara komputer bekerja, ini adalah bagaimana Anda melewati daftar periksa Anda langkah demi langkah.

OOP adalah cara berpikir yang berbeda. Alih-alih memikirkan daftar tugas yang perlu dilakukan langkah demi langkah, Anda memikirkan objek, kemampuan dan hubungan mereka. Jadi Anda akan menulis banyak objek, metode kecil dan program Anda akan secara ajaib bekerja. Untuk mencapai ini, Anda perlu memutar pikiran ...

Dan inilah mengapa OOP sulit. Karena semuanya adalah objek, yang mereka lakukan hanyalah meminta objek lain untuk melakukan sesuatu, dan objek lain itu pada dasarnya melakukan beberapa hal. Jadi kontrol dalam program OOP liar bisa melompat-lompat di antara objek.


-1

Sebagai seseorang yang saat ini sedang mempelajari pemrograman dan memiliki beberapa masalah di bidang ini, saya tidak berpikir bahwa konsepnya sulit untuk dipahami sebagaimana implementasi spesifik dari konsep tersebut. Saya mengatakan ini karena saya mendapatkan ide OOP, dan saya telah menggunakannya dalam PHP selama sekitar satu tahun, tetapi ketika saya beralih ke C # dan melihat penggunaan objek oleh programmer lain, saya menemukan bahwa banyak orang melakukannya dengan cara yang saya tidak mengerti. Ini secara khusus yang telah menuntun saya ke jalan untuk menemukan pemahaman yang lebih baik tentang prinsip-prinsip OOP.

Tentu saja, saya menyadari bahwa masalah ini kemungkinan besar adalah kurangnya pengalaman saya dengan bahasa asli-OOP, dan seiring berjalannya waktu saya akan menemukan cara-cara baru untuk memanfaatkan objek yang akan sama tidak jelasnya dengan programmer baru seperti saya. sedang mengalami. Jerry Coffin menyentuhnya beberapa kali, khususnya dalam komentarnya:

Ini menjadi sangat bermasalah ketika di satu sisi Anda diberitahu bahwa keuntungan besar dari OOP adalah memodelkan kenyataan lebih dekat, tetapi Anda memulainya dengan mengambil apa yang tampak sangat mengerikan seperti pandangan yang diinspirasi oleh LSD bahkan pada bagian yang paling dasar dan jelas dari realitas.

Saya menemukan ini sangat akurat, karena kesan yang sering saya dapatkan ketika melihat seseorang membuat kelas untuk hal-hal yang tidak benar-benar hal - contoh spesifik luput dari saya, tapi yang paling dekat saya dapat dengan cepat adalah memperlakukan jarak seperti sebuah objek (saya akan mengedit waktu berikutnya saya melihat sesuatu yang menyebabkan kebingungan yang sama). Kadang-kadang, OOP tampaknya mengabaikan sementara aturannya sendiri dan menjadi kurang intuitif. Ini lebih sering terjadi ketika objek memproduksi objek, mewarisi dari kelas yang mengenkapsulasi mereka, dan sebagainya.

Saya pikir untuk orang seperti saya, ada baiknya memikirkan konsep objek sebagai memiliki banyak sisi, salah satunya termasuk memperlakukan sesuatu seperti objek padahal sebenarnya tidak. Sesuatu seperti jarak, dengan hanya sedikit perubahan paradigma, dapat dianggap sebagai objek teoretis, tetapi tidak satu pun yang bisa dipegang di tangan Anda. Saya harus menganggapnya sebagai memiliki seperangkat properti tetapi seperangkat perilaku yang lebih abstrak, seperti mengakses propertinya. Saya tidak yakin bahwa ini adalah kunci untuk pemahaman saya, tetapi tampaknya di mana studi saya saat ini sedang memimpin.


1
Sepasang titik atau objek harus dianggap sebagai objek. Dan jarak harus diambil sebagai fungsi dari objek. Menggunakan objek tidak berarti Anda membuat objek dari segalanya.
Gangnus

Seperti yang saya katakan, jarak adalah contoh yang buruk. Mengenai membuat objek dari segala sesuatu, saya merujuk secara khusus pada apa yang telah saya lihat terjadi, bukan apa yang sebenarnya telah saya lakukan - yang belum ada.
dsimer

Itu tergantung pada bahasa - di SmallTalk jarak (dan semuanya) ADALAH objek. Tetapi dalam C # Anda telah menyebutkan itu akan buruk.
Gangnus

-2

Terminologi adalah benjolan saya di jalan ketika mempelajari prinsip-prinsip pemrograman berorientasi objek (POOP). Itu ketika Anda memahami dasar-dasar bahwa potongan-potongan mulai jatuh ke tempatnya. Sama seperti semua hal belajar konsep baru agak sulit.

Setuju bahwa pola desain harus kuat setidaknya sejajar dengan OOP.


-2

Lompatan utama bagi saya adalah hanya memahami konsep abstrak OOP. Sekarang saya sangat baru dalam pemrograman pada umumnya saya telah memprogram selama satu tahun sampai satu setengah tahun sekarang jadi pengantar saya ke OOP adalah dengan Actionscript dan Processing. Ketika saya pertama kali belajar coding Actionscript, itu tidak di OOP. Saya belajar kode langsung ke panel Tindakan dan itulah bagaimana saya belajar dasar-dasar pemrograman (variabel, fungsi, loop dll). Jadi saya mempelajarinya sebagai melakukan sesuatu langsung ke panggung dalam Flash atau Pemrosesan.

Ketika OOP muncul, menyadari bahwa saya dapat membuat metode dan properti dalam suatu objek untuk dapat digunakan dan digunakan kembali agak sulit bagi saya untuk dipahami pada awalnya. Semuanya sangat abstrak dan sulit untuk diproses, tetapi bahasa pemrogramannya sendiri jauh lebih baik, tetapi agak sulit untuk membuat koneksi pada awalnya.


wow bagian dari itu tidak masuk akal. "Semuanya sangat abstrak dan sulit untuk diproses antara kelas dan instance objek dll. Tapi bahasa pemrograman menjadi jauh lebih mudah dipahami setelah saya mendapatkan OOP. Tapi agak butuh lompatan faitl untuk membuat koneksi pada awalnya"

-2

resep

Pemahaman OOP Bagus = Mentor Baik Atau Buku Bagus Atau Keduanya + Minat Pribadi + Praktek.

Ketertarikan pribadi

Dari pengalaman pribadi saya, minat pribadi datang jauh untuk melintasi jembatan dari pemrograman prosedural ke OOP dengan input yang tepat dari mentor atau buku bagus atau keduanya digabungkan .

Berlatih, Berlatih dan Berlatih

Sahabat saya untuk mendapatkan pemahaman yang lebih baik tentang OOP tidak lain adalah latihan. Ini pasti akan menumbuhkan kemampuan OOP Anda.

Seperti kata pepatah, "Tidak ada pengganti untuk kerja keras dan tidak ada jalan pintas menuju kesuksesan."

Semoga berhasil!

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.