Внезапно у меня немного кризис ОО. За последние пару лет я неплохо использовал объекты Singleton. Я использовал их во многих местах.
Например, при разработке Java-приложения MVC я бы создал класс Singleton 'SystemRegistry' для хранения моделей и классов классов (я работал только с простыми приложениями, и необходимость в нескольких представлениях никогда не возникала).
Когда я создаю свою модель и просматриваю объекты (которые не были одиночными, просто нормальными объектами), я бы сделал что-то вроде:
SystemRegistry.getInstance().setModel(model);
В моих классах контроллера (которые были в значительной степени обработчиками событий для разных элементов GUI), я бы получил доступ к представлению или модели следующим образом:
SystemRegistry.getInstance().getView();
Я бы никогда не использовал класс SystemRegistry в части модели моего приложения, но иногда использовал его в своем представлении для доступа (но редко, если вообще когда-либо) для изменения информации из модели.
Из того, что я прочитал (особенно статьи Стив Йегге), это выглядит плохой способ разработки моего приложения. Любые идеи относительно лучшего способа структурирования моего кода.
Кроме того, еще один аспект того, как я проектирую классы, которые могут или не могут быть связаны с Singletons, - это использование классов "Тип менеджера". Примером является (очень простой) движок OpenGL, созданный на С++.
Основным классом был GameEngine. Это был класс over-arcing, который хранил кучу менеджеров и обрабатывал основной цикл, а что нет. Некоторые из менеджеров, хранящихся в этом классе, были такими, как: ObjectManager, RenderingManager, LightingManager, EventManager (включая ввод), HUDManager, FrameRateManager, WindowManager и т.д. Возможно, было еще несколько.
В основном эти классы обрабатывали различные аспекты игрового движка. Имена довольно просты, поэтому вы должны иметь представление о том, как они используются.
Теперь это должно было быть многоразовой базой, которую я мог бы использовать в разных проектах, с необходимостью идеально ее изменить.
В каждой новой игре я бы создал экземпляр GameEngine как переменной класса (большая часть игровой логики хранилась в одном классе) и настраивала разных менеджеров (например, загружая окно co- ординаты или детали освещения из файла, установка FPS и т.д.). Чтобы зарегистрировать объект в ObjectManager, я бы сделал что-то вроде:
Player player = new Player();
gameEngine.getObjectManager().addObject(player);
Этот объект теперь будет сохранен в векторе класса ObjectManager и будет нарисован, когда GameEngine вызывает метод ObjectOpject() объекта ObjectManager в каждом кадре.
Теперь я мог бы немного параноидально после этой статьи в Singletons (и, возможно, не хватило времени, чтобы обернуть вокруг меня голову), но я начинаю вторгаться и задаюсь вопросом, способ, которым я разработал свой GameEngine был правильным (из-за отсутствия лучшего слова) и не просто попадал в те же ловушки, которые разделял шаблон Singleton.
Любые комментарии к моему сообщению будут высоко оценены.
Изменить: Спасибо за ответы. Я их очень ценю. Если возможно, мне бы хотелось, чтобы кто-то мог дать мне несколько советов относительно двух сценариев проекта, опубликованных выше. Как я мог избежать использования синглтонов/менеджеров?
С первым, будет ли DI правильным ответом? Должен ли я даже дать виду доступ к модели (вероятно, это скорее ответ MVC)? Будет ли представление выгодно реализовать интерфейс (чтобы можно было подключить несколько разных представлений)?
Во втором случае, как еще можно было структурировать приложение? Является ли gripe просто использованием классов Manager в отличие от более конкретных имен? Или в некоторых случаях классы могут быть дополнительно разбиты (например, ObjectHolder, ObjectDrawer, ObjectUpdater)?
