Bir grup arkadaş ve ben kısa süredir bir proje üzerinde çalışıyoruz ve ürünümüze özgü bir senaryoyu temsil etmek için güzel bir OOP yöntemi icat etmek istedik. Temel olarak, Touhou tarzı bir mermi cehennemi oyunu üzerinde çalışıyoruz ve hayal edebileceğimiz herhangi bir mermi davranışını kolayca temsil edebileceğimiz bir sistem kurmak istedik.
Yani yaptığımız tam olarak buydu; Bir merminin davranışını istediğimiz gibi mermi örneklerine iliştirilebilecek farklı bileşenlere bölmemize izin veren gerçekten zarif bir mimari yaptık, bir nevi Birlik bileşen sistemi gibi. Güzelce çalıştı, kolayca genişletilebilir, esnek ve tüm üslerimizi kapsıyordu, ancak küçük bir sorun vardı.
Bizim uygulama aynı zamanda yüksek miktarda işlemsel üretim içerir, yani biz mermilerin davranışlarını usule göre üretiyoruz. Bu neden bir problem? Öyleyse, mermi davranışını temsil eden OOP çözümümüz zarif olsa da, insansız çalışmak için biraz karmaşık. İnsanlar hem mantıklı hem de zeki sorunların çözümlerini düşünecek kadar akıllıdır. Prosedürel üretim algoritmaları henüz o kadar akıllı değil ve OOP mimarisini kullanan bir AI'yi en yüksek potansiyele uygulamak için zor bulduk. Kuşkusuz, bu mimarinin bir kusuru, her durumda sezgisel olmamasıdır.
Bu sorunu çözmek için, temelde, farklı bileşenlerin sunduğu tüm davranışları mermi sınıfına ittik, böylece, hayal edebileceğimiz her şey, diğer ilişkili bileşen örneklerinin aksine, doğrudan her bir kurşun örneğinde sunuldu. Bu, prosedürel üretim algoritmalarımızın çalışmasını biraz kolaylaştırıyor, ancak şimdi kurşun sınıfımız çok büyük bir tanrı nesnesi . Kolayca programdaki en büyük sınıftır ve başka bir şeyden beş kat daha fazla kod içerir. Koruması da biraz acı verici.
Sınıflarımızdan birinin başka bir problemle çalışmayı kolaylaştırmak için bir tanrı nesnesine dönüşmesi sorun olmaz mı? Genel olarak, farklı bir soruna daha kolay bir çözüm getirirse, kodunuzda kod kokularınızın olması doğru olur mu?