Является ли это хорошим примером шаблона Singleton?

Question

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

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

Спасибо.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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