Шаблон Singleton

Когда мы должны использовать шаблон Singleton и почему?

Ответы

Ответ 1

http://sites.google.com/site/steveyegge2/singleton-considered-stupid

Почему Синглтон настолько привлекателен? Я буду первым, кто признается: мне тоже понравилось. Нет, поцарапать это - мне понравился Синглтон. Он почувствовал себя старым другом с того момента, как я посмотрел на него. Это было просто и красиво.

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

Вот краткое резюме...

a) Я не затронул даже десятую часть вопросов. Но я назову несколько из них.

b) Один из них - управление памятью; Синглтон в основном просто утечка памяти, если никто не будет использовать его какое-то время. Но вы не знаете, когда его освободить, потому что никто не позвонит вам и не скажет "никто не будет использовать вас какое-то время!"

Кроме того, вы не можете сказать, кто хранит ссылки на ваш экземпляр Singleton, так как вы были довольно хладны из-за его раздачи, не так ли? (Примечание: слабые ссылки Java могут помочь с этой проблемой).

c) Говоря об утечках памяти, что, если ваш Singleton имеет дескриптор некоторого ограниченного ресурса, например, базы данных или дескриптора файла? Я думаю, вы доберетесь до того, что ваша присоска будет открыта, пока ваша программа не закончится. Слава богу, программы на С++ никогда не длились дольше, чем за 10 минут до срыва, как правило, из-за нехватки ресурсов или от попыток доступа к Singleton, который кто-то освободил.

d) Другая проблема заключается в том, что дизайн Singleton синтаксически шумный; большинство языков этого не поддерживают (ну, к сожалению, Руби делает это, к сожалению, но это было, вероятно, до того, как Мац знал, что лучше), поэтому вы должны придерживаться шаблона кода не только в Синглтоне, но и во всех, кто его использует.

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

f) статические методы столь же гибки, как и гранит. Каждый раз, когда вы используете его, вы выполняете часть своей программы в бетоне. Просто убедитесь, что у вас нет застрявшей ноги, когда вы смотрите, как она затвердевает. Когда-нибудь вы будете удивлены тем, что, черт возьми, вам действительно нужна другая реализация этого класса PrintSpooler, и он должен был быть интерфейсом, factory и набором классов реализации. D'о!

Не думайте, что все. Есть много других проблем. Например, попробуйте добавить многопоточность и посмотреть, что произойдет. Хорошо, я расскажу вам, что происходит: в половине случаев вы получаете Doubleton или Tripleton, если только вы не являетесь специалистом по синхронизации, и наличие Tripleton примерно так же желательно, как наличие трех Balrogs на чаепитии. И даже если вы специалист по синхронизации и получите идиому с двойной проверкой, у вас все еще есть один Бэлрог, и они не пикник.

Но эти проблемы все угасают в незначительности по сравнению с Большим, а именно, что "шаблон" Singleton побуждает вас забыть все, что вы знаете о дизайне OO, поскольку OO сложно, а процедурный просто...

Ответ 2

Java Runnable - лучший пример Singleton Pattern. Если вы хотите добавить ограничение, которое не позволяет создавать более чем один экземпляр для определенного класса, лучше реализовать Singleton Pattern. Ключевые моменты для реализации singleton:

  • Частный конструктор
  • Статический частный экземпляр Переменная класса Singleton
  • Открытый метод getter только в первый раз инициализирует вышеперечисленную переменную и всегда возвращает тот же экземпляр класса Singleton.

    class Singleton {
    
          private static Singleton instance;
    
          private Singleton(){
          }
    
          public static Singleton getInstance(){
             if(instance=null){
                instance=new Singleton();
             }
    
             return instance;
          }
          ........
        }
    

    И для безопасности потока:      getInstance() необходимо синхронизировать.

Ответ 3

Если у вас есть ситуация, когда для координации действий по всей системе требуется один объект, вы можете использовать этот шаблон. Хорошим примером этого является Фасад, т.е. Фасады могут быть реализованы как одиночные, потому что часто требуется один объект Facade по всей системе.

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

Ответ 4

В теории: когда вам нужно ограничить экземпляр объекта одним экземпляром. На практике: никогда.

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

Если вы хотите, чтобы куча разных объектов могла ссылаться на один объект. Возможно, они хотят, чтобы все использовали один и тот же PhysicsEngineDude или что-то еще... Вы не хотите, чтобы разные объекты имели разные физические модели, когда они живут в одном мире!

Ответ 9

Если вам нужен только один экземпляр класса. Одним из лучших примеров является регистратор. Вам просто нужен экземпляр.

Ответ 10

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

Ответ 11

Как сказано, намерение шаблона singleton состоит в том, чтобы обеспечить экземпляр одного экземпляра класса.

Одноэлементный шаблон считается одним из "плохих" шаблонов в каталоге GOF pattern, поскольку синглтон приводит к связыванию кода и делает (единичного) тестирования кода. Последняя точка не на 100% истинна в (большинстве) динамических/слабо типизированных языках, потому что вы можете использовать код патча обезьян.

Посмотрим на связь: каждый фрагмент кода, который использует Singleton, напрямую связан с реализацией Singleton. Это сложно/невозможно издеваться, и поскольку Singletons часто используются для служб инфраструктуры, таких как уровень доступа к базе данных, блок, который вы хотите протестировать, связан с конкретной реализацией уровня доступа к базе данных. Но для unit test вы не хотите попасть в базу данных, вы хотите иметь некоторый уровень доступа к данным. Вы попадаете в ситуацию, когда вы спрашиваете себя, почему вы использовали шаблон singleton.

Я бы рекомендовал шаблон singleton только для "простого" программного обеспечения, но, как мы все знаем, программное обеспечение имеет тенденцию к росту. Чтобы начать простой и окончательный комплекс через несколько лет.

Ответ 12

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

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

Подробнее здесь...

http://www.dzone.com/links/r/java_ee_singleton_design_pattern_introduction.html

Ответ 13

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

  • Создание такого ресурса требует ресурсов

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

Таким образом, проектирование такого класса, как одноэлемент, имеет смысл. Для получения дополнительной информации см. шаблон дизайна singleton, объясненный с помощью примера С#.net