Предисловие Желаю вам здоровья, дорогие пользователи Хабра.
В данной публикации не будет столько внимания правилам использования.
Синглтон А что касается моего видения этого узора.
Хочу вас предупредить, что я совершенно зеленый человек.
Я не гуру программирования, не старший и, возможно, даже не средний.
Имею достаточный опыт разработки исключительно в Unity, поэтому затрагиваю только эту среду.
Поначалу мне было страшно делиться своими мыслями, но, вспомнив, что иногда здесь публикуются серьезные люди, я решил попробовать.
Я люблю пользователей этого сайта, и даже если моя карма уйдет в Марианскую впадину, комментарии всегда помогут мне понять то, чего я раньше не мог понять, и найти ту самую истину!
Почему люди ненавидят шаблон Singleton?
Причин невероятно много, хотя, как мне стало ясно, многие из них взяты абсолютно из воздуха, в попытке показать себя доблестным защитником SOLID-кода.Давайте посмотрим на некоторые из них! Нарушение принципа единоличной ответственности.
Извини, что? По какой причине наш Одиночка со 100% вероятностью нарушает этот принцип? Тот факт, что класс имеет глобальную точку доступа, не делает его классом БОГА.
Саундменеджер? Сетевой менеджер? Менеджер сцен? Даже в официальном уроке Unity3D SoundManager был создан Singleton. Судя по всему, этот пункт уже не нужен.
Синглтон не подлежит тестированию.
Другими словами, аргумент людей заключается в том, что синглтон жестко связан с объектом, изначально хранится в памяти, и невозможно запустить тест, не исключив его из запуска приложения.
Возможно, для людей, не понимающих жизненный цикл класса MonoBehaviour, все будет так.
Но давайте поговорим честно.
Тот факт, что наш единственный экземпляр создается в методе Awake(), не означает, что это является обязательным условием для создания синглтона.
Вы можете обернуть его инициализацию в любой другой метод и создавать его только тогда, когда он вам впервые понадобится.
А еще почему-то говорят о том, как Синглтон чудесным образом переносит сцены.
Для чего тогда используется DontDestroyOnLoad? Тайна.
Закрыть соединение .
Написав тысячи строк жутко связанного кода, я, как никто, понимаю, что такое страдать от ошибок, появляющихся в одном классе при изменении другого.
Но думаете ли вы, что Синглтон является источником этой проблемы? Мне не.
Дизайн и еще раз дизайн.
В одной из статей (извините, не могу дать ссылку, так как читал невероятно давно) говорилось, что проектированию структуры приложения нужно уделять до 80% времени, после чего дела пойдет как часы.
Я с этим абсолютно согласен.
На самом деле, я скажу вам больше, Я фанатично отношусь к модульности.
.
Продумать и создать структуру, в которой каждый модуль будет самодостаточным, расширяемым и простым — моя текущая мечта программирования.
Сегодня я посмотрел невероятно информативную презентацию об использовании Scriptable Objects. Он называется «Unite Austin 2017 — игровая архитектура со скриптуемыми объектами».
Материал будет полезен каждому Unity-разработчику.
Спикер приравнял Синглтон к природным катаклизмам, ядерной войне и рассказал, что их студия пытается создавать в играх префабы, которые были бы самодостаточными и не имели бы тесных связей.
Повторюсь, на мой взгляд, решение отличное.
Но что, если наша игра требует связей? Одним из основных примеров использования Scriptable Objects является игра Heart Stone, которая, как вы знаете, частично сделана на Unity3D. Прохладный.
Замечательный.
Удивительный.
Меня беспокоит только одно большое «НО».
Создание карт для Heart Stone можно ограничиться таблицей в Excel, где заполняем название карты, ее описание, ману, атаку и, конечно же, очки жизни.
Готовый.
А вам нужно было создать игру, в которой всё завязано на генерации.
Генерируется ландшафт, генерируются объекты, генерируются персонажи, даже генерируется то, что отвечает за генерацию.
Выкройка с одной из фабрик? Строитель? Ну, возможно.
Наш сенсей вряд ли солжет. Недостатком этих шаблонов является то, что они загружены ненужным кодом и имеют общую сложность.
Я ни в коем случае не говорю, что нужно прекратить использовать какие-либо паттерны кроме синглтона, я просто хочу призвать людей не бояться синглтонов и не создавать паттерны там, где они не нужны, что может привести к нецелесообразному усложнению архитектуры.
.
Несколько дополнений
Часто мы можем видеть решения, которые выглядят просто «не синглтонами».Разработчики извращаются любым способом.
Они создают публичную переменную для класса, перетаскивая один объект с нужным классом в инспекторе на сотни других объектов, которым нужна эта ссылка.
Вызывается в методе Start() GameObject.Find().
Но не Синглтон, отлично, правда? Связь есть, антипаттерна нет. Чудеса.
Базовый Проблема синглтона среди новых разработчиков в том, что вам не нужно много думать о структуре.
Из-за этого весь код обрастает синглтонами.
Доступ к любому методу без ссылок, монолитная архитектура.
Это все плохо, но каждый пишет код в меру своих возможностей.
Будем честны.
Программирование — это не просто деятельность, это полное изменение образа мышления.
Невозможно прочитать 700-страничную книгу, сесть и создать идеальную архитектуру.
Все приходит с опытом.
И если ваш путь начался с монолитов, это не повод отчаиваться.
Понимание того, что проблема существует – первый шаг к ее решению! Также , злоупотребление синглтонами равнозначно злоупотреблению любым другим шаблоном.
Никто не даст вам куки для создания абстрактной фабрики и 30 интерфейсов для класса, единственной целью которого является изменение фонового изображения.
Семь раз отмерь, один раз отрежь! Возможно, если комментарии будут очень насыщенными, я смогу дополнить эту статью или даже сделать 2 часть.
Надеюсь на критику моего письма.
Всем спасибо за внимание! Теги: #unity #unity3d #C++ #singleton #unity
-
Владимир Владимирович Научит Вас Стучать
19 Oct, 24 -
Извлечение Аудиоданных Из Wav-Файла В Uwp
19 Oct, 24 -
Система Частиц В Моделировании Толпы (2)
19 Oct, 24
