Komuniti Pengaturcaraan Berdebat Mengenai Kesilapan 35 Tahun Object-Oriented Programming Berikutan Analisis Sejarah Casey Muratori

Pasukan Komuniti BigGo
Komuniti Pengaturcaraan Berdebat Mengenai Kesilapan 35 Tahun Object-Oriented Programming Berikutan Analisis Sejarah Casey Muratori

Pembentangan Casey Muratori bertajuk The Big OOPs: Anatomy of a Thirty-Five Year Mistake telah mencetuskan perdebatan sengit dalam komuniti pengaturcaraan mengenai andaian asas yang mendasari object-oriented programming (OOP). Ceramah yang berlangsung hampir dua jam ini menjejaki perkembangan sejarah OOP dari tahun 1963 hingga 1998, dengan hujah bahawa pendekatan khusus untuk mengatur kod telah mewujudkan dekad kerumitan yang tidak perlu dalam pembangunan perisian.

Hujah Teras: Hierarki Model Domain Adalah Satu Kesilapan

Tesis utama Muratori memberi tumpuan kepada apa yang beliau panggil compile-time hierarchy of encapsulation that matches the domain model. Ini merujuk kepada amalan biasa mengatur kelas kod untuk mencerminkan hubungan dunia sebenar - seperti mempunyai kelas Car yang mewarisi daripada kelas Vehicle, yang mewarisi daripada kelas Transportation. Perbincangan komuniti mendedahkan bahawa ramai pembangun diajar pendekatan ini sebagai cara yang betul untuk melakukan OOP, dengan pewarisan mewakili hubungan semantik is-a daripada domain masalah.

Ceramah ini menjejaki pendekatan ini kembali kepada Simula , di mana ia masuk akal kerana bahasa tersebut direka untuk simulasi. Walau bagaimanapun, apabila konsep-konsep ini berpindah ke C++ dan kemudiannya Java , ia menjadi amalan universal yang digunakan untuk semua masalah perisian, tanpa mengira sama ada pemodelan domain sesuai atau tidak.

Garis Masa Sejarah Pembangunan OOP:

  • 1963: Konsep awal ECS muncul dalam Sketchpad
  • 1967: Simula 67 memperkenalkan kelas dan fungsi maya
  • 1980an-1990an: C++ mempopularkan hierarki model domain
  • 1998: Thief: The Dark Project menunjukkan seni bina ECS moden
  • Masa Kini: Enjin permainan seperti Unity dan Unreal menggunakan corak ECS

Entity Component Systems: Alternatif Yang Hilang

Sebahagian besar perbincangan komuniti tertumpu pada Entity Component Systems (ECS), yang Muratori bentangkan sebagai alternatif yang wujud seawal tahun 1963 tetapi sebahagian besarnya dilupakan. ECS mengatur kod berdasarkan keupayaan pengiraan dan bukannya hierarki domain. Daripada mempunyai pewarisan kelas yang tegar, entiti terdiri daripada komponen yang boleh ditambah atau dikeluarkan secara dinamik, dengan sistem beroperasi pada entiti yang mempunyai gabungan komponen tertentu.

Pembangun permainan dalam perbincangan menyatakan bahawa ECS telah menjadi semakin popular dalam bidang mereka, dengan enjin utama seperti Unity dan Unreal Engine menggunakan corak-corak ini. Pendekatan ini membolehkan kod yang lebih fleksibel dan boleh diselenggara, terutamanya dalam sistem kompleks di mana objek perlu mempamerkan pelbagai tingkah laku yang tidak sesuai dengan kategori hierarki.

Perbandingan Paradigma Pengaturcaraan Utama:

Pendekatan Organisasi Fleksibiliti Kes Penggunaan
OOP Tradisional Hierarki domain (Kereta → Kenderaan) Rendah - pewarisan tegar Aplikasi perniagaan, perisian awal
Sistem Komponen Entiti Keupayaan pengiraan Tinggi - komposisi dinamik Permainan, simulasi, sistem kompleks
Pengaturcaraan Berfungsi Fungsi matematik Tinggi - fungsi boleh digabung Pemprosesan data, sistem serentak
Pengaturcaraan Prosedural Operasi berurutan Sederhana - fungsi modular Pengaturcaraan sistem, utiliti

Komuniti Berpecah Mengenai Nilai OOP

Komuniti pengaturcaraan nampaknya berpecah mengenai sama ada OOP itu sendiri bermasalah atau hanya pelaksanaan khusus daripadanya. Sesetengah pembangun berkongsi pengalaman dikritik kerana mempersoalkan ortodoksi OOP sepanjang kerjaya mereka, menggambarkan situasi di mana mereka dianggap kurang mahir kerana lebih suka pendekatan fungsional atau prosedur.

Saya banyak mengadu tentang OOP sepanjang 25 tahun saya sebagai pembangun... apabila saya mula mengadu kepada rakan sekerja tentang perasaan saya, saya dikucilkan dan dituduh 'tidak mempunyai set kemahiran yang cukup kuat.'

Walau bagaimanapun, yang lain berpendapat bahawa masalahnya bukan OOP sebagai paradigma tetapi bagaimana ia diajar dan digunakan. Mereka menunjukkan bahawa bahasa seperti Python dan juga C++ membenarkan pelbagai gaya pengaturcaraan, dan bahawa polimorfisme dan enkapsulasi kekal sebagai alat yang berharga apabila digunakan dengan sewajarnya.

Perdebatan Teknikal Mengenai Pelaksanaan Bahasa

Subplot menarik dalam perbincangan komuniti melibatkan perdebatan tentang apa yang membentuk object-oriented programming di peringkat bahasa. Sesetengah berpendapat bahawa bahasa seperti Python sememangnya berorientasikan objek kerana segala-galanya dilaksanakan sebagai objek secara dalaman, manakala yang lain berpendapat bahawa butiran pelaksanaan kurang penting daripada corak pengaturcaraan yang digunakan pembangun.

Perbincangan teknikal ini menyerlahkan kekeliruan mengenai terminologi OOP, dengan pembangun berbeza menggunakan istilah tersebut untuk bermaksud perkara yang berbeza - daripada ciri bahasa seperti pewarisan kepada corak seni bina kepada butiran pelaksanaan asas.

Kesimpulan

Analisis sejarah Muratori jelas telah menyentuh saraf dalam komuniti pengaturcaraan, mengesahkan pengalaman yang dialami ramai pembangun dengan hierarki OOP yang terlalu kompleks sambil juga mendorong refleksi mengenai alternatif yang lebih baik. Perbincangan menunjukkan bahawa walaupun alat OOP seperti polimorfisme dan enkapsulasi kekal berharga, industri mungkin bergerak menjauhi pendekatan pemodelan domain yang tegar ke arah corak seni bina yang lebih fleksibel seperti ECS dan teknik pengaturcaraan fungsional.

Perdebatan ini mencerminkan persoalan yang lebih luas tentang bagaimana paradigma pengaturcaraan berkembang dan mengapa pendekatan tertentu menjadi berakar umbi walaupun terdapat batasan mereka. Apabila komuniti terus bergelut dengan idea-idea ini, jelas bahawa penyelidikan Muratori telah memberikan konteks sejarah yang berharga untuk memahami bagaimana kita sampai kepada amalan pengaturcaraan semasa dan ke mana kita mungkin pergi seterusnya.

Rujukan: The Big OOPs: Anatomy of a Thirty-Five Year Mistake