Это хорошее использование шаблона Singleton?

Question

Я делаю много приложений "Создай свой собственный ____".
Я делаю одноэлементный класс для хранения всех настроек, выбранных пользователем. Например: когда вы выбираете что-то зеленое, он обновляет геттер / сеттер в синглтоне, чтобы он стал зеленым. Затем, когда приложение должно знать, какой цвет был выбран, оно получает информацию от того же самого получателя / установщика.
Я использовал это, сохраняя информацию в пользовательском интерфейсе (просто проверяя, какой цвет был выбран из выпадающего списка).
После прочтения о MVC (я до сих пор не «полностью» понимаю MVC), я теперь знаю, что это совершенно неправильно, и именно поэтому я абстрагировал его в класс singleton, который содержит все это.

Теперь мне интересно, это тоже плохая идея? если да, то как мне это сделать?

Спасибо.

Answer 1

Я бы сказал, что это не совсем то, для чего предназначался паттерн Синглтон. Это очень неправильно истолкованный шаблон, и наиболее распространенная причина, по которой люди его используют, - это простой доступ, поскольку они часто статичны. Что действительно происходит, так это то, что у вас есть проблема конфигурации, которую вы пытаетесь обойти через статический синглтон, к которому легко получить доступ во всем приложении. «Правильное» использование будет при попытке контролировать доступ к действительно ограниченному ресурсу.

Если вы думаете об этом, вероятно, действительно не имеет смысла иметь только одну универсальную «конфигурацию» для приложения. Гораздо разумнее иметь несколько, но, возможно, когда-либо используется только один.

-Edit- Вместо использования Singleton, к которому можно обращаться статически, рассмотрите возможность использования Dependency Injection или Inversion of Control.

Answer 2

Синглтоны ограничивают количество экземпляров до одного. В вашем случае, почему вы решили, что у вас ДОЛЖЕН быть только один экземпляр? Что делать, если вы хотите несколько конфигураций? Несколько экземпляров, каждый из которых представляет свою конфигурацию, невозможно в вашем проекте.

Answer 3

Помните, что Singleton - это в основном глобальная переменная, и у нее все те же проблемы. Например:

• Каждый класс потенциально зависит от синглтона (и всего, от чего зависит сам синглтон). Но эта зависимость не указывается явным образом через передаваемые вами значения, поэтому ее невозможно обнаружить.
• Поскольку вы можете писать в нее из любой точки вашей программы, вы рискуете изменить ее в любое время при вызове функции. Таким образом, вы никогда не сможете полностью положиться на его ценность.

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

• Это заставит вас сократить количество классов, которые зависят от вашего объекта данных.
• Это сделает рефакторинг легче и более предсказуемым, потому что вы будете уверены, что ваш объект не изменяется за вашей спиной.

Answer 4

Я полагаю, вы говорите о чем-то вроде автомобильного конфигуратора - выберите краску, двигатель, диски и все остальное.

В этом случае я бы не использовал синглтон. Не потому что это не работает, а потому что это кажется семантически неправильным. Синглтон подразумевает, что существует только одно состояние. Но ваше приложение может иметь два окна - что-то вроде двух документов. С помощью singleton вы не можете изменять оба документа независимо, потому что они имеют общее состояние. Итак, вы видите, это действительно не должно быть синглтон.

Answer 5

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

Как открытие и чтение файла конфигурации. Вместо того, чтобы разные классы читали один и тот же файл, они проходят класс, который делает только это. Что вам нужно, это когда пользователь изменяет настройку, система должна быть уведомлена о том, что что-то было изменено.

Но это действительно зависит от языка, который вы используете. Насколько я знаю, только у java есть метод onNotify (). Но я могу ошибаться.

Answer 6

Ответ на ваш вопрос может иметь непосредственное отношение к вашей текущей среде. Например, в Java свойства времени выполнения предоставляются через System.getProperties и т. Д. Windows имеет свой реестр.

Задумывались ли вы о таких решениях, как использование контекстов для передачи состояния? Вам действительно нужны глобальные свойства? Могут ли ваши свойства быть изменены во время выполнения? Будут ли у вас несколько потоков, потенциально изменяющих одни и те же свойства? Это все, что нужно учитывать в дизайне.

Лично я обычно просто выбираю то, что кажется соглашением для среды, в которой я работаю. Из вашего последнего вопроса звучит так, как будто вы работаете с ActionScript. Для этого уже существует соглашение?

Answer 7

Я не совсем уверен, что ваш вопрос, но вот что я делаю из него.

Ваше приложение имеет пользовательский интерфейс, который позволяет пользователю выбирать набор параметров (например, раскрывающийся список с набором цветов. Одним из которых является зеленый цвет.)

Позже (например, после закрытия приложения и его перезапуска) выбранное значение необходимо снова загрузить.

Если это ваш конкретный вопрос, я не думаю, что это как-то связано с одноэлементным шаблоном как таковым. Я думаю, что вы хотите, это файл конфигурации (app.config для приложений и web.config для веб-приложений). С классом ConfiguratoinManager вы можете легко получить к ним доступ.

Answer 8

Я, будучи парнем Service Layer (хотя у меня есть собственное видение уровня сервиса), рекомендовал бы сделать IoC и перенести всю логику настройки в отдельный сервис AmbienceService или что-то). Таким образом, в вашем докладчике вы сделаете (псевдокод в стиле C #):

viewModel.HeaderColor = ServiceLocator.Resolve<AmbienceService>().HeaderColor;