Oyun mimarimde birçok singleton bulundurmaktan nasıl kaçınabilirim?

Oyun oluşturmak için cocos2d-x oyun motorunu kullanıyorum. Motor zaten birçok tekil kullanır. Birisi kullandıysa, o zaman bazılarına aşina olmalı:

Director
SimpleAudioEngine
SpriteFrameCache
TextureCache
EventDispatcher (was)
ArmatureDataManager
FileUtils
UserDefault

ve daha pek çoğu, yaklaşık 16 derslik. Bu sayfada benzer bir liste bulabilirsiniz: Cocos2d-html5 v3.0 içindeki Singleton nesneleri Ancak yazmak istediğimde oyun oynamak için çok daha fazla singleton'a ihtiyacım var:

PlayerData (score, lives, ...)
PlayerProgress (passed levels, stars)
LevelData (parameters per levels and level packs)
SocialConnection (Facebook and Twitter login, share, friend list, ...)
GameData (you may obtain some data from server to configure the game)
IAP (for in purchases)
Ads (for showing ads)
Analytics (for collecting some analytics)
EntityComponentSystemManager (mananges entity creation and manipulation)
Box2dManager (manages the physics world)
.....

Neden onların singleton olması gerektiğini düşünüyorum? Çünkü onlara oyunumda çok farklı yerlerde ihtiyacım olacak ve paylaşılan erişim çok kullanışlı olurdu. Başka bir deyişle, onları bir yerde yaratacak ve işaretçilerimi tüm mimarime iletecek çok zor olacağı için anlamıyorum. Ayrıca bunlar sadece bir tane ihtiyacım olan şeyler. Her durumda birkaç kişiye ihtiyacım olacak, ben de bir Multiton deseni kullanabilirim. Ancak en kötüsü, Singleton’ın şu sebeplerden dolayı en ağır biçimde eleştirilen model olmasıdır:

 - bad testability
 - no inheritance available
 - no lifetime control
 - no explicit dependency chain
 - global access (the same as global variables, actually)
 - ....

Burada bazı düşünceleri bulabilirsiniz: https://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons ve https://stackoverflow.com/questions/4074154/when-should-the-singleton -pattern--kullanılmamalıdır-yanında-bariz

Sanırım yanlış bir şey yapıyorum. Sanırım kodum kokuyor . :) Daha deneyimli oyun geliştiricilerinin bu mimari problemi nasıl çözdüğünü tahmin ediyorum? Kontrol etmek istiyorum, belki de oyun geliştirmede , halihazırda oyun motorunda olanları düşünen 30'dan fazla singleton olması normaldir .

İhtiyacım olan tüm bu sınıfların örneklerine sahip olacak bir Singleton-Cephe kullanmayı düşündüm, ancak her biri zaten bir tekillik olmayacaktı. Bu, birçok sorunu ortadan kaldıracak ve Cephe'nin kendisi olacak tek bir singleton olacaktı. Ancak bu durumda başka bir tasarım problemim olacak. Cephe bir ALLAH NESNE olacak. Sanırım bu da kokuyor . Bu yüzden bu durum için iyi bir tasarım çözümü bulamıyorum. Lütfen tavsiye.

Servislerimi ana uygulama sınıfımda başlatıyorum ve daha sonra bunları inşaatçılar veya fonksiyonlar aracılığıyla kullanmak için ihtiyaç duydukları şeylere işaretçiler olarak aktarıyorum. Bu iki nedenden dolayı faydalıdır.

Birincisi, başlatma ve temizleme sırası basit ve açıktır. Kazanan bir hizmeti tek birtonla yapabildiğiniz gibi başka bir yerden başlatmanız mümkün değildir.

İkincisi, kimin neye bağlı olduğu belli. Sadece sınıf bildiriminde hangi sınıfların hangi hizmetlere ihtiyaç duyduğunu kolayca görebilirim.

Tüm bu nesnelerin etrafından dolaştırılmasının can sıkıcı olduğunu düşünebilirsiniz, ancak sistem iyi tasarlanmışsa, hiç de fena değil ve her şeyi daha net hale getirir (benim için).

İnternetin benden daha iyisini yapabilmesi için, singletonların arkasındaki kötülük hakkında konuşmayacağım.

Oyunlarımda tonlarca Tekli / Yönetici sahibi olmamasını önlemek için Servis Belirleme modelini kullanıyorum.

Kavram oldukça basit. Singleton olarak kullandığın şeye ulaşan tek arayüz gibi davranan sadece bir Singleton var. Birden fazla Singleton'a sahip olmak yerine, şimdi sadece bir tane var.

Gibi aramalar:

FlyingToasterManager.GetInstance().Toast();
SmokeAlarmManager.GetInstance().Start();

Servis Belirleme desenini kullanarak şuna benziyor:

SvcLocator.FlyingToaster.Toast();
SvcLocator.SmokeAlarm.Start();

Gördüğünüz gibi her Singleton Servis Bulucuda bulunur.

Daha ayrıntılı bir açıklama için, Konum Belirleme Şablonunun nasıl kullanılacağı hakkında bu sayfayı okumanızı öneririm .

[ EDIT ]: yorumlarda belirtildiği gibi gameprogrammingpatterns.com sitesi , Singleton'da çok ilginç bir bölüm içermektedir .

Umut ediyorum bu yardım eder.

Tüm bu cevapları, yorumları ve makaleleri okumak, özellikle de bu iki harika makaleyi,

• http://gameprogrammingpatterns.com/singleton.html
• http://gameprogrammingpatterns.com/service-locator.html

Sonunda, kendi soruma bir nevi cevap olan şu sonuca vardım. En iyi yaklaşım tembel olmamak ve doğrudan bağımlılıkları geçmek değildir. Bu açık, test edilebilir, küresel erişim yok, delegeleri çok derin ve birçok yerde ve başka yerlerde geçirmeniz gerekiyorsa yanlış tasarım gösterebilir. Ancak programlamada bir boyut hepsine uymuyor. Bu nedenle, onları doğrudan iletmenin kullanışlı olmadığı hala devam etmektedir. Örneğin, bir oyun çerçevesi oluşturduğumuzda (farklı tür oyunlar geliştirmek için temel kod olarak yeniden kullanılacak bir kod şablonu) ve orada birçok hizmet içerir. Burada her bir hizmetin ne kadar derinden geçilebileceğini ve kaç yere ihtiyaç duyulacağını bilmiyoruz. Belirli bir oyuna bağlıdır. Peki bu tür durumlarda ne yaparız? Singleton yerine Service Locator tasarım modelini kullanıyoruz,

1. Uygulamaları değil, arayüzleri de programlıyorsunuz. Bu, OOP müdürleri açısından çok önemlidir. Çalışma zamanında Null Object pattern kullanarak servisi değiştirebilir veya hatta devre dışı bırakabilirsiniz. Bu sadece esneklik açısından önemli değil, aynı zamanda testlerde doğrudan yardımcı olur. Ayrıca, alay, devre dışı bırakabilirsiniz, ayrıca bazı günlük ve diğer işlevler eklemek için Dekoratör desenini kullanabilirsiniz. Bu Singleton sahip olmayan çok önemli bir özelliktir.
2. Bir diğer büyük avantaj, nesnenin ömrünü kontrol edebilmenizdir. Singleton'da nesnenin yalnızca Tembel Başlatma modeli ile ortaya çıkacağı zamanı kontrol edersiniz. Ancak nesne bir kez doğduğunda, programın sonuna kadar yaşayacak. Ancak bazı durumlarda servisi değiştirmek isteyebilirsiniz. Ya da kapat. Özellikle oyunlarda bu esneklik çok önemlidir.
3. Birkaç Singleton'ı tek bir kompakt API'de birleştirir / sarar. Ayrıca, tek bir işlem için bir seferde birden fazla servisi kullanabilecek Cephe gibi Servis Belirleyicileri de kullanabilirsiniz.
4. Singleton'un ana tasarım sorunu olan küresel erişime hala sahip olduğumuzu iddia edebilirsiniz. Aynı fikirdeyim, ancak bu forma yalnızca ihtiyacımız olacak, ancak küresel erişim istiyorsak. Doğrudan bağımlılık enjeksiyonunun durumumuz için kullanışlı olmadığını ve küresel bir erişime ihtiyacımız olduğunu düşünüyorsanız, küresel erişimden şikayet etmemeliyiz. Ancak bu problem için bile bir gelişme var (yukarıdaki ikinci maddeye bakınız). Tüm hizmetleri özel yapabilir ve hizmetleri kullanmaları gerektiğini düşündüğünüz tüm sınıfları Service Locator sınıfından miras alabilirsiniz. Bu, erişimi önemli ölçüde daraltabilir. Lütfen Singleton durumunda, mirası özel kurucu nedeniyle kullanamayacağınızı düşünün.

Ayrıca, bu kalıbın Unity, LibGDX, XNA'da kullanıldığını da düşünmeliyiz. Bu bir avantaj değil, ancak bu, modelin kullanılabilirliğinin bir kanıtı. Bu motorların uzun süredir akıllı geliştiriciler tarafından geliştirildiğini ve motorun evrimi sırasında hala daha iyi bir çözüm bulamadıklarını düşünün.

Sonuç olarak, Hizmet Bulucu'nun sorumumda açıklanan senaryolar için çok faydalı olabileceğini düşünüyorum, ancak mümkünse yine de kaçınılması gerekir. Temel kural olarak - mecbur kalırsanız kullanın.

EDIT: Bir yıl çalıştıktan ve doğrudan DI kullandıktan sonra, büyük inşaatçılar ve birçok delegasyonla ilgili problemler yaşadıktan sonra, daha fazla araştırma yaptım ve DI ve Hizmet Bulucu yöntemleriyle ilgili lehte ve aleyhte olanlar hakkında konuşan iyi bir makale buldum. Servis sağlayıcıların gerçekte ne zaman kötü olduklarını açıklayan Martin Fowler tarafından yayınlanan bu makaleye ( http://www.martinfowler.com/articles/injection.html ) bakınız:

Bu nedenle, asıl mesele yazarın kontrolü dışındaki uygulamalarda kullanılması beklenen kod yazan insanlar içindir. Bu durumlarda bir Servis Bulucu ile ilgili asgari bir varsayım bile bir problemdir.

Ama yine de, eğer ilk kez bize DI yapmak istiyorsanız, bu http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/ makalesini okumalısınız (@megadan tarafından belirtilmiştir) , Demeter Yasasına (LoD) veya en az bilgi ilkesine çok dikkat ederek .

Bir kod tabanının bölümlerinin temel taş nesneler veya bir temel sınıf olarak görülmesi nadir değildir, ancak bu, Singleton olarak dikte edilmesi yaşam döngüsünü haklı çıkarmaz.

Programcılar genellikle alternatif bir yaklaşım benimsemek ve açık bir malikânede birbirleri arasında nesne ilişkilerini biraz daha ayrıntılı ve empoze etmek yerine, kolaylık ve saf tembellik aracı olarak Singleton modeline güvenirler.

Öyleyse, bakımı daha kolay olan kendinize sorun.

Benim gibiyseniz, bir başlık dosyasını açmayı ve bir uygulama dosyasındaki yüzlerce kod satırını denetlemek yerine bir nesnenin hangi bağımlılıkları gerektirdiğini görmek için yapıcı argümanlarını ve genel yöntemleri gözden geçirmeyi tercih ediyorum.

Eğer bir nesneyi bir Singleton yaptıysanız ve daha sonra, söz konusu nesnenin birden fazla örneğini destekleyebilmeniz gerektiğinin farkına vardıysanız, bu sınıf kod tabanınızda oldukça yoğun bir şekilde kullandığınız bir şeyse, gerekli olan kapsamlı değişiklikleri hayal edin. Daha iyi bir alternatif, nesne yalnızca bir kez tahsis edilmiş olsa ve birden fazla örneği destekleme ihtiyacı ortaya çıkarsa bile, böyle endişeler olmadan güvenle yapabilirsiniz, bağımlılıkları açık hale getirmektir.

Diğerlerinin de belirttiği gibi, Singleton modelinin kullanılması, modüller arasında genellikle zayıf tasarım ve yüksek uyum gösteren bağlantıyı da engeller. Bu tür bir uyum genellikle istenmez ve bakımı zor olabilecek kırılgan kodlara yol açar.

Singleton ünlü bir kalıptır, ancak hizmet ettiği amaçları, artılarını ve eksilerini bilmek iyidir.

Hiçbir ilişki yoksa gerçekten mantıklı geliyor .
Bileşeninizi tamamen farklı bir nesneyle (güçlü bir bağımlılık olmadan) kaldırabilir ve aynı davranışa sahip olmayı beklerseniz, singleton iyi bir seçim olabilir.

Öte yandan, yalnızca belirli zamanlarda kullanılan küçük bir işlevselliğe ihtiyacınız varsa , referansları geçmeyi tercih etmelisiniz .

Bahsettiğiniz gibi, singletons'un yaşam boyu kontrolü yoktur. Ancak avantaj, tembel bir başlangıç ​​durumuna sahip olmaları.
Uygulamanız boyunca o singleton'ı aramazsanız, örneklenemez. Ancak, siz tekiller ürettiğinizden ve kullanmadığınızdan şüpheliyim.

Bir bileşen yerine hizmet gibi bir singleton görmelisiniz .

Singletons işe yarıyor, hiçbir zaman bir uygulama kırmadılar. Ancak onların eksiklikleri (verdiğiniz dördü) bir tane yapmamanızın nedenleridir.

Motor zaten birçok tekil kullanır. Birisi kullandıysa, o zaman bazılarına aşina olmalı:

Bilmediğiniz, singleton'lardan kaçınılması gereken sebep değil.

Singleton'ın gerekli veya kaçınılmaz olmasının birçok nedeni vardır. Oyun çerçeveleri genellikle tekilleri kullanır, çünkü sadece tek bir durumsal donanıma sahip olmanın kaçınılmaz bir sonucudur. Bu donanımları kendi kontrol elemanlarının birden fazla örneği ile kontrol etmek istemenin hiçbir anlamı yoktur. Grafik yüzeyi harici bir durumsal donanımdır ve yanlışlıkla grafik alt sisteminin ikinci bir kopyasını başlatmak felaketten başka bir şey değildir, çünkü şimdi iki grafik alt sistemi birbirlerini kontrol edemeyecekleri ve birbirlerinin üzerine yazabilecekleri birbirleriyle savaşacaklardır. Aynı şekilde, olay kuyruğu sistemiyle, fare olaylarını tanımlayıcı olmayan bir biçimde kimin kazandığı üzerine savaşacaklar. Bunlardan yalnızca birinin bulunduğu devlet dışı bir dış donanım ile uğraşırken, singleton, çatışmaları önlemek için kaçınılmazdır.

Singleton'ın duyarlı olduğu bir başka yer ise Cache yöneticileridir. Önbellek özel bir durumdur. Hayatta kalmak ve sonsuza dek yaşamak için Singletons ile aynı teknikleri kullansalar bile bir Singleton olarak görülmemeliler. Önbellekleme hizmetleri şeffaf bir hizmettir, programın davranışını değiştirmeleri beklenmez, bu nedenle önbellek hizmetini boş bir önbellekle değiştirirseniz, programın yalnızca daha yavaş çalışması dışında çalışmaya devam etmesi gerekir. Önbellek yöneticilerinin tekil kurallara istisna olmasının ana nedeni, uygulamanın kendisini kapatmadan önce bir önbellek hizmetini kapatmanın bir anlam ifade etmemesidir. singleton.

Bunlar, bu hizmetlerin tekil olması için iyi nedenlerdir. Ancak, singleton'ların olmasının iyi sebeplerinden hiçbiri, listelediğiniz sınıflara uygulanmaz.

Çünkü onlara oyunumda çok farklı yerlerde ihtiyacım olacak ve paylaşılan erişim çok kullanışlı olurdu.

Bunlar singletonların nedeni değil. Bunlar küresellerin sebepleri. Ayrıca, çeşitli sistemlerin etrafından çok şey geçirmeniz gerekirse, zayıf bir tasarımın işaretidir. Etrafı dolaşmak zorunda olmak, iyi bir OO tasarımı ile önlenebilecek olan yüksek birleşme olduğunu gösterir.

Sadece görevinizde Singletons olması gerektiğini düşündüğünüz sınıfların listesine bakarken, bunların yarısının gerçekten singleton olmaması gerektiğini, diğer yarısının da ilk başta orada olmaması gerektiğini söyleyebildiğini söyleyebilirim. Nesneleri dolaştırmanız gereken, singletonlar için gerçek iyi kullanım durumlarından ziyade uygun kapsülleme eksikliğinden kaynaklanıyor gibi görünmektedir.

Sınıflarınıza birazcık bakalım:

PlayerData (score, lives, ...)
LevelData (parameters per levels and level packs)
GameData (you may obtain some data from server to configure the game)

Sınıfların isimlerinden, bu sınıfların Anemic Domain Model antipattern gibi koktuğunu söyleyebilirim . Anemik nesneler genellikle çevrilmesi gereken birçok bağlantıya neden olur ve bu da eşleşmeyi arttırır ve kodun geri kalanını hantal hale getirir. Ayrıca, anemik sınıf, ayrıntıları kapsüllemek için nesne yönelimini kullanmaktan ziyade muhtemelen hala prosedürsel olarak düşündüğünüzü gizler.

IAP (for in purchases)
Ads (for showing ads)

Neden bu sınıfların tekil olması gerekiyor? Bana göre bunların kısa süren sınıflar olması gerektiği, kullanıcının satın alma işlemini bitirdiğinde veya reklamların gösterilmesi gerekmediğinde gerektiğinde ortaya çıkarılması ve kaldırılması gerektiği ortaya çıktı.

EntityComponentSystemManager (mananges entity creation and manipulation)

Başka bir deyişle, bir yapıcı ve hizmet katmanı? Bu sınıf niçin net bir sınırları yok, ne de bir amacı yok.

PlayerProgress (passed levels, stars)

Oyuncu neden ilerleyişini Oyuncu sınıfından ayırıyor? Player sınıfı, kendi ilerlemesini nasıl takip edeceğini bilmelidir, ilerleme takibini, sorumluluk ayrımı için Player sınıfından farklı bir sınıfta uygulamak istiyorsanız, PlayerProgress Player'ın arkasında olmalıdır.

Box2dManager (manages the physics world)

Bu sınıfın gerçekte ne yaptığını bilmeden bu konuda daha fazla yorum yapamam, ancak bir şey açıktır ki, bu sınıfın kötü adlandırılmış olduğu açıktır.

Analytics (for collecting some analytics)
SocialConnection (Facebook and Twitter login, share, friend list, ...)

Bu, Singleton'ın makul olabileceği tek sınıf gibi görünüyor, çünkü sosyal bağlantı nesneleri aslında sizin nesneleriniz değil. Sosyal bağlantılar, uzak bir serviste yaşayan harici nesnelerin gölgesidir. Başka bir deyişle, bu bir çeşit önbellek. Sadece önbellekleme bölümünü harici servisin servis bölümü ile net bir şekilde ayırdığınızdan emin olun, çünkü ikinci bölümün bir singleton olması gerekmez.

Bu sınıfların örneklerini iletmekten kaçınmanın bir yolu ileti iletisini kullanmaktır. Bu sınıfların örneklerine doğrudan bir çağrı yapmak yerine, bunun yerine, senkronize olmayan bir şekilde Analytic ve SocialConnection servisine gönderilen bir mesaj gönderirsiniz ve bu servisler bu mesajları almak ve mesaj üzerinde hareket etmek için abone olunur. Olay kuyruğu zaten bir tekil olduğundan, aramayı sürtünerek, bir tekille iletişim kurarken gerçek bir örneği geçme gereksinimini ortadan kaldırırsınız.

Bana Singletons her zaman kötü.

Mimarlığımda oyun sınıfının yönettiği bir GameServices koleksiyonu oluşturdum. Gerektiği gibi bu koleksiyona ekleme ve çıkarma arama yapabilirim.

Global kapsamda bir şey söyleyerek temelde yukarıda vermiş olduğunuz örneklerde "bu acılama tanrıdır ve usta yoktur" diyorsunuz, bunların çoğunun ya yardımcı sınıflar ya da GameServices olduğunu söyleyebilirim ki bu durumda oyun onlardan sorumlu olacaktır.

Ama bu sadece motorumdaki tasarımım, durumunuz farklı olabilir.

Daha doğrudan koymak ... Tek gerçek singleton, kodun her bölümüne ait olan oyundur.

Bu cevap, sorunun öznel doğasına dayanıyor ve tamamen benim görüşüme dayanıyor, buradaki tüm geliştiriciler için doğru olmayabilir.

Düzenleme: İstenildiği gibi ...

Tamam şu an kafamdan geliyor, çünkü kodum şu anda önümde değil ama esasen herhangi bir oyunun temelinde gerçek bir singleton olan Oyun sınıfı ... olması gereken!

Ben de aşağıdakileri ekledim ...

class Game
{
   IList<GameService> Services;

   public T GetService<T>() where T : GameService
   {
       return Services.FirstOrDefatult(s => s is T);
   }
}

Şimdi ayrıca tüm programdaki tüm singletonlarımı içeren (statik olan) bir sistem sınıfım (statik) var (çok az oyun ve yapılandırma seçenekleri ve bununla ilgili olanlar var) ...

public static class Sys
{
    // only the main game assembly can set this (done by the game ctor)
    // anything can get
    public static Game Game { get; internal set; }
}

Ve kullanım ...

Her yerden, bir şey yapabilirim.

var tService = Sys.Game.getService<T>();
tService.Something();

Bu yaklaşım, oyunumun tipik olarak "singleton" olarak kabul edilebilecek şeyler "sahibi olduğum" anlamına gelir ve temel GameService sınıfını istediğim gibi uzatabilirim. Oyunumun belirli durumlar için gerektiği gibi uygulayan hizmetleri kontrol edip çağırdığı IUpdateable gibi arayüzlerim var.

Ayrıca daha belirli sahne senaryoları için diğer hizmetleri alan / genişleten hizmetlere de sahibim.

Örneğin ...

Fizik simülasyonlarımı idare eden bir Fizik servisim var ancak sahneye bağlı olarak fizik simülasyonu biraz farklı davranışlar gerektirebilir.

Singleton'un rakiplerinin çoğu zaman göz önünde bulundurmadığı temel bir singleton eliminasyon bileşeni, singletons örnek değerlerine yol açtığında nesnelerin enkapsüle ettiği çok daha karmaşık durumla başa çıkmak için ekstra bir mantık ekliyor. Aslında, bir singletonu bir değişkenle değiştirdikten sonra bir nesnenin durumunu tanımlamak bile zor olabilir, ancak singletonları örnek değişkenlerle değiştiren programcılar bununla başa çıkmak için hazırlanmalıdır.

Örneğin, Java adlı için, karşılaştırın HashMap.NET en ile Dictionary. Her ikisi de oldukça benzer, ancak önemli bir farkları var: Java HashMapkullanımı zor kodlanmış equalsve hashCode(etkin bir şekilde bir singleton karşılaştırıcı kullanıyor), .NET'ler bir yapıcı parametresi Dictionaryörneğini kabul edebilir IEqualityComparer<T>. Korumanın çalışma zamanı maliyeti IEqualityComparerasgari düzeydedir ancak getirdiği karmaşıklık değildir.

Her Dictionaryörnek bir kapsül IEqualityCompareriçerdiğinden, durumu yalnızca gerçekten içerdiği anahtarlar ve bunlarla ilişkili değerler arasındaki bir eşleme değil, bunun yerine anahtarlar ve karşılaştırıcı ve bunlarla ilişkili değerlerin tanımladığı eşdeğerlik kümeleri arasındaki bir eşlemedir . İki durum olursa d1ve d2bir Dictionaryaynı etmek tutma referanslar IEqualityComparer, yeni bir örneğini üretmek mümkün olacaktır d3herhangi şekilde x, d3.ContainsKey(x)eşit olacaktır d1.ContainsKey(x) || d2.ContainsKey(x). Bununla birlikte, farklı keyfi eşitlik karşılaştırıcılarına referanslar verebilir d1ve d2referanslar alabilirse, genel olarak koşulun geçerli olmasını sağlamak için bunları birleştirmenin bir yolu olmayacaktır.

Singleton'ları ortadan kaldırmak için örnek değişkenler eklemek, ancak bu örnek değişkenler tarafından ima edilebilecek olası yeni durumları tam olarak hesaba katmamak, singleton ile olduğundan daha kırılgan hale gelen kod oluşturabilir. Her nesne örneğinin ayrı bir alanı varsa, ancak hepsi aynı nesne örneğini tanımlamazsa işler kötü şekilde arızalanırsa, o zaman tüm yeni alanların satın aldığı şeylerin yanlış gidebilmesi için artan sayıda yol vardır.