Там какие-либо жизнеспособные альтернативы к Шаблону "одиночка" GOF?
Он - среди других применений - ярлык для инициализации коллекций. Подробнее ...
16 ответов
Alex Miller в" Шаблоны я Ненависть " кавычки следующее:
, "Когда одиночный элемент походит на ответ, я нахожу, что часто более мудро:
- Создают интерфейс и реализацию по умолчанию Вашего одиночного элемента
- Конструкция единственный экземпляр Вашей реализации по умолчанию в “top” Вашей системы. Это могло бы быть в конфигурации Spring, или в коде, или определено во множестве путей в зависимости от Вашей системы.
- Передача единственный экземпляр в каждый компонент, которому нужен он (внедрение зависимости)
Что Вы имеете в виду, что мои методы должны избежать его?
Для "избегания" его, который подразумевает, что существует много ситуаций, что я сталкиваюсь, в котором шаблон "одиночка" естественно подходящий вариант, и следовательно что я должен принять некоторые меры для обезвреживания этих ситуаций.
, Но нет. Я не должен избегать шаблона "одиночка". Это просто не возникает.
Не запрограммировав в сильно объектно-ориентированной среде (например, Java), я не нахожусь полностью на запутанности обсуждения. Но я реализовал одиночный элемент в PHP 4. Я сделал это как способ создать обработчик баз данных 'черного ящика', который автоматически инициализировал и не должен был быть передан вверх и вниз по вызовам функции в неполной и несколько поврежденной платформе.
прочитавший некоторые ссылки шаблонов "одиночка", я не абсолютно уверен, что реализовал бы его вполне тем же способом снова. То, что было действительно необходимо, было несколькими объектами с совместно используемой памятью (например, фактический дескриптор базы данных), и это в значительной степени, во что превратился мой вызов.
Как большинство шаблонов и алгоритмов, с помощью одиночного элемента 'просто, потому что это прохладно', Неправильный поступок. Мне было нужно действительно вызов 'черного ящика', который, оказалось, много походил на одиночный элемент. И IMO это - способ заняться вопросом: знайте о шаблоне, но также и взгляде на, он - более широкий объем и на то, какой уровень это - экземпляр, должно быть уникальным.
Я использую одиночный элемент главным образом в качестве "контейнера методов" без состояния вообще. Если я должен совместно использовать эти методы со многими классами и хотеть избежать нагрузки инстанцирования и инициализации, я создаю контекст/сессию и инициализирую все классы там; все, что обращается к сессии, имеет также доступ к "одиночному элементу", таким образом, содержавшему.
Я думаю, что лучшее место для управления на основе политик одиночным элементом на уровне дизайна класса. На данном этапе необходимо быть в состоянии планировать взаимодействия между классами и видеть, требует ли что-то абсолютно, определенно, чтобы только 1 экземпляр этого класса был когда-либо существующим в любое время срока действия приложений.
, Если это так, тогда у Вас есть одиночный элемент. Если Вы добавляете одиночные элементы как удобство во время кодирования тогда, необходимо действительно пересматривать дизайн и также прекращать кодировать, сказали одиночные элементы:)
И да, 'полиция' является словом, которое я имел в виду здесь, а не 'избежать'. Одиночный элемент не что-то, чтобы избежаться (таким же образом, что goto и глобальные переменные не что-то, чтобы избежаться). Вместо этого необходимо контролировать, это - использование и гарантируя, что это - лучший метод для получения то, что Вы хотите сделанный эффективно.
Лично для меня Р ° намного более разумный способ реализовать что-то, что ведет себя как одиночный элемент, должно использовать полностью статический класс (статические участники, статические методы, статические свойства). Большую часть времени я реализую его таким образом (я не могу думать ни о каких различиях в поведении с пользовательской точки зрения)
На самом деле при разработке права с нуля при уходе от Singeltons Вам не, вероятно, придется работать вокруг не использования Одиночных элементов при помощи статических переменных. При использовании статических переменных Вы также создаете Singleton более или менее, единственная разница - Вы, создают различные экземпляры объектов, однако внутренне они все ведут себя, как будто они использовали Singleton.
можно ли, возможно, дать подробный пример, где Вы используете Singleton или где Singleton в настоящее время используется, и Вы стараетесь не использовать ее? Это могло помочь людям найти более необычное решение, как ситуация могла быть обработана без Singleton вообще.
BTW, у меня лично нет проблем с Одиночными элементами, и я не могу понять проблемы, которые другие люди имеют относительно Одиночных элементов. Я ничего не вижу плохо о них. Таким образом, если Вы не оскорбляете их. Каждой полезной техникой можно злоупотребить и будучи злоупотребленным, она приведет к отрицательным результатам. Другая техника, которая обычно неправильно используется, является наследованием. Тем не менее никто не сказал бы, что наследование - что-то плохо просто, потому что некоторые люди ужасно злоупотребляют им.
Используйте простой объект и объект фабрики. Фабрика ответственна за управление на основе политик экземпляром, и простой объект детализирует только с конфигурационной информацией (это содержит, например), и поведение.
Если Ваша проблема - то, что Вы хотите сохранить состояние, Вы хотите класс MumbleManager. Прежде чем Вы начнете работать с системой, Ваш клиент создает MumbleManager, где Бормотание является названием системы. Состояние сохраняется через это. Возможностями является Ваш MumbleManager, будет содержать набор свойств, который содержит Ваше состояние.
Этот тип стиля чувствует себя очень подобным C и не очень объектный как - Вы найдете, что возражает, что определяют Вашу систему, будет все иметь ссылку на тот же MumbleManager.
При использовании Singleton для представления единственного объекта данных, Вы могли бы вместо этого раздать объект данных как параметр метода.
(хотя, я обсудил бы это, неправильный способ использовать Singleton во-первых)
одиночный элемент шаблон существует, потому что существуют ситуации, когда отдельный объект необходим для предоставления ряда услуг .
, Даже если дело обстоит так я все еще рассматриваю подход создания одиночных элементов при помощи глобальное статическое поле/свойство , представляющее экземпляр, несоответствующий. Это является несоответствующим, потому что это создает зависимость в коде между статическим полем и объектом не, услуги, которые предоставляет объект.
Так вместо классика, шаблона "одиночка", я рекомендую использовать сервис 'как' шаблон с [1 113] обслуживаемые контейнеры , где вместо того, чтобы использовать Ваш одиночный элемент через статическое поле, Вы получаете ссылку на него через метод, запрашивающий тип требуемого сервиса.
*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.
вместо единственного, глобального
*pseudocode* singletonType.Instance
Таким образом, когда Вы захотите изменить тип объекта от одиночного элемента до чего-то еще, Вы будете иметь и бездельничанье, делающее его. Также как и дополнительное преимущество Вы не должны раздавать, выделяют экземпляров объектов каждому методу.
Также видят Инверсия Управления , идея состоит в том, что путем представления одиночных элементов непосредственно потребителю, Вы создаете зависимость между потребителем и экземпляром объекта, не объектными услугами, предоставленными объектом.
Мое мнение к [1 115], скрываются использование шаблона "одиночка", когда это возможно, потому что не всегда возможно избежать его, или желательный.
Вам не придется стараться изо всех сил избегать любого шаблона. Использование шаблона является или проектным решением или естественным соответствием (оно просто встает на свое место). При разработке системы у Вас есть выбор или использовать шаблон или не использовать шаблон. Однако Вы не должны стараться изо всех сил избегать чего-либо, что является в конечном счете проектным решением.
я не избегаю Шаблона "одиночка". Или это является соответствующим, и я использую его, или это не является соответствующим, и я не использую его. Я полагаю, что это настолько просто.
уместность (или отсутствие этого) Singleton зависит от ситуации. Это - проектное решение, которое должно быть сделано, и последствия того решения должны быть поняты (и зарегистрированы).
Spring или любой другой Контейнер МОК делают довольно хорошее задание в этом. Так как классы создаются и управляются вне самого приложения, контейнер может сделать простые одиночные элементы классов и ввести их при необходимости.
Для понимания надлежащего пути к Одиночным элементам обходного решения необходимо понять что не так с Одиночными элементами (и глобальное состояние в целом):
Одиночные элементы скрывают зависимости.
, Почему это важно?
, поскольку при сокрытии зависимостей Вы склонны терять след объема связи.
Вы могли бы утверждать, что
void purchaseLaptop(String creditCardNumber, int price){
CreditCardProcessor.getInstance().debit(creditCardNumber, amount);
Cart.getInstance().addLaptop();
}
более просто, чем
void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart,
String creditCardNumber, int price){
creditCardProcessor.debit(creditCardNumber, amount);
cart.addLaptop();
}
, но по крайней мере второй API проясняет точно, каковы сотрудники метода.
, Таким образом, путь к Одиночным элементам обходного решения не состоит в том, чтобы использовать статические переменные или сервисные локаторы, но изменить Singleton-классы в экземпляры, которые инстанцируют в объеме, где они имеют смысл и введенный в компоненты и методы, для которых нужны они. Вы могли бы использовать платформу МОК для обработки этого, или Вы могли бы сделать это вручную, но важная вещь состоит в том, чтобы избавиться от Вашего глобального состояния и сделать зависимости и сотрудничество явными.
Самое прекрасное решение, которое я имею, столкнулось, использует шаблон "фабрика" для построения экземпляров классов. Используя шаблон, Вы можете гарантировать , что существует только один экземпляр класса, который является общим для объекты, которые используют его.
я, хотя это было бы сложно для управления, но после чтения этого сообщения в блоге , "Где Имеют Все Одиночные элементы Уведенный?" , это кажется настолько естественным. И как в стороне, это помогает много с изоляцией Ваших модульных тестов.
, Таким образом, что необходимо сделать? Каждый раз, когда объект зависит от другого, он получит экземпляр его только через его конструктора (никакое новое ключевое слово в Вашем классе).
class NeedyClass {
private ExSingletonClass exSingleton;
public NeedyClass(ExSingletonClass exSingleton){
this.exSingleton = exSingleton;
}
// Here goes some code that uses the exSingleton object
}
И затем, фабрика.
class FactoryOfNeedy {
private ExSingletonClass exSingleton;
public FactoryOfNeedy() {
this.exSingleton = new ExSingletonClass();
}
public NeedyClass buildNeedy() {
return new NeedyClass(this.exSingleton);
}
}
, Поскольку Вы инстанцируете своей фабрики только однажды, будет единственное инстанцирование экс-одиночного элемента. Каждый раз, когда Вы называете buildNeedy, новый экземпляр NeedyClass будет связан экс-одиночным элементом.
я надеюсь, что это помогает. Укажите на любые ошибки.
Моностат (описанный в книге Роберта К. Мартина «Гибкая разработка программного обеспечения») является альтернативой синглтону. В этом шаблоне все данные класса статичны, но геттеры / сеттеры нестатичны.
Например:
public class MonoStateExample
{
private static int x;
public int getX()
{
return x;
}
public void setX(int xVal)
{
x = xVal;
}
}
public class MonoDriver
{
public static void main(String args[])
{
MonoStateExample m1 = new MonoStateExample();
m1.setX(10);
MonoStateExample m2 = new MonoStateExample();
if(m1.getX() == m2.getX())
{
//singleton behavior
}
}
}
Моностат ведет себя так же, как синглтон, но делает это таким образом, что программист не обязательно осознает тот факт, что используется синглтон.