Bukankah multiple inheritance menyelesaikan semua masalah yang dilakukan sistem entitas?

Pertanyaannya cukup jelas: bukankah multiple inheritance menyelesaikan semua masalah yang juga dipecahkan oleh sistem entitas?

Saya baru ingat sebuah istilah yang disebut "pewarisan berganda", dan itu sepertinya memecahkan banyak masalah besar yang dipaksakan oleh pewarisan klasik.

— jcora
sumber

Multiple inheritance mirip dengan sistem entitas, tetapi tidak sama. Misalnya, beberapa entitas turunan tidak dapat memiliki komponen yang ditambahkan dan dihapus pada saat dijalankan. Tidak semua bahasa mendukung banyak pewarisan juga. Anda juga dapat mempertimbangkan komposisi berada dalam kategori yang sama vs entitas / komponen.

— MichaelHouse

Jika kelas Anda sudah sangat rapi sehingga Anda dapat mewarisi mereka dengan mulus dengan cara apa pun yang Anda suka, mereka mungkin sudah menjadi komponen. Komponen juga memungkinkan komposisi / agregasi saat runtime

Nah, ini lebih kompleks dan lebih sedikit kesalahan rawan, jadi mengapa lebih suka itu?

— API-Beast

MI juga tidak benar-benar mengatasi masalah "mengasapi", karena mewarisi kelebihan antarmuka dari kelas induk atau kelas lebih merupakan gejala buruk menggunakan mekanisme pewarisan daripada warisan tunggal versus banyak. "Penggembungan" yang sama dapat dicapai dengan pendekatan yang berorientasi komposisi terhadap suatu masalah.

@ MrBeast maksud Anda lebih kompleks / lebih rentan kesalahan, kurang kompleks / rentan kesalahan, atau "mengapa tidak suka itu?"

— 3Dave

Jawaban:

Tidak, multiple inheritance tidak menyelesaikan semua masalah yang sama yang dilakukan oleh sistem entitas: sistem entitas dan multiple inheritance adalah dua hal yang sangat berbeda. Anda dapat membangun sistem entitas dengan atau tanpa pewarisan berganda dan Anda juga dapat menggunakan pewarisan berganda tanpa membangun sistem entitas.

Secara tradisional, sistem entitas yang berfokus pada komponen dikembangkan karena keinginan untuk menjauh dari warisan yang berat dalam bentuk apa pun, yang bertujuan untuk komposisi . Ada literatur dan diskusi yang cukup di tempat lain tentang pepatah ini, misalnya pada programmer SE atau SO itu sendiri , dan itu pertanyaan yang lebih besar mengapa memilih komposisi adalah semacam topik untuk pengembangan game. Singkatnya, bagaimanapun, ini adalah pendekatan yang cenderung cocok untuk peningkatan mutabilitas dan pemeliharaan.

— Komunitas
sumber

Jawaban Josh luar biasa, tetapi saya ingin menambahkan:

Salah satu fitur paling keren dari Entity / Component adalah cara yang didorong oleh data di mana setiap "hal" dalam gim Anda dibuat dan dikelola. Dari apa yang saya lihat, setelah Anda memiliki perpustakaan yang bagus untuk jenis komponen dan sistem yang dibuat, Anda dapat membangun apa saja dengan modifikasi kode minimal. (Catatan: minimal! = 0 )

Dengan mendefinisikan game Anda dari segi perilaku, dan memberi diri Anda kemampuan untuk memodifikasi perilaku tersebut dengan cepat - saat runtime, selama inisialisasi dengan memuatnya dari skrip atau database, dll. - Anda membuka seluruh dunia kemungkinan baru. Ingin melihat mengapa bayangan Anda tidak mendarat di tempat yang Anda harapkan? Tambahkan komponen kamera / POV ke cahaya Anda.

Entitas / komponen memungkinkan Anda membangun apa pun yang Anda inginkan, selama Anda telah membuat blok.

Juga, pewarisan berganda menyebabkan masalah yang sama dengan pewarisan tunggal. Saat Anda menambahkan atribut atau perilaku dalam hierarki, itu menyebar. Selama Anda membuat hierarki yang mendalam, Anda akan menghadapi situasi di mana Anda membawa beban yang tidak perlu, kode duplikat, atau menyelesaikan konflik. Sebagian besar itu bisa dihindari ketika Anda membayangkan game Anda sebagai data.

Saya baru saja mulai bermain dengan ini dalam beberapa minggu terakhir, tetapi saya terkesan dengan betapa hal-hal sederhana telah terjadi. Ini bukan peluru perak - saya telah menemukan beberapa kasus di mana menempelkan lambda ke komponen adalah cara paling bersih dan paling bijaksana untuk menyelesaikan masalah - tetapi ini adalah pola yang cukup hebat, jika Anda bisa menyebutnya begitu.

Pada catatan yang sedikit terkait: salah satu generator pemeliharaan yang besar dan membosankan dalam aplikasi data-sentris (situs web, dll.) Adalah memetakan objek hierarkis ke dalam basis data relasional. Kami memiliki banyak solusi bagus, tetapi pada akhirnya semua peretasan dirancang untuk meratakan hierarki. Alih-alih membangun model Anda sehingga melayani tujuan aplikasi, Anda akhirnya berkompromi antara hierarki yang efektif dan representasi relasional yang logis. Saya telah mempermainkan ide membangun kembali hierarki yang cukup besar di salah satu aplikasi saya sebagai sistem entitas / komponen - membuang hierarki dan menjadikan basis data sebagai Standar Emas untuk sisa implementasi - dan ini menjanjikan.

Ketika Anda mengintegrasikan kemampuan seperti pembuatan kode / caching kode dinamis yang dapat mengatasi masalah kinerja, Anda akhirnya dengan arsitektur yang cepat, fleksibel, dan logis yang mungkin saja mewujudkan tujuan kode OOP yang dapat digunakan kembali dengan cara yang jauh lebih baik.

— 3Dave
sumber