Як я можу уникнути виникнення багатьох одиночних клавіш у своїй ігровій архітектурі?

Я використовую ігровий движок cocos2d-x для створення ігор. Двигун вже використовує багато однотонних. Якщо хтось ним користувався, то їм слід ознайомитись з деякими з них:

Director
SimpleAudioEngine
SpriteFrameCache
TextureCache
EventDispatcher (was)
ArmatureDataManager
FileUtils
UserDefault

та багато іншого, загалом близько 16 класів. Ви можете знайти подібний список на цій сторінці: Об'єкти Singleton в Cocos2d-html5 v3.0 Але коли я хочу написати гру, мені потрібно набагато більше синглів:

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)
.....

Чому я думаю, що вони повинні бути одинокими? Тому що мені знадобляться в дуже різних місцях у моїй грі, і спільний доступ буде дуже зручним. Іншими словами, я не знаю, що їх десь створити і передати покажчики на всю мою архітектуру, оскільки це буде дуже важко. Також це такі речі, які мені потрібні лише одні. У будь-якому випадку мені знадобиться декілька, я також можу використовувати мультитонний візерунок. Але найгірше те, що Сінглтон є найбільш гостро критикованою моделлю через:

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

Деякі думки ви можете знайти тут: https://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons та https://stackoverflow.com/questions/4074154/when-should-the-singleton -паттерн-не-вживаний-крім того-очевидний

Отже, я думаю, я роблю щось не так. Я думаю, що мій код пахне . :) Я думаю, як більш досвідчені розробники ігор вирішують цю архітектурну проблему? Я хочу перевірити, можливо, все ж нормально в розробці ігор мати більше 30 синглів , які вважаються тими, які вже є в ігровому двигуні.

Я подумав використовувати Singleton-Facade, який матиме екземпляри всіх цих потрібних мені класів, але кожен з них уже не був би однотонним. Це усуне безліч проблем, і у мене був би один сингтон, який би був самим Фасадом. Але в цьому випадку у мене буде ще одна проблема дизайну. Фасад перетвориться на ОБ'ЄКТ БОГУ. Я думаю, що це теж пахне . Тому я не можу знайти хорошого дизайнерського рішення для цієї ситуації. Будь ласка, порадь.

Я ініціалізую свої сервіси в моєму головному класі додатків, а потім передаю їх як покажчики на все, що потрібно використовувати, або через конструктори чи функції. Це корисно з двох причин.

По-перше, порядок ініціалізації та очищення простий і зрозумілий. Немає можливості випадково ініціалізувати одну службу де-небудь ще, як ви можете, з одиночним.

По-друге, зрозуміло, хто від чого залежить. Я легко бачу, яким класам потрібні які послуги саме з декларації класу.

Ви можете подумати, що прикро передавати всі ці об’єкти навколо, але якщо система розроблена добре, це насправді зовсім не погано і робить речі набагато зрозумілішими (для мене все одно).

Я не буду обговорювати про зло, що стоїть за одиночними, тому що Інтернет може зробити це краще, ніж я.

У своїх іграх я використовую шаблон пошуку локатора, щоб уникнути безлічі синглів / менеджерів.

Концепція досить проста. У вас є лише один Singleton, який діє як єдиний інтерфейс, щоб досягти того, що ви використовували як Singleton. Замість того, щоб мати кілька синглтон, у вас зараз є лише один.

Дзвінки типу:

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

Виглядає так, використовуючи шаблон пошуку ":

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

Як ви бачите, кожен Singleton міститься в локаторі послуг.

Щоб отримати більш детальне пояснення, я пропоную вам ознайомитись із цією сторінкою щодо використання шаблону локатора .

[ EDIT ]: як зазначено в коментарях, сайт gameprogrammingpatterns.com також містить дуже цікавий розділ про Singleton .

Я сподіваюся, що це допомагає.

Читаючи всі ці відповіді, зауваження та статті, особливо ці дві геніальні статті,

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

врешті-решт я прийшов до наступного висновку, який є своєрідною відповіддю на моє власне питання. Найкращий підхід - не лінуватися і переходити залежності безпосередньо. Це явно, перевіряється, немає глобального доступу, може вказувати на неправильну конструкцію, якщо вам доведеться передати делегатів дуже глибоко і в багатьох місцях тощо. Але в програмуванні один розмір підходить не всім. Таким чином, все ще є випадки, що передавати їх безпосередньо не зручно. Наприклад, якщо ми створимо ігрову рамку (шаблон коду, який буде повторно використаний як базовий код для розробки різних видів ігор) і включимо туди безліч сервісів. Тут ми не знаємо, наскільки глибоко можна пройти кожну службу і скільки місць це знадобиться. Це залежить від певної гри. То що ми робимо в таких випадках? Ми використовуємо шаблон дизайну Locator служби замість Singleton,

1. Ви не програмуєте на реалізації, а на інтерфейси. Це дуже важливо з точки зору директорів ООП. Під час виконання ви можете змінити або навіть відключити послугу за допомогою шаблону Null Object. Це не тільки важливо з точки зору гнучкості, але безпосередньо допомагає при тестуванні. Ви можете відключити, знущатися, також ви можете використовувати шаблон «Декоратор», щоб також додати деякі журнали та інші функціональні можливості. Це дуже важлива властивість, якої Сінглтон не має.
2. Ще одна величезна перевага полягає в тому, що ви можете контролювати термін експлуатації об’єкта. У Singleton ви керуєте лише тим часом, коли об’єкт буде породжений шаблоном Lazy Initialization. Але як тільки об’єкт породжується, він буде жити до кінця програми. Але в деяких випадках ви хочете змінити послугу. Або навіть закрити його. Особливо в іграх ця гнучкість дуже важлива.
3. Він поєднує / обгортає декілька синглтонів в один компактний API. Я думаю, ви також можете використовувати такі фасади, як Локатори обслуговування, які для однієї операції можуть використовувати одразу кілька сервісів.
4. Ви можете стверджувати, що ми все ще маємо глобальний доступ, який є основною проблемою дизайну в Singleton. Я погоджуюся, але цей шаблон нам знадобиться лише і лише в тому випадку, якщо ми хочемо отримати глобальний доступ. Ми не повинні скаржитися на глобальний доступ, якщо ми вважаємо, що введення прямої залежності не є зручним для нашої ситуації, і нам потрібен глобальний доступ. Але навіть для цієї проблеми можливе вдосконалення (див. Другу статтю вище). Ви можете зробити всі сервіси приватними, і ви можете успадкувати від класу "Локатор послуг" усі класи, які, на вашу думку, повинні використовувати ці послуги. Це може істотно звузити доступ. І врахуйте, що у випадку Singleton ви не можете використовувати спадщину через приватний конструктор.

Також слід врахувати, що ця модель використовувалася в Unity, LibGDX, XNA. Це не є перевагою, але це свого роду доказ зручності використання моделі. Вважайте, що ці двигуни розроблялися багатьма розумними розробниками протягом тривалого часу, і на етапах еволюції двигуна вони все ще не знайшли кращого рішення.

На закінчення, я думаю, що Локатор послуг може бути дуже корисним для сценаріїв, описаних у моєму запитанні, але все ж слід уникати, якщо це можливо. Як правило, використовуйте його, якщо потрібно.

EDIT: Після року роботи та використання прямих DI та проблем із величезними конструкторами та безліччю делегацій я провів більше досліджень і знайшов хорошу статтю, яка розповідає про плюси та мінуси щодо методів DI та Locator послуг. Цитуючи цю статтю ( http://www.martinfowler.com/articles/injection.html ) Мартіна Фаулера, яка пояснює, коли насправді локатори сервісу погані:

Таким чином, головне питання - це для людей, які пишуть код, який очікується використовувати в додатках, що не підпадають під контроль автора. У цих випадках навіть мінімальне припущення про пошук локатора є проблемою.

Але в будь-якому випадку, якщо ви хочете, щоб ми вперше пройшли DI, ви повинні прочитати цю http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/ статтю (вказав @megadan) , приділяючи дуже ретельну увагу Закону Деметера (LoD) або принципу найменших знань .

Не рідкість частини бази коду вважати наріжними об'єктами або фундаментальним класом, але це не виправдовує, що життєвий цикл диктується як Singleton.

Програмісти часто покладаються на схему Сінглтона як на зручність і чистий лінь, а не на альтернативний підхід і бути більш багатослівним і нав'язувати об'єктивні відносини між собою в явному маєтку.

Тож запитайте себе, що простіше в обслуговуванні.

Якщо ви схожі на мене, я вважаю за краще мати змогу відкрити файл заголовка та коротко переглядати аргументи конструктора та публічні методи, щоб побачити, яким залежностей потрібен об'єкт, а не перевіряти сотні рядків коду у файлі реалізації.

Якщо ви зробили об'єкт Singleton і пізніше зрозуміли, що вам потрібно вміти підтримувати кілька екземплярів зазначеного об'єкта, уявіть необхідні зміни, якщо цей клас був чимось, що ви використовували досить широко у всій своїй кодовій базі. Кращою альтернативою є створення явних залежностей, навіть якщо об'єкт виділяється лише один раз і якщо виникає потреба у підтримці декількох екземплярів, ви можете сміливо робити це без таких проблем.

Як зазначають інші, використання схеми Singleton також пригнічує зв'язок, що часто означає слабкий дизайн і високу згуртованість між модулями. Така згуртованість, як правило, небажана і призводить до крихкого коду, який важко підтримувати.

Сінглтон - відомий зразок, але добре знати цілі, які він служить, і його плюси і мінуси.

Це справді має сенс, якщо взагалі немає відносин .
Якщо ви можете обробити свій компонент абсолютно іншим об'єктом (немає сильної залежності) і очікуєте, що матиме однакову поведінку, сингл може бути хорошим вибором.

З іншого боку, якщо вам потрібен невеликий функціонал , який використовується лише в певний час, вам слід віддати перевагу передачі посилань .

Як ви вже згадували, одинаки не мають контролю за життям. Але перевага в тому, що вони мають ледачу ініціалізацію.
Якщо ви не зателефонуєте цьому синглтону протягом свого життя програми, він не буде створений. Але я сумніваюся, ви будуєте одинаків і не використовуєте їх.

Ви повинні бачити одиночне слово як службу замість компонента .

Сінглтон працює, вони ніколи не порушували жодної програми. Але їх недоліки (чотири наведені вами чотири) причини, з яких ви цього не зробите.

Двигун вже використовує багато однотонних. Якщо хтось ним користувався, то їм слід ознайомитись з деякими з них:

Незнайомість не є причиною того, чому одиноких людей потрібно уникати.

Є багато вагомих причин, чому Singleton необхідний або неминучий. Ігрові рамки часто використовують одиночні кнопки, оскільки це неминучий наслідок наявності лише одного апаратного обладнання. Немає сенсу ніколи хотіти керувати цими обладнаннями за допомогою декількох примірників відповідних обробників. Графічна поверхня є зовнішнім стаціонарним обладнанням, і випадково ініціалізація другої копії графічної підсистеми - це не що інше, як катастрофічне, оскільки тепер дві графічні підсистеми будуть битися один з одним за те, хто може малювати, і коли, переписуючи один одного безконтрольно. Так само і з системою черги на події, вони будуть вести боротьбу за те, хто отримує події миші недетермінованим способом. У роботі з надзвичайним зовнішнім обладнанням, в якому є лише один з них, одинарне неминуче запобігання конфліктам.

Ще одне місце, де Singleton є розумним, - це кеш-менеджери. Схованки - це особливий випадок. Їх насправді не можна вважати синглтоном, навіть якщо вони використовують усі ті ж методики, що й Сінглтон, щоб залишатися живими та жити назавжди. Служби кешування - це прозорі сервіси, вони не повинні змінювати поведінку програми, тому якщо ви заміните службу кешування на нульовий кеш, програма все одно працюватиме, за винятком того, що вона працює лише повільніше. Основна причина, чому керуючі кешами є винятком для одиночного, хоча це не має сенсу вимикати кеш-службу перед тим, як вимкнути саму програму, тому що це також відкине кешовані об'єкти, що перешкоджає тому, що вона має як одинарний.

Це вагомі причини, чому ці послуги є одинаковими. Однак жодна з вагомих причин мати одиночні кнопки не стосується перелічених вами класів.

Тому що мені знадобляться в дуже різних місцях у моїй грі, і спільний доступ буде дуже зручним.

Це не причини синглів. Це причини глобалів. Це також ознака поганого дизайну, якщо вам потрібно пройти багато речей навколо різних систем. Передача речей вказує на високу зчіпність, яку можна запобігти хорошим дизайном OO.

Тільки дивлячись на список класів у вашій публікації, який, на вашу думку, потребують одинаків, я можу сказати, що половина з них насправді не повинна бути одиночними, а інша половина, здається, навіть не повинна бути там в першу чергу. Те, що вам потрібно передати об'єкти навколо, здається, пояснюється відсутністю належної інкапсуляції, а не реальними випадками хорошого використання для одиночних.

Давайте розглянемо ваші заняття потроху:

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

Якраз із назв класів я б сказав, що ці класи пахнуть як антипатерні Anemic Domain Model . Анемічні об'єкти, як правило, призводять до безлічі даних, які потрібно передавати навколо, що збільшує зв'язок і робить решту коду громіздкою. Також анемічний клас приховує той факт, що ви, ймовірно, все ще думаєте процедурно, а не використовуєте орієнтацію об'єкта для інкапсуляції деталей.

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

Чому для цих класів потрібно бути одиночними? Мені здається, що це мають бути короткочасні заняття, які слід виховувати, коли вони потрібні, і деконструювати, коли користувач закінчує покупку або коли рекламу більше не потрібно показувати.

EntityComponentSystemManager (mananges entity creation and manipulation)

Іншими словами, конструктор і сервісний рівень? Чому цей клас без чітких меж і цілей навіть там на першому місці?

PlayerProgress (passed levels, stars)

Чому прогрес гравця відрізняється від класу гравців? Клас гравця повинен знати, як слідкувати за власним прогресом, якщо ви хочете впровадити відстеження прогресу в іншому класі, ніж клас гравця для розділення відповідальності, тоді PlayerProgress повинен стояти за гравцем.

Box2dManager (manages the physics world)

Я не можу більше коментувати цей клас, не знаючи, що цей клас насправді робить, але одне очевидно, що цей клас погано названий.

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

Це, здається, єдині класи, де Singleton може бути розумним, оскільки об'єкти соціального зв'язку насправді не є вашими об'єктами. Соціальні зв’язки - це лише тінь зовнішніх об'єктів, що живуть у віддаленій службі. Іншим словом, це свого роду кеш. Просто переконайтеся, що ви чітко відокремили кеширувальну частину від службової частини зовнішньої служби, оскільки остання частина не повинна бути однократною.

Один із способів уникнути передачі екземплярів цих класів - це використання передачі повідомлень. Замість того, щоб робити прямий дзвінок до екземплярів цих класів, натомість ви асинхронно надсилаєте повідомлення, адресоване службі Analytic and SocialConnection, і ці служби підписуються на отримання цих повідомлень і діють на це повідомлення. Оскільки в черзі подій вже є сингл, виправляючи виклик, ви уникаєте необхідності передавати фактичний екземпляр під час спілкування з однотонним.

Для мене одиночки ВЖЕ завжди погані.

У своїй архітектурі я створив колекцію GameServices, якою керує ігровий клас. Я можу шукати додавання та видалення з цієї колекції за потребою.

Кажучи, що щось знаходиться в глобальному масштабі, ви в основному говорите «цей хтінг - це бог і не має господаря» у наведених вище прикладах, я б сказав, що більшість із них є або допоміжними класами, або GameServices, і в цьому випадку гра відповідала б за них.

Але це тільки моя конструкція в моєму двигуні, ваша ситуація може бути різною.

Якщо говорити прямо… Єдиний справжній синглтон - це гра, оскільки вона володіє кожною частиною коду.

Ця відповідь ґрунтується на суб'єктивному характері питання і ґрунтується виключно на моїй думці, це може бути неправильним для всіх розробників там.

Редагувати: За запитом ...

Гаразд, це з моєї голови, тому що в даний момент у мене немає свого коду, але, по суті, в корені будь-якої гри - ігровий клас, який справді є одинаковим ... це повинно бути!

Тому я додав наступне ...

class Game
{
   IList<GameService> Services;

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

Тепер у мене також є системний клас (статичний), який містить усі мої синглтони з усієї програми (містить дуже мало, варіантів ігор та конфігурацій, і про це) ...

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; }
}

І використання ...

З будь-якого місця я можу зробити щось подібне

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

Такий підхід означає, що моя гра «Влаштовує» речі, які, як правило, вважаються «одиночними», і я можу розширити базовий клас GameService, як тільки я хочу. У мене є такі інтерфейси, як IUpdateable, що моя гра перевіряє та залучає до будь-яких служб, які реалізують її за потребою в конкретних ситуаціях.

У мене також є сервіси, які успадковують / розширюють інші послуги для більш конкретних сценаріїв сцени.

Наприклад ...

У мене є служба фізики, яка займається моїми фізичними моделюваннями, але залежно від моделювання фізики сцени може знадобитися дещо інша поведінка.

Основним інгредієнтом усунення синглтона, який опоненти синглтона часто не враховують, є додавання додаткової логіки для вирішення набагато складнішого стану, яке об'єкти інкапсулюють, коли одиночні поступаються місцем значень екземплярів. Дійсно, навіть визначити стан об’єкта після заміни сингтона на змінну екземпляра може бути складно, але програмісти, які замінюють одиночні кнопки змінними екземпляра, повинні бути готові боротися з ним.

Порівняйте, наприклад, Java HashMapз .NET Dictionary. Обидва є досить схожими, але вони мають ключову відмінність: у Java HashMapважко закодовано equalsта hashCode(він ефективно використовує однотонний компаратор), тоді як .NET Dictionaryможе приймати екземпляр IEqualityComparer<T>параметру конструктора. Вартість експлуатації на утримання IEqualityComparerмінімальна, але складність, яку вона впроваджує, не є.

Оскільки кожен Dictionaryекземпляр інкапсулює an IEqualityComparer, його стан - це не просто відображення між ключами, які він насправді містить, та їх асоційованими значеннями, а натомість відображенням між наборами еквівалентності, визначеними ключами та компаратором, та пов'язаними з ними значеннями. Якщо два примірники d1і d2про Dictionaryпосиланнях дотримуються же IEqualityComparer, можна буде виробляти новий екземпляр d3такої , що для будь-якого x, d3.ContainsKey(x)дорівнюватиме d1.ContainsKey(x) || d2.ContainsKey(x). Якщо, однак, d1і d2можуть бути посилання на різні довільні порівняння рівності, взагалі не буде способу їх злиття, щоб забезпечити виконання цієї умови.

Додавання змінних екземплярів у прагненні усунути сингли, але не вдається належним чином врахувати можливі нові стани, які могли б мати на увазі ці змінні екземпляри, може створити код, який в кінцевому підсумку буде більш крихким, ніж це було б з одинаком. Якщо кожен екземпляр об'єкта має окреме поле, але речі погано працюватимуть, якщо всі вони не ідентифікують один і той же екземпляр об'єкта, то всі нові куплені поля - це збільшена кількість способів, коли все може піти не так.