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

[Alexmody]

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

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


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

[Gaen]

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

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

[mikhailk]

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

[Psycho Tiger]

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

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

[Alexmody]

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

[mikhailk]

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

[expl]

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

[Psycho Tiger]

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

[Alexmody]

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

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

[expl]

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

в конструкторе/тянется из пула
что за "пул"?

[GBee]

Все мои менеджеры в последнем проекте лежат в одном синглтоне. Есть друг, который говорит: "Если в проекте появились класс с названием manager, значит что-то пошло не так", но не обосновал.

[incvizitor]

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

Можете объяснить, что Вы этим сказать хотите?

[Psycho Tiger]

В баблинге промежуточный класс ничего не знает о типах событий.
Это мешает ему подписаться на это событие?
При протягивании ссылок НЕ получится использовать промежуточный класс без тех, которые он протягивает,
или получится - но типизация пойдёт лесом.
Как можно протянуть ссылку в ущерб типизации?
Первую часть фразы тоже присоединяюсь к вопросу.
что за "пул"?
Object pool. Лужа объектов. Меня mayakwd недавно по этой теме красочно просвящал. (Передаю ему привет!)

[expl]

Теперь, кажется понял фразу "инстантциация происходит в конструкторе/тянется из пула"
Думал, может какой другой пул, а тут речь о том что не важно, создается ли из пула или с помощью new (правильно?)

Как можно протянуть ссылку в ущерб типизации?
Я этот подход не использую, за исключением передачи параметров из лоадера во флешку - там все одним динамическим объектом передается и промежуточные ничего не знают о его структуре.

Но это могло бы выглядеть так:

class ServiceClient {
var _service:Service;

public function new ServiceClient(serviceContainer:Object):void
{
_service = (serviceContainer as IServiceContainer).service;
}
}

public class ServiceClientOwner {// Вот этот класс ничего не знает о IServiceContiner, правда он завязан на ServiceClient, но сейчас речь не об этом

public function ServiceClientOwner(servieContainer:Objесt)
{
_serviceClient = new ServiceClient(serviceContainer);
}
}


Цитата:
В баблинге промежуточный класс ничего не знает о типах событий.

Это мешает ему подписаться на это событие?
Нет, но если он не подписался - класс можно использовать без передаваемого им класса события

Например, через визуальный список рендереров может проходить куча разнотипных событий рендереров, но это не мешает вынести его в библиотеку без этих конкретных классов событий.

[Psycho Tiger]

(правильно?)
Правильно.

Я вот тебя вообще не понимаю.
Класс не знает ни о каком IServiceClient (вообще ситуация из ряда вон) и поэтому типа подход плохой. Ну, а если он не знает о SingletoneClient? В этом случае вообще хана.

Нет, но если он не подписался - класс можно использовать без передаваемого им класса события
Все события наследуются от Event`а. Можно подписаться на любое событие, сузив объект события от CustomEvent до Event.


Вообще менеджер на каком-то уровне глобальная вещь. И если для работы не всегда есть конкретный класс этого менеджера — то блин, надо как-то постараться и заиметь интерфейс, что менеджер реализует. Иначе зачем этот менеджер туда передавать вообще?

[expl]

Класс не знает ни о каком IServiceClient (вообще ситуация из ряда вон) и поэтому типа подход плохой
Наоборот хорошо, что ServiceClientOwner, которому не нужен IService о нём не знает. Плохо, что приводить типы в ServiceClient надо

[Psycho Tiger]

Понятие "знает" это импорт класса?

[expl]

Можно и так сказать
Согласись, если класс импортирует какой-нибудь специфичный игровой менеджер - в библиотеку этот класс не вынесешь, даже если он с ним ничего не делает

[Psycho Tiger]

Я если честно вообще не вижу проблем в "лишнем" импорте класса. Ну болтается и болтается, я туда вообще не смотрю.
А про вынос - интерфейса хватит. Если вообще на то пошло, то можно предоставить геттер на нужный объект, который будет содержать сеттер на нужный менеджер.

[incvizitor]

Согласись, если класс импортирует какой-нибудь специфичный игровой менеджер - в библиотеку этот класс не вынесешь, даже если он с ним ничего не делает


import IManager;
public class Client{

_manager:IManager;

pubilc function Client(manager:IManager){
_manager=manager;
}
}


Делаем вот так:


public class ManagerA implements IManager{
}


Или вот так:


public class ManagerC{
}



public class DelegateManagerC implements IManager{
private var _targer:ManagerC;
}