Manfaat OOP klasik daripada bahasa mirip Go

13

Saya telah banyak berpikir tentang desain bahasa dan elemen apa yang diperlukan untuk bahasa pemrograman "ideal", dan mempelajari Google's Go telah membuat saya mempertanyakan banyak pengetahuan umum.

Secara khusus, Go tampaknya memiliki semua manfaat menarik dari pemrograman berorientasi objek tanpa benar-benar memiliki struktur bahasa berorientasi objek. Tidak ada kelas, hanya struktur; tidak ada kelas / pewarisan struktur - hanya penyisipan struktur. Tidak ada hierarki, tidak ada kelas induk, tidak ada implementasi antarmuka eksplisit. Sebagai gantinya, aturan pengecoran tipe didasarkan pada sistem longgar yang mirip dengan pengetikan bebek, sehingga jika sebuah struktur mengimplementasikan elemen-elemen yang diperlukan dari "Pembaca" atau "Permintaan" atau "Pengkodean", maka Anda dapat melemparkannya dan menggunakannya sebagai satu.

Apakah ada sesuatu tentang OOP seperti yang diterapkan dalam C ++ dan Java dan C # yang secara inheren lebih mampu, lebih dapat dipelihara, entah bagaimana lebih kuat sehingga Anda harus menyerah ketika pindah ke bahasa seperti Go? Apa manfaat yang Anda harus berikan untuk mendapatkan kesederhanaan yang diwakili oleh paradigma baru ini?

EDIT
Menghapus pertanyaan "usang" yang tampaknya terlalu sering digantung dan dibenci oleh pembaca.

Pertanyaannya adalah, apa yang paradigma berorientasi objek tradisional (dengan hierarki dan semacamnya) seperti yang sering terlihat dalam implementasi bahasa umum yang ditawarkan yang tidak dapat dilakukan dengan mudah dalam model yang lebih sederhana ini? Atau, dengan kata lain, jika Anda mendesain bahasa hari ini, adakah alasan Anda ingin memasukkan konsep hierarki kelas?

— tylerl
sumber

1

Apakah OOP membuat pemrograman prosedural menjadi usang? Aku benci kedengarannya aneh atau aku sedang meremehkanmu, tapi itu kalimat pertama yang muncul di benakku. Go menyediakan paradigma (ish) baru. Dengan eksperimen, pengguna akan mengetahui apa yang baik dan apa yang tidak bagus (seperti dengan semua paradigma dan bahasa), dan kami akan berakhir dengan ratusan produk hebat (bersama dengan itu adalah bagian dari produk buruk) yang ditulis dalam Go . Setidaknya, itulah pendapat saya

— Jamie Taylor

1

Ada beberapa bacaan menarik ketika Anda Google untuk OOP sudah mati . Saya merekomendasikan Web Akan Mati Ketika OOP Meninggal

— Andomar

Ada sedikit nilai dalam OOP sehingga tidak ada gunanya membuang waktu Anda sama sekali.

— SK-logic

1

Saya setuju dengan komentar sebelumnya jangan terlalu fokus pada OOP. Selain itu OOP tidak berarti C ++ atau Java. Coba baca abit di ltu.org

— AndreasScheinert

C ++, Java, dan C # bukan bahasa "klasik" OOP. Jika ada bahasa OOP klasik, saya pikir itu adalah Smalltalk.

— kevin cline

16

Tidak ada paradigma baru. Orientasi objek adalah pola yang Anda gunakan untuk menulis program, yang bahkan tidak didefinisikan dengan jelas. Berbagai bahasa menyediakan berbagai ciri khas orientasi objek (definisi jenis baru, enkapsulasi, hierarki jenis, polimorfisme, kelulusan pesan, dan lainnya) tetapi mungkin gagal menyediakan yang lain. Dalam kasus-kasus itu terserah programmer untuk meniru mereka jika perlu.

Banyak bahasa yang menyediakan fitur-fitur ini tidak memiliki analog dengan konsep kelas - misalnya Javascript dan Common Lisp. Implementasi yang disediakan oleh bahasa seperti Java (berbasis kelas, dengan pewarisan tunggal, antarmuka, pengiriman berbasis tipe) hanyalah salah satu dari kemungkinan, dan belum tentu yang terbaik.

— Andrea
sumber

11

+1 untuk "belum tentu yang terbaik". Mengutip Alan Kay: "Saya menemukan istilah Berorientasi Objek, dan saya dapat memberitahu Anda bahwa saya tidak memiliki C ++ dalam pikiran." (dia juga tidak punya C # dan / atau Java, saya akan dengan rendah hati menebaknya)

— herby

1

@pada saya pernah melihatnya menyarankan bahwa sistem agen (mirip dengan cara kerja Erlang) lebih dekat dengan niat Alan Kay untuk OOP.

— CodexArcanum

2

Eh, Common Lisp pasti punya kelas. Tapi, biasanya, kelas CL berisi data dan metode didefinisikan pada "fungsi generik". Sebagai efek samping, itu memberi Anda cara mudah untuk melakukan pengiriman ganda, karena metode tidak lagi digabungkan dengan "kelas implementasi tunggal".

— Vatine

Ya, yang saya maksudkan adalah bahwa ia tidak memiliki kelas dalam arti Java

— Andrea

5

Apa manfaat yang Anda harus berikan untuk mendapatkan kesederhanaan yang diwakili oleh paradigma baru ini?

Pengecekan tipe untuk sistem tipe struktural jauh lebih kompleks daripada sekadar memeriksa apakah baseclass ada dalam daftar warisan Anda. Pengiriman virtual menjadi sedikit lebih rumit, dan cenderung kurang berkinerja.

Apakah sistem seperti itu membuat konsep OOP usang?

Tidak. Selama Anda dapat membuat program dalam hal 'objek yang melakukan hal-hal' daripada daftar instruksi, atau seperangkat aturan yang dinyatakan, atau serangkaian fungsi ... implementasi tidak masalah. Demikian juga, mengubah sistem tipe tidak membatalkan prinsip OO yang umum.

Anda masih dapat bekerja pada tipe dasar dan tidak peduli dengan tipe yang sebenarnya. Anda masih dapat memperluas jenis tanpa mengubahnya. Anda masih bisa membuat tipe melakukan hanya satu hal. Anda masih dapat menyediakan antarmuka berbutir halus. Anda masih dapat menyediakan abstraksi untuk tipe Anda.

Bagaimana bahasa memungkinkan itu tidak terlalu penting.

— Telastyn
sumber

Bahkan, Go membuat semua hal-hal OOP lebih mudah dan menambahkan beberapa kemungkinan tambahan seperti memperluas tipe untuk menyediakan antarmuka baru yang berlaku untuk instance yang ada (selama Anda tidak membutuhkan anggota data baru, tentu saja).

— Jan Hudec

4

Saya pikir ide Anda tentang OOP cukup sedikit:

Saya menemukan istilah 'Pemrograman Berorientasi Objek' dan {Java dan C ++} ini bukan yang ada dalam pikiran saya.
- Alan Kay .

Pilihan pengetikan (subtyping nominatif, subtyping struktural atau pengetikan bebek - atau kombinasi dari semuanya) sebagian besar ortogonal terhadap OOP. Warisan dan kelas sepenuhnya ortogonal untuk OOP. Jika Anda meluangkan waktu untuk bermain io, Anda akan melihatnya.

Sekarang Anda bisa bertanya jenis sistem jenis apa yang "lebih baik", dan mana yang menggunakan kembali dan kombinasi kode. Dan cobalah untuk menentukan kelebihan dan kekurangan antara pilihan yang dibuat di Simula (dan kemudian dijalankan di C ++, Java dan C #) dan yang dibuat di Go. Tetapi ini semua adalah pertanyaan yang berbeda dan berbeda.

Pada akhirnya, OOP adalah konsep yang sangat samar dan semua upaya untuk mengimplementasikannya datang dalam berbagai macam rasa. Tetapi untuk benar-benar menyederhanakan banyak hal, saya akan mengatakan ide inti dari OOP adalah menyusun sistem subsistem SOLID . Sekarang ini benar-benar mengaburkan garis ke paradigma lain, tapi saya berspekulasi bahwa itulah alasan mengapa bahasa multi-paradigma telah meningkat popularitasnya baru-baru ini dan mengapa Google mengambil kesempatan sendiri untuk itu dengan Go.

— back2dos
sumber

2

Pertanyaannya berkaitan dengan konsep, tidak perlu istilah. Jika Anda dapat membuat nama yang lebih baik daripada "OOP" untuk merujuk pada konsep hierarki kelas dan semua pemangkasan yang menyertainya, maka kita dapat menggunakannya.

— tylerl

@tylerl: Anda membingungkan setidaknya dua pertanyaan menjadi satu. Pertama, apakah subtyping struktural lebih baik daripada subtyping nominatif. Yang lain pada dasarnya, apakah komposisi lebih baik daripada warisan. Pertanyaan-pertanyaan ini saling ortogonal. Saya pikir pada akhirnya bahasa "terbaik" tidak membuat pilihan ini untuk Anda. Saya berspekulasi bahwa Go hanya memiliki serangkaian masalah yang berbeda, tetapi kita akan melihat apakah Google menambahkan fitur-fitur itu "kembali" atau tidak.

— back2dos

Saya ingin hanya satu bahasa yang memiliki sebagian besar kemampuan C ++ tetapi lebih kecil dan lebih sederhana. C ++ adalah satu-satunya bahasa kecuali C realistis untuk kernel, dan itu memberi Anda alat yang sangat berguna seperti destruktor dan STL. Dan prinsip penting 'jika Anda tidak menggunakannya, Anda tidak membayar untuk itu'. OO, digunakan dengan benar, sangat kuat. Tetapi obat generik dan konsep non-OO lainnya juga sangat diperlukan. C hampir tidak memberimu apa-apa, dan Go membuang OO sungguhan untuk beberapa ide aneh baru.

— Erik Alapää

1

OOP tidak usang.

Seperti yang dikatakan Andrea, ada banyak konsep yang diusulkan sebagai alternatif untuk kelas (misalnya: typeclass haskell). OOP memiliki satu manfaat besar: diajarkan di banyak tempat, dan budaya OOP sebagian besar dibagi di antara para pengembang.

Ini memungkinkan komunikasi yang lebih kaya di dalam tim. Orang dapat berbicara tentang pabrik lebih mudah daripada tentang prepromorfisme Zygohistomorphic . OOP menyusun cara Anda akan mengatur dan berkomunikasi tentang program Anda dengan diagram yang umum digunakan. Ini adalah aset yang kuat.

— Simon Bergot
sumber

1

Saya pikir: banyak di banyak tempat. Sebenarnya bukan suatu keuntungan.

— AndreasScheinert

@AndreasScheinert mengapa itu tidak menguntungkan?

— Simon Bergot

Karena untuk membuat penilaian Anda harus tahu setidaknya 1 alternatif yang sama baiknya. Ini adalah masalah kebiasaan, orang suka tinggal di zona nyaman mereka dan itu mengarah pada stagnasi.

— AndreasScheinert

@AndreasScheinert menggunakan alat yang tepat untuk pekerjaan itu. Oop tidak berfungsi untuk semua skenario .... tidak ada hubungannya dengan zona

— nyamannya

1

Tidak, tidak ada yang baru di sini, juga OOP sudah usang. C ++ memiliki antarmuka implisit juga dalam bentuk templat, tetapi orang masih menggunakan fungsi virtual. Anda memerlukan antarmuka eksplisit untuk mengatasinya, misalnya, antarmuka biner, atau antarmuka di mana kode lain tidak diketahui saat kompilasi.

Anda bisa berpendapat bahwa ini hanyalah kasus inferensi vs menyatakannya secara eksplisit, yang tidak seperti "paradigma baru" dan benar-benar hanya lebih nyaman.

— DeadMG
sumber