Обозначение классов Менеджеров
 

1. Есть сервисные классы, которые могут выступать в роли статических/синглтонов и являются менеджерами/контроллерами, напр:
SoundManager – добавляет и управляет всеми звуками/музыкой игры.
EffectManager – создает динамически систему частиц и проигрывает ее, по аналогии TweenMax, Tweeer.
TransitionsManager – по аналогии с вторым классом.

Добавление в конце названия класса “Manager/Controller” режет глаза и достаточно длинно.
Мне приятней обращаться Effect.create(….); Sound.play(…) и пр. В то же время это не обычные классы.
Как вы именуете классы подобного типа, т.е. как принято выделять их как глобальные менеджеры?


2. Столкнулся с такой дилеммой, есть напр. ObjectManager, который управляет добавлением/удалением игровых объектов в сцену. Теоретически в игре он должен существовать один, т.е. делать его статикой или синглтоном. Но я очень не люблю плодить глобальные классы, к которым можно обратится в любой точке игры, это разрушает общую структуру игры, которая разделена на логические части в основном за счет различных паттернов, которые помогают избавится от статики и синглтонов.
Если еще с использованием SoundManager, EffectManager, я могу смирится, т.к. это удобно и данные классы в принципе можно назвать сервисными, т.е. типа Math, т.к. они не влияют на структуру и взаимодействие логических частей игры, но вот ObjectManager я не хочу делать глобальным, т.к. он строго используется в определенной части игры и его в большой степени нельзя отнести к сервисному классу, т.е. он является значимым участником в структуре игры.
Если я не хочу делать класс ObjectManager глобальным (статическим и синглтоном), а создаю экземпляр, то как обозначить, что его можно создать только один раз…создать член статик переменную подсчитывающую количество созданных экземпляров, и если больше 1, то выдавать throw с сообщением…, т.е. вообще как это принято? Или все же посоветуете сделать ObjectManager синглтоном?

1. Названия типа SomethingManager меня вполне устраивают, пользы от длинного и понятного названия гораздо больше чем от короткого и быстропищущегося. К использовании "Controller" в названии отношусь с осторожностью, т.к. может возникнуть путаница с контекстом MVC: тот же класс, ведающий объектами на сцене, относится скорее к виду, нежели к контроллеру.

2. Кроме private static члена тут больше ничего особо не придумать. Если не хотите делать ваш синглтон глобальным, то просто не делайте метод для получения экземпляра. Останется только конструктор, который в первый раз отработает нормально, а после этого будет выкидывать исключения. И тогда экземпляр можно будет получить только по ссылке.

+1
Синглтон по сути своей глобальным как раз быть не обязан. Более того, есть мнение, что и не должен. :)

А я вот stage считаю синглтоном.

Мои менеджеры не статичные, вот. Все эти менеджеры нужны на каком-то уровне или нескольких. Например, коннектор к серверу не должен иметь доступ к менеджеру хинтов, а вот вью должен. Отсюда этот менеджер можно сделать некоторого рода "глобальным" для всего вью. Я не ленюсь тянуть ссылки.

Спасибо за ответы.
Psycho Tiger
>>Все эти менеджеры нужны на каком-то уровне или нескольких.
Да, я тоже именно так стараюсь делать, передаю ссылки в неск. соотв. объектов работающих в одной логике. Это помогает локализировать классы и задачи, обособив классы, не убивая всю игру глобализацией, что хорошо сказывается, когда перетягивается классы от одной игре к другой.
Интересно, а вы как именуете менеджеры с окончанием "Manager"?

SoundManager -> SoundMaster или SoundProcessor
и т.д.

У протяжки ссылок есть объективный недостаток:
об интерфейсах/классах, которые протягиваются начинают знать промежуточные объекты, которым это не нужно

Обычно инстантциация происходит в конструкторе/тянется из пула и всё такое и промежуточные объекты сохраняют это дело в локальных переменных, т.е. в принципе и не сохраняют. Это сродни "нет бабблингу событий, ведь на них могут подписаться те объекты, через которые идёт event-flow!".
Ну вот сейчас как раз код рефакторю, структура такая. AvatarGroup надо было тоже назвать AvatarManager, но вот что-то поленился. Пакет, кстати, тоже.

Psycho Tiger
Вот тут мне еще один интересный вариант именования менеджеров предложили, фактически которым я и пользовался:
"Чтобы избавится от Manager/Controller можно их вынести в имя пакеджа а имена таким классам давать во множественном числе (например, Sounds)."

В принципе, к каждому Менеджеру требуются вспомогательный класс/классы, поэтому выделение пакета с названием, напр. SoundManager, где будут помещены вспомогательные классы и класс менеджер - Sounds, где "s", как раз не плохо отображает смысл менеджера.

В баблинге промежуточный класс ничего не знает о типах событий.
При протягивании ссылок НЕ получится использовать промежуточный класс без тех, которые он протягивает,
или получится - но типизация пойдёт лесом.

что за "пул"?