Существует много толчков на использование синглетонов, потому что они часто злоупотребляют. Ленивые кодеры либо (1) не помещают достаточную функциональность в синглтон, что приводит к распространению логики в других объектах, таких как спагетти, либо (2) они вкладывают в большую функциональность, так что синглтон становится всей программой. Ленивые программисты часто используют синглтоны вместо проверки данных, тестирования объектов и отслеживания объектов. Людям надоедает пытаться распутать и поддерживать ленивое использование синглтона, поэтому они пытаются подавить использование синглетонов.
Я полностью понимаю импульс и сам ритуально предостерегаю от злоупотребления синглтоном.
Однако модель данных - это одно из немногих законных применений для синглтона. Это особенно актуально для небольших приложений, таких как те, которые работают на мобильных устройствах. В конце концов, вы либо будете использовать синглтон для своей модели данных, либо прикрепите его к синглтону.
Например, предположим, что вы решили разместить свой объект не-одноэлементной модели данных в делегате приложения. Итак, вы сделали это: dataModel -> appDelegate -> application (singleton). Чтобы получить к нему доступ, вы должны позвонить:
[[[UIApplication sharedApplication (a singleton)] delegate] theDataModelObj];
Даже если вы передадите его как токен от объекта к объекту, вам все равно придется начинать dataModel obj как свойство одиночного объекта.
Когда объект действительно должен соответствовать шаблону «Горец» («Может быть только один!»), Тогда лучшим вариантом является синглтон. В дополнение к объекту приложения, у вас есть пользовательские настройки по умолчанию как одиночный, а также файловый менеджер. Очевидно, что во всех трех случаях вам нужен один и только один экземпляр для всего приложения. Например, если у вас было несколько объектов по умолчанию для пользователя, ваше приложение было бы крушение поезда, пытаясь отследить все настройки предпочтений. Если у вас более одного файлового менеджера, файловые операции могут накладываться друг на друга.
Правильно спроектированная модель пользовательских данных - это просто увеличенная версия пользовательских настроек по умолчанию. Это должен быть единственный объект, который напрямую манипулирует данными пользователя. Ни у какого другого объекта в приложении не должно быть этой задачи. Это делает шаблон проектирования Singleton лучшим в данном конкретном случае.
Синглтоны - очень мощный инструмент, но, как и в случае с физическими инструментами, чем больше они дают вам энергии, тем больше у них возможностей для того, чтобы отрезать вам голову, если вы будете их небрежно использовать. По этой причине синглтон редко должен быть вашим первым выбором. Обычно есть лучшие модели дизайна для использования.
Однако, когда вам действительно нужен синглтон, вы не должны уклоняться от его использования только потому, что лень других сделала его плохим представителем.
Знание того, когда и когда не следует использовать мощный и опасный инструмент, является частью интуиции программистов, которую вы разрабатываете с опытом. Вы не можете идти по формуле. Это один из тех факторов, который делает хорошее программирование искусством, а программист - мастером.