Birden fazla miras, varlık sistemlerinin yaptığı tüm sorunları çözmez mi?


10

Soru oldukça kendi kendine açıklıyor: çoklu miras, varlık sistemlerinin de çözdüğü tüm sorunları çözmez mi?

"Çoklu kalıtım" olarak adlandırılan bir terimi hatırladım ve bu klasik kalıtımın dayattığı birçok şişkinlik problemini çözüyor gibi görünüyor.


1
Çoklu kalıtım varlık sistemlerine benzer, ancak aynı değildir. Örneğin, birden çok devralma varlığının bileşenlerini çalışma zamanında ekleyip çıkaramazsınız. Tüm diller birden fazla kalıtım özelliğini desteklemez. Kompozisyonun varlık / bileşenlerle aynı kategoride olduğunu da düşünebilirsiniz.
MichaelHouse

2
Sınıflarınız zaten o kadar düzenli ise, onları istediğiniz gibi sorunsuz bir şekilde devralınabilirsiniz, zaten bileşenler olabilirler. Bileşenler ayrıca çalışma zamanında kompozisyona / toplamaya izin verir

Peki, daha karmaşık ve daha az hata eğilimli, neden tercih edesin?
API-Beast

2
MI, "şişkinlik" meselelerini de ele almaz, çünkü bir üst sınıftan veya sınıftan fazla bir arabirim miras almak, tek veya çoklu kalıtım yerine kalıtım mekanizmasını kullanmanın daha kötü bir belirtisidir. Aynı "şişkinlik", bir probleme kompozisyon odaklı yaklaşımda da elde edilebilir.

@MrBeast daha karmaşık / daha fazla hataya eğilimli, daha az karmaşık / hataya eğilimli veya "neden tercih etmiyorsunuz?"
3Dave

Yanıtlar:


10

Hayır, çoklu kalıtım varlık sistemleriyle aynı sorunları çözmez: varlık sistemleri ve çoklu kalıtım çok farklı iki şeydir. Birden fazla mirasa sahip olan veya olmayan bir varlık sistemi oluşturabilir ve benzer şekilde bir varlık sistemi oluşturmadan birden fazla miras kullanabilirsiniz.

Geleneksel olarak, bileşen odaklı varlık sistemleri herhangi bir biçimde ağır mirastan uzaklaşmak ve kompozisyonu hedeflemek arzusuyla gelişir . Bu atasın başka bir yerinde, örneğin SE veya SO programcılarının kendisinde yeterli literatür ve tartışma vardır ve kompozisyonun neden tercih edilmesinin daha büyük sorusu, oyun geliştirme için bir tür konu dışıdır. Kısacası, bu iyileştirilmiş değişebilirlik ve sürdürülebilirliğe kendini adamış bir yaklaşımdır.


2

Josh'un cevabı harika, ama eklemek istiyorum:

Varlık / Bileşenin en havalı özelliklerinden biri, oyununuzdaki her "şeyin" oluşturulduğu ve yönetildiği veri odaklı yöntemdir. Gördüğüm kadarıyla, oluşturduğunuz bileşen türleri ve sistemlerin güzel bir kütüphanesine sahip olduğunuzda, minimum kod değişiklikleri ile hemen hemen her şeyi oluşturabilirsiniz. (Not: minimal! = 0 )

Oyununuzu davranış açısından tanımlayarak ve kendinize bu davranışları anında değiştirme yeteneği vererek - çalışma zamanında, başlatma sırasında bunları bir komut dosyasından veya veritabanından yükleyerek vb. - yeni olasılıkların tüm dünyasını açarsınız. Gölgelerinizin neden beklediğiniz yere inmediğini görmek ister misiniz? Işığınıza bir kamera / POV bileşeni ekleyin.

Varlık / bileşen, blokları oluşturduğunuz sürece istediğiniz her şeyi oluşturmanıza olanak tanır.

Ayrıca, çoklu kalıtım, tek kalıtımla aynı soruna neden olur. Hiyerarşiye bir nitelik veya davranış eklediğinizde, yayılır. Derin hiyerarşiler yaptığınız sürece, gereksiz ağırlık taşıdığınız, kodu çoğalttığınız veya çakışmaları çözdüğünüz durumlarla karşılaşırsınız. Oyununuzu veri olarak hayal ettiğinizde bunların çoğu önlenebilir.

Son birkaç hafta içinde bununla oynamaya başladım, ancak işlerin ne kadar basit hale geldiğinden çok etkilendim. Gümüş bir mermi değil - bir bileşene lambda eklemenin bir sorunu çözmenin en temiz ve en uygun yolu olduğu birkaç durumla karşılaştım - ancak bunu söyleyebilirseniz oldukça harika bir model.

Biraz ilgili bir notta: veri merkezli uygulamalarda (web siteleri, vb.) Büyük, sıkıcı bakım jeneratörlerinden biri, hiyerarşik nesneleri ilişkisel veritabanlarıyla eşlemektir. Etrafta çok şık çözümler var, ama sonuçta hepsi hiyerarşileri düzleştirmek için tasarlanmış hackler. Modelinizi uygulamanın amacına hizmet edecek şekilde oluşturmak yerine, etkili bir hiyerarşi ve mantıksal ilişkisel temsil arasında uzlaşmaya varırsınız. Bir varlık / bileşen sistemi olarak uygulamalarımdan birinde oldukça büyük bir hiyerarşi yeniden oluşturma fikriyle oynuyorum - hiyerarşiyi bırakın ve veritabanını uygulamanın geri kalanı için Altın Standart haline getirin - ve bu umut vericidir.

Performans sorunlarını ele alabilecek dinamik kod oluşturma / kod önbellekleme gibi özellikleri entegre ettiğinizde, OOP'un yeniden kullanılabilir kod hedefini çok daha iyi bir şekilde gerçekleştirebilecek hızlı, esnek ve mantıklı bir mimariyle bitirirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.