Альтернативы Singleton, когда требуется глобальный доступ - PullRequest
Новая
       30

Альтернативы Singleton, когда требуется глобальный доступ

2 голосов
/ 01 сентября 2011

Последние пару часов я читал о шаблоне синглтона и почему бы не использовать его, в том числе эти действительно хорошие сайты:

Я думаю, многие из вас уже знают это.

Глядя на мой код после прочтения этого, я определенно являюсь одним из, возможно, 95% программистов, которые неправильно поняли и неправильно использовали шаблон синглтона.
В некоторых случаях я могу четко удалить шаблон, но в некоторых случаях я не уверен, что делать:

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

А как насчет других классов, которые не соответствуют этим критериям, но требуются для многих классов?

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

Я прочитал несколько других SO вопросов, таких как «Одиночки: хороший дизайн или костыль?» , и все они указали, почему не рекомендуется использовать синглтоны.
Я понимаю причины этого, но у меня все еще есть один главный вопрос:

Как мне спроектировать класс, которому нужен один экземпляр, доступный из любого места, если не использовать шаблон Singleton?

Возможные варианты:

  1. Вместо этого используйте статический класс (хотя я не вижу, как это было бы лучше, рассматривая ООП и модульное тестирование).
  2. Создайте его в ApplicationFactory и выполните внедрение зависимостей для каждого отдельного класса, который в этом нуждается (имейте в виду, что в некоторых случаях это 200+).
  3. В любом случае используйте синглтон, так как глобальный бонус доступа перевешивает недостатки для этого случая.
  4. Что-то совершенно другое.

Ответы [ 2 ]

2 голосов
/ 01 сентября 2011

Это будет зависеть от того, что именно вы подразумеваете под объектом настроек.

Все 200 классов нуждаются во всех настройках;если нет, то почему они имеют доступ к неиспользуемым настройкам?Откуда поступают настройки и есть ли веская причина, по которой каждый класс не может загружать свои настройки как и когда это необходимо?

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

РЕДАКТИРОВАТЬ: Я не знаю ваши ограничения, но я не буду беспокоиться о множественном доступе из файла, пока не будет показано, что это проблема.Я бы разбил конфигурацию на разные файлы для разных классов / групп классов или, предпочтительно, использовал бы БД вместо файлов с разными таблицами, предоставляющими данные для каждого класса.

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

PS: Если другие варианты не подходят, я бы использовал синглтон ... вы хотите, чтобы данные были глобально доступны, вы не желаете использовать внедрение зависимостей, вы хотите, чтобы файл читался только один раз;Вы ограничили свои возможности, и синглтон не так уж и плох.

2 голосов
/ 01 сентября 2011

Разве это уже не обсуждалось широко и исчерпывающе?

Нет неправильного использования шаблона.Если ваше программное обеспечение работает должным образом (включая удобство сопровождения и тестируемость), вы правы с помощью синглетонов.

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

  • вы вводите глобальную переменную
  • вы не можете построить подкласс
  • вы не можете сбросить экземпляр

Если все это не является проблемойдля вас: используйте синглтоны повсюду.Обсуждение паттерна носит академический характер и носит потрясающий характер.

И - чтобы ответить на ваш вопрос - ознакомьтесь с темой моностат против синглтона: Моностат против синглтона

...