На шаблонах проектирования: когда я должен использовать синглтон? [закрыто]

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

Пример с кодом, возможно.

Здесь, ConcreteRegistry является одиночным элементом в игре в покер, которая предоставляет поведениям полностью доступ дерева пакета некоторые, базовые интерфейсы игры (т.е. фасады для модели, представления, контроллера, среды, и т.д.):

http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs40.html

Ed.

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

В этом случае Вы берете зависимость от инфраструктуры, чтобы упростить пользование библиотекой и избежать ненужной сложности.

Как все сказали, совместно используемый ресурс - конкретно что-то, что не может обработать параллельный доступ.

Одним определенным примером, который я видел, является Индексный Писатель Поиска Lucene.

Управление подключением (или пул соединений) к базе данных.

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

Одиночные элементы только для чтения, хранящие некоторое глобальное состояние (пользовательский язык, помогите filepath, путь приложения) разумны. Остерегайтесь использования одиночных элементов для управления бизнес-логикой - единственный, почти всегда заканчивает тем, что был [приблизительно 110]

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

Или соединение с базой данных или файловый менеджер и т.д.

Я использую его для объекта, инкапсулирующего параметры командной строки при контакте со сменными модулями. Основная программа не знает то, что параметры командной строки для модулей, которые загружаются (и не всегда даже знает, какие модули загружаются). например, основные загрузки A, которому не нужны никакие параметры самостоятельно (итак, почему это должно взять дополнительный указатель / ссылка / безотносительно, я не уверен - похожи на загрязнение), затем загружает модули X, Y, и Z. Два из них, говорят X и Z, потребность (или примите), параметры, таким образом, они перезванивают к одиночному элементу командной строки для сообщения его, что параметры принять, и во времени выполнения они перезванивают, чтобы узнать, определил ли пользователь на самом деле какого-либо из них.

Во многих отношениях, одиночный элемент для обработки параметров CGI работал бы так же, если бы Вы только используете один процесс на запрос (другие mod_* методы не делают этого, таким образом, это было бы плохо там - таким образом аргумент, который говорит, что Вы не должны использовать одиночные элементы в mod_cgi мире в случае, если Вы портируете на mod_perl или безотносительно мира).

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

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

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

Также думают о ситуации, где у Вас есть приложение со многими окнами/потоками/и т.д., но которому нужна единственная точка коммуникации. Я когда-то использовал для управления заданиями, которые я хотел, чтобы мое приложение запустило. Одиночный элемент был ответственен за сериализацию заданий и отображение их состояния к любой другой части программы, которой было интересно. В этом виде сценария можно посмотреть на одиночный элемент, как являющийся видом подобных выполнение класса "сервера" в приложении... HTH

Кандидат Singleton должен удовлетворить три требования:

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

, Если Ваша предложенная Singleton имеет только один или два из этих требований, модернизация является почти всегда корректной опцией.

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

А простой регистратор является самым очевидным примером возможно допустимой Singleton, но это может измениться с более сложными схемами входа.

Практический пример одиночного элемента может быть найден в Тест:: Разработчик , класс, который спины примерно каждый современный модуль тестирования Perl. Тест:: одноэлементные хранилища Разработчика и брокеры состояние и история тестового процесса (исторические результаты испытаний, считает количество тестового прогона), а также вещи как то, куда тестовый вывод идет. Они все необходимы, чтобы скоординировать несколько модулей тестирования, записанных различными авторами, сотрудничать в единственном сценарии тестирования.

история Теста:: одиночный элемент Разработчика является образовательным. Вызов new() всегда дает Вам тот же объект. Во-первых, все данные хранились как переменные класса ни с чем в самом объекте. Это работало, пока я не хотел протестировать Тест:: Разработчик с собой. Тогда мне были нужны два Теста:: Разработчик возражает, одна установка как макет, чтобы получить и протестировать его поведение и произвести, и один, чтобы быть реальным тестовым объектом. В том Тесте точки:: Разработчик был пересмотрен в реальный объект. Одноэлементный объект хранился, поскольку данные класса, и new() будут всегда возвращать его. create() был добавлен, чтобы сделать новый объект и позволить тестировать.

В настоящее время, пользователи желают изменить некоторые поведения Теста:: Разработчик в их собственном модуле, но оставляют других в покое, в то время как тестовая история остается вместе через все модули тестирования. Что происходит, теперь монолитный Тест:: объект Разработчика разламывается на мелкие кусочки (история, производится, формат...) с Тестом:: экземпляр Разработчика, собирающий их вместе. Теперь Тест:: Разработчик больше не должен быть одиночным элементом. Ее компоненты, как история, могут быть. Это продвигает негибкую необходимость одиночного элемента вниз уровень. Это дает больше гибкости пользователю к частям смешивания и подгонки. Меньшие одноэлементные объекты могут теперь просто хранить данные с их содержанием объектов, решающих, как использовать его. Это даже позволяет нетест:: класс Разработчика для манипулирования при помощи Теста:: история Разработчика и выходные одиночные элементы.

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

1 - Комментарий к первому ответу:

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

2 - Я стараюсь не создавать синглтон вручную. Я просто создаю простой объект с конструкторами, которые позволяют мне вставлять соавторов в объект. Если бы мне понадобился синглтон, я бы использовал структуру определения зависимостей (Spring.NET, Unity для .NET, Spring для Java) или что-то другое.

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

Вы можете использовать Singleton при внедрении шаблона состояния (в порядке, показанном в книге GOF). Это потому, что бетонные государственные классы не имеют своего собственного состояния и выполняют свои действия с точки зрения контекстно-класса.

Вы также можете сделать абстрактный завод Singleton.