Apa gunanya OOP?

Sejauh yang saya tahu, terlepas dari jutaan atau miliaran yang dihabiskan untuk pendidikan OOP, bahasa, dan alat, OOP belum meningkatkan produktivitas pengembang atau keandalan perangkat lunak, juga tidak mengurangi biaya pengembangan. Hanya sedikit orang yang menggunakan OOP dalam arti yang ketat (hanya sedikit orang yang mematuhi atau memahami prinsip-prinsip seperti LSP); tampaknya ada sedikit keseragaman atau konsistensi dengan pendekatan yang dilakukan orang untuk memodelkan domain masalah. Terlalu sering, kelas digunakan hanya untuk gula sintaksisnya; itu menempatkan fungsi untuk tipe catatan ke dalam namespace kecil mereka sendiri.

Saya telah menulis sejumlah besar kode untuk berbagai aplikasi. Meskipun ada tempat-tempat di mana subtyping yang dapat diganti benar memainkan peran yang berharga dalam aplikasi, ini sudah sangat luar biasa. Secara umum, meskipun banyak layanan bibir diberikan kepada pembicaraan tentang "re-use" kenyataannya adalah bahwa kecuali sepotong kode tidak persis apa yang Anda ingin lakukan, ada sangat sedikit hemat biaya "digunakan kembali". Sangat sulit untuk mendesain kelas agar dapat diperluas dengan cara yang benar , sehingga biaya perpanjangan biasanya sangat besar sehingga "menggunakan kembali" sama sekali tidak bermanfaat.

Dalam banyak hal, ini tidak mengejutkan saya. Dunia nyata bukan "OO", dan gagasan yang tersirat dalam OO - bahwa kita dapat membuat model dengan beberapa taksonomi kelas - bagi saya kelihatannya sangat cacat mendasar (saya bisa duduk di atas meja, tunggul pohon, kap mobil) , pangkuan seseorang - tetapi bukan salah satu dari itu adalah-kursi). Bahkan jika kita pindah ke domain yang lebih abstrak, pemodelan OO seringkali sulit, berlawanan dengan intuisi, dan pada akhirnya tidak membantu (pertimbangkan contoh klasik lingkaran / elips atau kuadrat / bujur sangkar).

Jadi apa yang saya lewatkan di sini? Di mana nilai OOP, dan mengapa semua waktu dan uang gagal membuat perangkat lunak lebih baik?

Tidak ada bukti empiris yang menunjukkan bahwa orientasi objek adalah cara yang lebih alami bagi orang untuk berpikir tentang dunia. Ada beberapa pekerjaan di bidang psikologi pemrograman yang menunjukkan bahwa OO entah bagaimana lebih cocok daripada pendekatan lain.

Representasi berorientasi objek tampaknya tidak secara universal lebih bermanfaat atau kurang berguna.

Tidak cukup hanya mengadopsi metode OO dan mengharuskan pengembang untuk menggunakan metode seperti itu, karena itu mungkin berdampak negatif pada produktivitas pengembang, serta kualitas sistem yang dikembangkan.

Yang berasal dari "On Usability of OO Representations" dari Communications of the ACM Oktober 2000. Artikel-artikel tersebut terutama membandingkan OO dengan pendekatan yang berorientasi pada proses. Ada banyak penelitian tentang bagaimana orang-orang yang bekerja dengan metode OO "berpikir" (Int. J. dari Human-Computer Studies 2001, edisi 54, atau Human-Computer Interaction 1995, vol. 10 memiliki tema keseluruhan pada studi OO), dan dari apa yang saya baca, tidak ada yang menunjukkan semacam kealamian pada pendekatan OO yang membuatnya lebih cocok daripada pendekatan prosedural yang lebih tradisional.

Dunia nyata bukanlah "OO", dan gagasan yang tersirat dalam OO - bahwa kita dapat membuat model dengan beberapa taksonomi kelas - bagi saya sangat cacat secara mendasar.

Meskipun ini benar dan telah diamati oleh orang lain (ambil Stepanov, penemu STL), sisanya adalah omong kosong. OOP mungkin cacat dan tentu saja bukan peluru perak, tetapi itu membuat aplikasi skala besar jauh lebih sederhana karena itu cara yang bagus untuk mengurangi ketergantungan. Tentu saja, ini hanya berlaku untuk desain OOP "baik". Desain ceroboh tidak akan memberikan keuntungan apa pun. Tapi desain decoupled yang baik dapat dimodelkan dengan sangat baik menggunakan OOP dan tidak baik menggunakan teknik lain.

Ada banyak model yang lebih baik dan lebih universal (model tipe Haskell muncul di pikiran) tetapi ini juga sering lebih rumit dan / atau sulit untuk diterapkan secara efisien. OOP merupakan trade-off yang baik antara ekstrem.

OOP bukan tentang membuat kelas yang dapat digunakan kembali, ini tentang membuat kelas yang dapat digunakan.

Terlalu sering, kelas digunakan hanya untuk gula sintaksisnya; itu menempatkan fungsi untuk tipe catatan ke dalam namespace kecil mereka sendiri.

Ya, saya menemukan ini terlalu lazim juga. Ini bukan Pemrograman Berorientasi Objek. Ini Pemrograman Berbasis Objek dan pemrograman sentris data. Dalam 10 tahun saya bekerja dengan Bahasa OO, saya melihat orang-orang kebanyakan melakukan Pemrograman Berbasis Objek. OBP memecah IMHO sangat cepat karena Anda pada dasarnya mendapatkan yang terburuk dari kedua kata: 1) pemrograman prosedural tanpa mengikuti metodologi pemrograman terstruktur terbukti dan 2) OOP tanpa mengikuti metodologi OOP terbukti.

OOP yang dilakukan dengan benar adalah hal yang indah. Itu membuat masalah yang sangat sulit mudah untuk dipecahkan, dan bagi yang belum tahu (tidak berusaha terdengar sombong di sana), itu hampir bisa tampak seperti sulap. Yang sedang berkata, OOP hanyalah satu alat di toolbox metodologi pemrograman. Bukan akhir dari semua metodologi. Itu hanya terjadi sesuai dengan aplikasi bisnis besar dengan baik.

Sebagian besar pengembang yang bekerja dalam bahasa OOP menggunakan contoh-contoh OOP yang dilakukan dengan benar dalam kerangka dan jenis yang mereka gunakan sehari-hari, tetapi mereka tidak menyadarinya. Berikut adalah beberapa contoh yang sangat sederhana: ADO.NET, Hibernate / NHibernate, Logging Frameworks, berbagai jenis koleksi bahasa, tumpukan ASP.NET, JSP stack dll ... Ini semua adalah hal-hal yang sangat bergantung pada OOP dalam basis kode mereka.

Penggunaan kembali tidak boleh menjadi tujuan OOP - atau paradigma lainnya dalam hal ini.

Penggunaan kembali adalah efek samping dari desain yang baik dan tingkat abstraksi yang tepat. Kode mencapai penggunaan kembali dengan melakukan sesuatu yang bermanfaat, tetapi tidak melakukan sebanyak yang membuatnya tidak fleksibel. Tidak masalah apakah kodenya OO atau tidak - kami menggunakan kembali yang berfungsi dan tidak sepele untuk melakukannya sendiri. Itu pragmatisme.

Pemikiran OO sebagai cara baru untuk dapat digunakan kembali melalui warisan pada dasarnya cacat. Seperti yang Anda perhatikan, pelanggaran LSP berlimpah. Alih-alih, OO dianggap sebagai metode untuk mengelola kompleksitas domain masalah. Tujuannya adalah pemeliharaan sistem dari waktu ke waktu. Alat utama untuk mencapai ini adalah pemisahan antarmuka publik dari implementasi pribadi. Ini memungkinkan kita untuk memiliki aturan seperti "Ini hanya boleh dimodifikasi menggunakan ..." yang diberlakukan oleh kompiler, daripada review kode.

Menggunakan ini, saya yakin Anda akan setuju, memungkinkan kami untuk membuat dan memelihara sistem yang sangat kompleks. Ada banyak nilai dalam hal itu, dan tidak mudah dilakukan dalam paradigma lain.

Beragama agama tetapi saya akan mengatakan bahwa Anda melukis gambar yang terlalu suram tentang keadaan OOP modern. Saya berpendapat bahwa itu sebenarnya telah mengurangi biaya, membuat proyek-proyek perangkat lunak besar dapat dikelola, dan sebagainya. Itu tidak berarti itu memecahkan masalah mendasar dari kekacauan perangkat lunak, dan itu tidak berarti pengembang rata-rata adalah seorang ahli OOP. Tetapi modularisasi fungsi menjadi komponen-objek tentu saja telah mengurangi jumlah kode spageti di dunia.

Saya bisa memikirkan lusinan perpustakaan dari atas kepala saya yang dapat digunakan kembali dengan indah dan yang telah menghemat waktu dan uang yang tidak pernah dapat dihitung.

Tetapi sejauh OOP telah membuang-buang waktu, saya akan mengatakan itu karena kurangnya pelatihan programmer, diperparah oleh kurva pembelajaran curam belajar pemetaan OOP bahasa tertentu. Beberapa orang "mendapatkan" OOP dan yang lain tidak akan pernah.

Saya pikir penggunaan objek konteks buram (HANDLE di Win32, FILE * s di C, untuk menyebutkan dua contoh terkenal - neraka, HANDLE hidup di sisi lain dari penghalang mode kernel, dan itu benar-benar tidak mendapatkan jauh lebih enkapsulasi daripada itu) ditemukan dalam kode prosedural juga; Saya berjuang untuk melihat bagaimana ini sesuatu yang khusus untuk OOP.

HANDLEs (dan WinAPI lainnya) adalah OOP! C tidak mendukung OOP dengan baik sehingga tidak ada sintaks khusus tetapi itu tidak berarti tidak menggunakan konsep yang sama. WinAPI dalam segala hal kata kerangka kerja berorientasi objek.

Lihat, ini adalah masalah dengan setiap diskusi yang melibatkan OOP atau teknik alternatif: tidak ada yang jelas tentang definisi, semua orang berbicara tentang sesuatu yang lain dan dengan demikian tidak ada konsensus yang dapat dicapai. Sepertinya buang-buang waktu bagiku.

Ini adalah paradigma pemrograman .. Dirancang untuk membuatnya lebih mudah bagi kita manusia biasa untuk memecah masalah menjadi lebih kecil, bagian yang bisa dikerjakan ..

Jika Anda merasa itu tidak berguna .. Jangan menggunakannya, jangan membayar untuk pelatihan dan bahagia.

Saya di sisi lain memang merasa berguna, jadi saya akan :)

Sehubungan dengan pemrograman prosedural yang lurus, prinsip fundamental pertama OOP adalah gagasan menyembunyikan informasi dan enkapsulasi. Ide ini mengarah pada gagasan kelas yang memisahkan antarmuka dari implementasi. Ini adalah konsep yang sangat penting dan dasar untuk menempatkan kerangka kerja di tempat untuk berpikir tentang desain program dengan cara yang berbeda dan cara yang lebih baik (saya pikir). Anda tidak dapat benar-benar menentang properti-properti tersebut - tidak ada trade-off yang dibuat dan selalu merupakan cara yang lebih bersih untuk memodulasi hal-hal.

Aspek-aspek lain dari OOP termasuk pewarisan dan polimorfisme juga penting, tetapi seperti yang telah disinggung oleh orang-orang, itu biasanya digunakan secara berlebihan. yaitu: Kadang-kadang orang menggunakan warisan dan / atau polimorfisme karena mereka bisa, bukan karena seharusnya. Mereka adalah konsep yang kuat dan sangat berguna, tetapi perlu digunakan secara bijak dan tidak otomatis menjadi keunggulan OOP.

Relatif untuk digunakan kembali. Saya setuju digunakan kembali lebih dari penjualan untuk OOP. Ini adalah efek samping yang mungkin dari objek yang terdefinisi dengan baik, biasanya dari kelas yang lebih primitif / generik dan merupakan akibat langsung dari konsep enkapsulasi dan penyembunyian informasi. Ini berpotensi lebih mudah untuk digunakan kembali karena antarmuka kelas yang didefinisikan dengan baik hanya lebih jelas dan agak mendokumentasikan diri.

Masalah dengan OOP adalah oversold.

Seperti Alan Kay awalnya disusun itu, itu adalah alternatif yang bagus untuk praktik sebelumnya memiliki data mentah dan semua rutinitas global.

Kemudian beberapa tipe konsultan manajemen mengaitkannya dan menjualnya sebagai messiah perangkat lunak, dan seperti lemming, akademisi dan industri jatuh setelahnya.

Sekarang mereka seperti jatuh lemming setelah ide bagus lainnya oversold, seperti pemrograman fungsional.

Jadi, apa yang akan saya lakukan secara berbeda? Banyak, dan saya menulis buku tentang ini. (Sudah tidak dicetak - saya tidak mendapatkan satu sen, tetapi Anda masih bisa mendapatkan salinan.) Amazon

Jawaban konstruktif saya adalah melihat pemrograman bukan sebagai cara memodelkan hal-hal di dunia nyata, tetapi sebagai cara pengkodean persyaratan.

Itu sangat berbeda, dan didasarkan pada teori informasi (pada tingkat yang dapat dipahami siapa pun). Dikatakan bahwa pemrograman dapat dipandang sebagai proses mendefinisikan bahasa, dan keterampilan dalam melakukannya adalah penting untuk pemrograman yang baik.

Ini mengangkat konsep domain-bahasa-spesifik (DSL). Itu setuju dengan tegas dengan KERING (jangan ulangi sendiri). Ini memberi acungan jempol besar untuk pembuatan kode. Ini menghasilkan perangkat lunak dengan struktur data jauh lebih sedikit daripada yang khas untuk aplikasi modern.

Ia berusaha untuk menguatkan kembali gagasan bahwa jalan ke depan terletak pada penemuan, dan bahkan gagasan yang diterima dengan baik pun harus dipertanyakan.

HANDLE (dan anggota WinAPI lainnya) adalah OOP!

Apakah mereka demikian? Mereka tidak bisa diwariskan, mereka tentu saja tidak dapat diganti, mereka tidak memiliki kelas yang terdefinisi dengan baik ... Saya pikir mereka jauh dari "OOP".

Pernahkah Anda membuat jendela menggunakan WinAPI? Maka Anda harus tahu bahwa Anda mendefinisikan kelas ( RegisterClass), membuat instance dari itu ( CreateWindow), memanggil metode virtual ( WndProc) dan metode kelas-dasar ( DefWindowProc) dan seterusnya. WinAPI bahkan mengambil nomenklatur dari SmallTalk OOP, menyebut metode "pesan" (Pesan Jendela).

Pegangan mungkin tidak dapat diwariskan tetapi kemudian, ada finaldi Jawa. Mereka tidak kekurangan kelas, mereka adalah pengganti untuk kelas: Itulah arti kata "pegangan". Melihat arsitektur seperti MFC atau .NET WinForms segera jelas bahwa kecuali sintaksisnya, tidak banyak yang berbeda dari WinAPI.

Ya OOP tidak menyelesaikan semua masalah kami, maaf soal itu. Namun, kami sedang mengerjakan SOA yang akan menyelesaikan semua masalah itu.

OOP cocok untuk pemrograman struktur komputer internal seperti "widget" GUI, di mana misalnya SelectList dan TextBox mungkin subtipe Item, yang memiliki metode umum seperti "bergerak" dan "mengubah ukuran".

Masalahnya adalah, 90% dari kita bekerja di dunia bisnis di mana kita bekerja dengan konsep bisnis seperti Faktur, Karyawan, Pekerjaan, Pesanan. Ini tidak cocok untuk OOP karena "objek" lebih samar, dapat berubah sesuai dengan rekayasa ulang bisnis dan sebagainya.

Kasus terburuk adalah di mana OO secara antusias diterapkan ke database, termasuk "peningkatan" OO yang mengerikan untuk database SQL - yang diabaikan dengan benar kecuali oleh basis data yang menganggap bahwa mereka harus menjadi cara yang tepat untuk melakukan sesuatu karena mereka lebih baru.

Dalam pengalaman saya meninjau kode dan desain proyek yang telah saya lalui, nilai OOP tidak sepenuhnya terwujud karena banyak pengembang belum mengonseptualisasikan model berorientasi objek dengan benar dalam pikiran mereka. Jadi mereka tidak memprogram dengan desain OO, sangat sering terus menulis kode prosedural top-down membuat kelas-kelas yang cukup datar desain yang . (jika Anda bahkan dapat memanggil "desain" itu di tempat pertama)

Sangat menakutkan untuk mengamati bagaimana kolega kecil tahu tentang apa kelas abstrak atau antarmuka, apalagi merancang hierarki warisan yang sesuai dengan kebutuhan bisnis.

Namun, ketika desain OO yang baik hadir, itu hanya kegembiraan belaka membaca kode dan melihat kode secara alami masuk ke dalam komponen / kelas yang intuitif. Saya selalu merasa arsitektur sistem dan desain seperti merancang berbagai departemen dan pekerjaan staf di sebuah perusahaan - semua ada di sana untuk menyelesaikan pekerjaan tertentu dalam skema besar, memancarkan sinergi yang diperlukan untuk mendorong organisasi / sistem ke depan.

Sayangnya , itu cukup langka . Seperti rasio benda-benda fisik yang dirancang dengan indah dan sangat mengerikan di dunia, hal yang sama dapat dikatakan tentang rekayasa dan desain perangkat lunak. Memiliki alat-alat bagus yang tersedia bagi seseorang tidak serta merta memberikan praktik dan hasil yang baik.

Mungkin topi, pangkuan, atau pohon bukanlah kursi, tetapi semuanya bisa ISITI.

Saya pikir benda-benda dunia nyata itu benda

Kamu lakukan?

Metode apa yang dimiliki faktur? Oh tunggu. Itu tidak bisa membayar sendiri, tidak bisa mengirim sendiri, tidak bisa membandingkan dirinya dengan barang yang benar-benar dikirimkan oleh vendor. Itu tidak memiliki metode sama sekali; itu benar-benar lembam dan tidak berfungsi. Ini adalah tipe rekaman (sebuah struct, jika Anda mau), bukan objek.

Demikian juga hal-hal lain yang Anda sebutkan.

Hanya karena sesuatu itu nyata tidak menjadikannya objek dalam arti kata OO. Objek-objek OO adalah gabungan khusus dari keadaan dan perilaku yang dapat bertindak atas kemauannya sendiri. Itu bukan sesuatu yang berlimpah di dunia nyata.

Saya telah menulis kode OO selama 9 tahun terakhir ini. Selain menggunakan olahpesan, sulit bagi saya untuk membayangkan pendekatan lain. Manfaat utama yang saya lihat benar-benar sejalan dengan apa yang dikatakan CodingTheWheel: modularisasi. OO secara alami menuntun saya untuk membangun aplikasi saya dari komponen modular yang memiliki antarmuka yang bersih dan tanggung jawab yang jelas (yaitu longgar digabungkan, kode yang sangat kohesif dengan pemisahan keprihatinan yang jelas).

Saya pikir di mana OO rusak adalah ketika orang membuat pusaka kelas yang sangat bersarang. Ini dapat menyebabkan kompleksitas. Namun, memasukkan finctionality umum ke dalam kelas dasar, kemudian menggunakan kembali bahwa di kelas turunan lainnya adalah hal yang sangat elegan, IMHO!

Pertama, pengamatannya agak ceroboh. Saya tidak memiliki angka pada produktivitas perangkat lunak, dan tidak memiliki alasan yang baik untuk percaya itu tidak naik. Lebih lanjut, karena ada banyak orang yang menyalahgunakan OO, penggunaan OO yang baik tidak akan menyebabkan peningkatan produktivitas bahkan jika OO adalah hal terbesar sejak selai kacang. Bagaimanapun, seorang ahli bedah otak yang tidak kompeten cenderung lebih buruk daripada tidak sama sekali, tetapi yang kompeten bisa sangat berharga.

Yang sedang berkata, OO adalah cara yang berbeda untuk mengatur sesuatu, melampirkan kode prosedural ke data daripada memiliki kode prosedural beroperasi pada data. Ini harus setidaknya menang kecil dengan sendirinya, karena ada kasus di mana pendekatan OO lebih alami. Tidak ada yang menghentikan siapa pun untuk menulis API prosedural dalam C ++, dan karenanya pilihan untuk menyediakan objek malah membuat bahasa lebih fleksibel.

Lebih jauh, ada sesuatu yang dilakukan dengan sangat baik oleh OO: memungkinkan kode lama untuk memanggil kode baru secara otomatis, tanpa perubahan. Jika saya memiliki kode yang mengatur hal-hal secara prosedural, dan saya menambahkan hal-hal baru yang serupa tetapi tidak identik dengan yang sebelumnya, saya harus mengubah kode prosedural. Dalam sistem OO, saya mewarisi fungsi, mengubah apa yang saya suka, dan kode baru secara otomatis digunakan karena polimorfisme. Ini meningkatkan lokalitas perubahan, dan itu adalah Good Thing.

Kelemahannya adalah bahwa OO yang baik tidak gratis: itu membutuhkan waktu dan usaha untuk mempelajarinya dengan benar. Karena ini adalah kata kunci utama, ada banyak orang dan produk yang melakukannya dengan buruk, hanya demi melakukannya. Tidaklah mudah untuk merancang antarmuka kelas yang baik daripada API prosedural yang baik, dan ada segala macam kesalahan yang mudah dibuat (seperti hierarki kelas dalam).

Anggap saja sebagai alat yang berbeda, umumnya tidak selalu lebih baik. Palu selain obeng, katakanlah. Mungkin kita akhirnya akan keluar dari praktik rekayasa perangkat lunak karena mengetahui kunci pas mana yang digunakan untuk memalu sekrup.

@Sean

Namun, memasukkan finctionality umum ke dalam kelas dasar, kemudian menggunakan kembali bahwa di kelas turunan lainnya adalah hal yang sangat elegan, IMHO!

Tetapi pengembang "prosedural" telah melakukan itu selama beberapa dekade. Sintaks dan terminologinya mungkin berbeda, tetapi efeknya identik. Ada lebih banyak untuk OOP daripada "menggunakan kembali fungsi umum dalam kelas dasar", dan saya bahkan mungkin mengatakan bahwa itu sulit untuk digambarkan sebagai OOP sama sekali; Memanggil fungsi yang sama dari bit kode yang berbeda adalah teknik yang sama tuanya dengan sub-prosedur itu sendiri.

@Konrad

OOP mungkin cacat dan tentu saja bukan peluru perak tetapi itu membuat aplikasi skala besar jauh lebih sederhana karena itu cara yang bagus untuk mengurangi ketergantungan

Itu adalah dogma. Saya tidak melihat apa yang membuat OOP secara signifikan lebih baik dalam hal ini daripada pemrograman prosedural lama. Setiap kali saya melakukan panggilan prosedur saya mengisolasi diri dari spesifikasi implementasi.

Bagi saya, ada banyak nilai dalam sintaks OOP itu sendiri. Menggunakan objek yang berusaha mewakili hal-hal nyata atau struktur data seringkali jauh lebih berguna daripada mencoba menggunakan sekelompok fungsi flat (atau "mengambang") yang berbeda untuk melakukan hal yang sama dengan data yang sama. Ada "aliran" alami tertentu untuk hal-hal dengan OOP yang baik yang lebih masuk akal untuk membaca, menulis, dan memelihara jangka panjang.

Tidak masalah bahwa Faktur sebenarnya bukan "objek" dengan fungsi yang dapat ia lakukan sendiri - instance objek dapat ada hanya untuk melakukan fungsi pada data tanpa harus mengetahui jenis data apa yang sebenarnya ada. Fungsi "invoice.toJson ()" dapat dipanggil dengan sukses tanpa harus tahu apa jenis data "faktur" - hasilnya akan menjadi Json, tidak masalah apakah itu berasal dari database, XML, CSV, atau bahkan objek JSON lainnya . Dengan fungsi prosedural, Anda tiba-tiba harus tahu lebih banyak tentang data Anda, dan berakhir dengan fungsi seperti "xmlToJson ()", "csvToJson ()", "dbToJson ()", dll. Pada akhirnya menjadi berantakan dan Sakit kepala besar jika Anda pernah mengubah tipe data yang mendasarinya.

Maksud dari OOP adalah untuk menyembunyikan implementasi aktual dengan memisahkannya. Untuk mencapai tujuan itu, Anda harus membuat antarmuka publik. Untuk membuat pekerjaan Anda lebih mudah saat membuat antarmuka publik dan menjaga hal-hal KERING, Anda harus menggunakan konsep-konsep seperti kelas abstrak, pewarisan, polimorfisme, dan pola desain.

Jadi bagi saya, tujuan utama OOP yang sebenarnya adalah membuat pemeliharaan dan perubahan kode di masa mendatang lebih mudah. Tetapi bahkan lebih dari itu, itu bisa sangat menyederhanakan banyak hal ketika dilakukan dengan benar dengan cara yang tidak pernah bisa dilakukan oleh kode prosedural. Tidak masalah jika tidak cocok dengan "dunia nyata" - pemrograman dengan kode tidak berinteraksi dengan objek dunia nyata. OOP hanyalah alat yang membuat pekerjaan saya lebih mudah dan lebih cepat - saya akan melakukannya setiap hari.

@CodingTheWheel

Tetapi sejauh OOP telah membuang-buang waktu, saya akan mengatakan itu karena kurangnya pelatihan programmer, diperparah oleh kurva pembelajaran curam belajar pemetaan OOP bahasa tertentu. Beberapa orang "mendapatkan" OOP dan yang lain tidak akan pernah.

Saya tidak tahu apakah itu benar-benar mengejutkan. Saya pikir secara teknis pendekatan (LSP menjadi hal yang jelas) membuat sulit untuk digunakan , tetapi jika kita tidak menggunakan pendekatan seperti itu membuat kode rapuh dan tidak dapat dipertahankan lagi (karena kita tidak dapat lagi alasan tentang hal itu). Dan saya pikir hasil yang berlawanan dengan intuisi yang membuat OOP membuat kita tidak mengejutkan bahwa orang tidak mengambilnya.

Lebih penting lagi, karena perangkat lunak sudah terlalu sulit bagi manusia normal untuk menulis dengan andal dan akurat, haruskah kita benar-benar memuji teknik yang secara konsisten diajarkan dengan buruk dan tampaknya sulit untuk dipelajari? Jika manfaatnya jelas, maka mungkin ada gunanya bertahan meskipun kesulitan, tapi itu tampaknya tidak menjadi masalah.

@ Jeff

Sehubungan dengan pemrograman prosedural yang lurus, prinsip fundamental pertama OOP adalah gagasan menyembunyikan informasi dan enkapsulasi. Ide ini mengarah pada gagasan kelas yang memisahkan antarmuka dari implementasi.

Yang memiliki implementasi lebih tersembunyi: iostreams C ++, atau C's FILE * s?

Saya pikir penggunaan objek konteks buram (HANDLE di Win32, FILE * s di C, untuk menyebutkan dua contoh terkenal - neraka, HANDLE hidup di sisi lain dari penghalang mode kernel, dan itu benar-benar tidak mendapatkan jauh lebih enkapsulasi daripada itu) ditemukan dalam kode prosedural juga; Saya berjuang untuk melihat bagaimana ini sesuatu yang khusus untuk OOP.

Saya kira itu mungkin menjadi bagian dari mengapa saya berjuang untuk melihat manfaatnya: bagian yang jelas baik tidak spesifik untuk OOP, sedangkan bagian yang khusus untuk OOP tidak jelas baik! (Ini bukan untuk mengatakan bahwa mereka selalu buruk, tetapi lebih karena saya belum melihat bukti bahwa mereka berlaku luas dan secara konsisten bermanfaat).

Di satu-satunya blog dev yang saya baca, oleh lelaki Joel-On-Software-Founder-SO, saya membaca sejak lama bahwa OO tidak menyebabkan peningkatan produktivitas. Manajemen memori otomatis tidak. Keren. Siapa yang bisa menolak data?

Saya masih percaya bahwa OO adalah untuk non-OO apa pemrograman dengan fungsi untuk memprogram semuanya sesuai.

(Dan saya harus tahu, ketika saya mulai dengan GWBasic.) Ketika Anda refactor kode untuk menggunakan fungsi, variable2654menjadi variable3metode yang Anda gunakan . Atau, lebih baik lagi, itu punya nama yang dapat Anda pahami, dan jika fungsinya pendek , Itu disebut value dan itu cukup untuk pemahaman penuh.

Ketika kode tanpa fungsi menjadi kode dengan metode, Anda bisa menghapus mil kode.

Ketika Anda refactor kode untuk benar-benar OO, b, c, q, dan Zmenjadi this, this, thisdan this. Dan karena saya tidak percaya menggunakan thiskata kunci, Anda bisa menghapus mil kode. Sebenarnya, Anda bisa melakukannya bahkan jika Anda menggunakannya this.

Saya tidak berpikir OO adalah metafora alami.

Saya tidak berpikir bahasa adalah metafora alami juga, saya juga tidak berpikir bahwa "bau" Fowler lebih baik daripada mengatakan "kode ini rasanya tidak enak." Yang mengatakan, saya pikir bahwa OO bukan tentang metafora alami dan orang-orang yang berpikir objek hanya muncul pada Anda pada dasarnya kehilangan intinya. Anda mendefinisikan objek semesta, dan objek semesta yang lebih baik menghasilkan kode yang lebih pendek, lebih mudah dipahami, bekerja lebih baik, atau semua ini (dan beberapa kriteria saya lupa). Saya berpikir bahwa orang yang menggunakan objek alami pelanggan / domain sebagai objek pemrograman kehilangan kekuatan untuk mendefinisikan kembali alam semesta.

Misalnya, ketika Anda melakukan sistem reservasi penerbangan, apa yang Anda sebut reservasi mungkin tidak sesuai dengan reservasi hukum / bisnis sama sekali.

Beberapa konsep dasar adalah alat yang sangat keren

Saya pikir sebagian besar orang melebih-lebihkan dengan keseluruhan "ketika Anda memiliki palu, semuanya adalah paku". Saya pikir sisi lain dari koin / cermin itu sama benarnya: ketika Anda memiliki gadget seperti polimorfisme / pewarisan, Anda mulai menemukan kegunaan yang cocok seperti sarung tangan / kaus kaki / lensa kontak. Alat-alat OO sangat kuat. Warisan tunggal, saya pikir, mutlak diperlukan agar orang tidak terbawa, perangkat lunak multi-warisan saya sendiri tidak tahan.

Apa gunanya OOP?

Saya pikir ini cara yang bagus untuk menangani basis kode yang sangat besar. Saya pikir itu memungkinkan Anda mengatur dan mengatur ulang kode Anda dan memberi Anda bahasa untuk melakukannya di (di luar bahasa pemrograman tempat Anda bekerja), dan memodulasi kode dengan cara yang cukup alami dan mudah dimengerti.

OOP ditakdirkan untuk disalahpahami oleh sebagian besar pengembang

Ini karena ini adalah proses yang membuka mata seperti kehidupan: Anda semakin memahami OO dengan pengalaman, dan mulai menghindari pola-pola tertentu dan mempekerjakan orang lain ketika Anda menjadi lebih bijaksana. Salah satu contoh terbaik adalah Anda berhenti menggunakan pewarisan untuk kelas yang tidak Anda kontrol, dan lebih memilih pola Facade sebagai gantinya.

Mengenai esai / pertanyaan Anda

Saya memang ingin mengatakan bahwa Anda benar. Dapat digunakan kembali adalah mimpi-pipa, sebagian besar. Berikut ini kutipan dari Anders Hejilsberg tentang topik itu (brilian) dari sini :

Jika Anda meminta para pemrogram pemula untuk menulis kontrol kalender, mereka sering berpikir pada diri mereka sendiri, "Oh, saya akan menulis kontrol kalender terbaik di dunia! Ini akan menjadi polimorfik sehubungan dengan jenis kalender. Ini akan memiliki pemajang, dan hijau, dan ini, itu, dan yang lainnya. " Mereka perlu mengirimkan aplikasi kalender dalam dua bulan. Mereka menempatkan semua infrastruktur ini pada kontrol, dan kemudian menghabiskan dua hari menulis aplikasi kalender jelek di atasnya. Mereka akan berpikir, "Dalam versi aplikasi berikutnya, saya akan melakukan lebih banyak lagi."

Begitu mereka mulai berpikir tentang bagaimana mereka sebenarnya akan mengimplementasikan semua konkretisasi lain dari desain abstrak mereka, bagaimanapun, ternyata desain mereka benar-benar salah. Dan sekarang mereka telah melukis diri mereka ke sudut, dan mereka harus membuang semuanya. Saya telah melihatnya berulang kali. Saya sangat percaya menjadi minimalis. Kecuali jika Anda benar-benar akan menyelesaikan masalah umum, jangan mencoba dan menempatkan kerangka kerja untuk memecahkan masalah tertentu, karena Anda tidak tahu seperti apa bentuk kerangka itu.

Pernahkah Anda membuat jendela menggunakan WinAPI?

Lebih sering dari yang saya ingin ingat.

Maka Anda harus tahu bahwa Anda mendefinisikan kelas (RegisterClass), membuat instance dari itu (CreateWindow), memanggil metode virtual (WndProc) dan metode kelas dasar (DefWindowProc) dan sebagainya. WinAPI bahkan mengambil nomenklatur dari SmallTalk OOP, menyebut metode "pesan" (Pesan Jendela).

Maka Anda juga akan tahu bahwa itu tidak mengirim pesan sendiri, yang merupakan kekosongan besar menganga. Ini juga memiliki subclass yang jelek.

Pegangan mungkin tidak dapat diwariskan tetapi kemudian, ada final di Jawa. Mereka tidak kekurangan kelas, mereka adalah pengganti untuk kelas: Itulah arti kata "pegangan". Melihat arsitektur seperti MFC atau .NET WinForms segera jelas bahwa kecuali sintaksisnya, tidak banyak yang berbeda dari WinAPI.

Mereka tidak dapat diwariskan baik dalam antarmuka atau implementasi, minimal dapat disubstitusikan, dan mereka tidak jauh berbeda dari apa yang telah dilakukan oleh coders prosedural sejak dulu.

Benarkah ini? Bit terbaik OOP hanyalah ... kode prosedural tradisional? Itu masalah besar?

Saya setuju sepenuhnya dengan jawaban InSciTek Jeff , saya hanya akan menambahkan penyempurnaan berikut:

• Penyembunyian dan enkapsulasi informasi: Penting untuk kode yang dapat dipelihara. Dapat dilakukan dengan berhati-hati dalam bahasa pemrograman apa pun, tidak memerlukan fitur OO, tetapi melakukannya akan membuat kode Anda sedikit seperti OO.
• Warisan: Ada satu domain aplikasi penting yang semua OO -nya adalah sejenis dan mengandung- hubungan yang sangat cocok: Graphical User Interface. Jika Anda mencoba membangun GUI tanpa dukungan bahasa OO, Anda akhirnya akan membangun fitur seperti OO, dan itu lebih sulit dan lebih rentan kesalahan tanpa dukungan bahasa. Glade (baru-baru ini) dan X11 Xt (secara historis) misalnya.

Menggunakan fitur OO (terutama hierarki abstrak yang bersarang mendalam), ketika tidak ada gunanya, tidak ada gunanya. Tetapi untuk beberapa domain aplikasi, benar-benar ada benarnya.

Saya percaya kualitas OOP yang paling bermanfaat adalah menyembunyikan / mengelola data. Namun, ada BANYAK contoh di mana OOP disalahgunakan dan saya pikir ini adalah di mana kebingungan muncul.

Hanya karena Anda dapat membuat sesuatu menjadi objek bukan berarti Anda harus melakukannya. Namun, jika melakukannya akan membuat kode Anda lebih terorganisir / lebih mudah dibaca maka Anda harus melakukannya.

Contoh praktis yang bagus di mana OOP sangat membantu adalah dengan kelas "produk" dan objek yang saya gunakan di situs web kami. Karena setiap halaman adalah produk, dan setiap produk memiliki referensi ke produk lain, itu bisa sangat membingungkan untuk produk mana data yang Anda rujuk. Apakah "strURL" ini variabel tautan ke halaman saat ini, atau ke halaman rumah, atau ke halaman statistik? Tentu Anda bisa membuat semua jenis variabel berbeda yang merujuk pada informasi yang sama, tetapi proCurrentPage-> strURL, jauh lebih mudah dipahami (untuk pengembang).

Selain itu, melampirkan fungsi ke halaman tersebut jauh lebih bersih. Saya dapat melakukan proCurrentPage-> CleanCache (); Diikuti oleh proDisplayItem-> RenderPromo (); Jika saya baru saja memanggil fungsi-fungsi itu dan menganggapnya data saat ini tersedia, siapa yang tahu kejahatan macam apa yang akan terjadi. Juga, jika saya harus meneruskan variabel yang benar ke dalam fungsi-fungsi itu, saya kembali ke masalah memiliki semua jenis variabel untuk produk yang berbeda-beda.

Alih-alih, menggunakan objek, semua data dan fungsi produk saya bagus dan bersih dan mudah dimengerti.

Namun. Masalah besar dengan OOP adalah ketika seseorang percaya bahwa SEMUA hal harus menjadi OOP. Ini menciptakan banyak masalah. Saya memiliki 88 tabel di database saya. Saya hanya memiliki sekitar 6 kelas, dan mungkin saya harus memiliki sekitar 10 kelas. Saya jelas tidak membutuhkan 88 kelas. Sebagian besar waktu secara langsung mengakses tabel-tabel itu dapat dipahami dengan sempurna dalam keadaan saya menggunakannya, dan OOP sebenarnya akan membuatnya lebih sulit / membosankan untuk mendapatkan fungsionalitas inti dari apa yang terjadi.

Saya percaya model hybrid objek mana yang berguna dan prosedural di mana praktis adalah metode pengkodean yang paling efektif. Sayang sekali kita memiliki semua perang agama ini di mana orang menganjurkan menggunakan satu metode dengan mengorbankan yang lain. Mereka berdua baik, dan mereka berdua memiliki tempat masing-masing. Sebagian besar waktu, ada kegunaan untuk kedua metode di setiap proyek yang lebih besar (Dalam beberapa proyek yang lebih kecil, satu objek, atau beberapa prosedur mungkin semua yang Anda butuhkan).

Saya tidak peduli untuk digunakan kembali sebanyak yang saya lakukan untuk keterbacaan. Yang terakhir berarti kode Anda lebih mudah diubah. Itu saja bernilai emas dalam kerajinan membangun perangkat lunak.

Dan OO adalah cara yang sangat efektif untuk membuat program Anda dapat dibaca. Menggunakan kembali atau tidak menggunakan kembali.

"Dunia nyata bukan" OO ","

Betulkah? Dunia saya penuh dengan benda. Saya menggunakan satu sekarang. Saya pikir memiliki perangkat lunak "objek" model objek nyata mungkin bukan hal yang buruk.

OO mendesain untuk hal-hal konseptual (seperti Windows, bukan windows dunia nyata, tetapi panel layar pada monitor komputer saya) sering meninggalkan banyak hal yang diinginkan. Tetapi untuk hal-hal dunia nyata seperti faktur, pesanan pengiriman, klaim asuransi dan apa-tidak, saya pikir hal-hal dunia nyata adalah objek. Saya punya setumpuk di meja saya, jadi pasti nyata.

Inti dari OOP adalah untuk memberi programmer cara lain untuk menggambarkan dan mengkomunikasikan solusi untuk masalah dalam kode ke mesin dan orang. Bagian terpenting dari itu adalah komunikasi kepada orang-orang. OOP memungkinkan programmer untuk menyatakan apa artinya dalam kode melalui aturan yang diberlakukan dalam bahasa OO.

Bertentangan dengan banyak argumen tentang topik ini, konsep OOP dan OO meresap di seluruh kode termasuk kode dalam bahasa non-OOP seperti C. Banyak programmer canggih non-OO akan mendekati fitur objek bahkan dalam bahasa non-OO.

Memiliki OO dibangun ke dalam bahasa hanya memberi programmer cara ekspresi lain.

Bagian terbesar untuk menulis kode bukanlah komunikasi dengan mesin, bagian itu mudah, bagian terbesar adalah komunikasi dengan pemrogram manusia.