Каково некоторое определенное законное использование для одиночных элементов? [дубликат]

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

Для разделения настроек на различные файлы можно использовать initsplit.el . Кроме того, вики имеет страницу на модульном макете .emacs .

Эти ярлыки я использую чаще всего:

  Shift + Strg + O : Organize imports

  Shift + Alt + R  : Delete current element.

  Ctrl + D         : Delete current/marked line.

  Ctrl + Space     : Content assist.

  Ctrl + 1         : Context-sensitive proposals.

  Ctrl + 7         : (Un)comment current/marked line.

  Ctrl + M         : Max./minimize current tab.

  Ctrl + J         : Incrementel search.

  F3               : Jump to the declaration of the current element.

* Define own shortcuts

  - Window/Preferences/General/Keys

  Alt + C          : SVN Commit.

  Alt + U          : SVN Update.

  Shift + Ctrl + N : "New Class" Dialog.

* Templates

  - Window/Preferences/Java/Editor/Templates

  syso + Ctrl + Space : System.out.println();

  main + Ctrl + Space : public static void main(String[] args) {

                        }

Расширяю мой комментарий...

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

1. Глобальная переменная является глобальной переменной.

   Как только вы используете

   void f () { X * x = X:: getInstance (); ... }

   вместо void f (X *) ваш заказ на блюдо спагетти принят.

2. Синглтоны размножаются и любят зависеть друг от друга. SessionManager использует EventManager , который использует LogManager . Кто-то хочет, чтобы в файлах журнала упоминалось имя текущего пользователя. Сопровождающий LogManager добавляет SessionManager:: getInstance () - > getUser () - > getName (); , все розы, пока LoginManager , который также использует LogManager , не захочет зарегистрировать ошибку входа в систему.

3. Синглтоны ингибируют тестируемость.

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

Как вы можете догадаться, мой ответ на когда глобальные переменные хороши? - «никогда». Что такое ваш ?

• Регистрация.

• Найти локализованные строковые ресурсы E.G. Strings.get («подтвердить_Делет») .

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

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

Моя ситуация состояла в том, что у меня была API, которая построила объекты Singleton для функций управления управлением, таким как безопасность, конфигурация и т. Д. API использовал EntityFramework, а также вытащил в плагинах (с использованием MEF). Поскольку построение этих классов не всегда было выполнено моим кодом (особенно для EF-объектов), не всегда было возможно ввести их в объекты Biz элегантно. Поэтому я использовал Singletons, которые могут быть доступны в любом месте в рамках проекта субъекта Tot Heir Case.

Они хороши для предметов, которые вы хотите рассматривать как уникальные ресурсы.

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

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

Вы можете использовать urllib2 для выполнения HTTP-запросов, и тогда у вас будет веб-содержимое.

Вы можете получить его так:

import urllib2
response = urllib2.urlopen('http://example.com')
html = response.read()

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

В частности, здесь - это их учебное пособие по разбору HTML-документа.

Удачи!

Другой, не столь сложный, метод может состоять во времени одной итерации и позволить потоку спать в течение (x * t) миллисекунд до следующей итерации, где t - миллисекундное время для одной итерации, а x - выбранная доля времени сна (между 0 и 1).

• Когда ваш домен указывает, что существует только один уникальный экземпляр того, что вы моделируете

Я по-прежнему считаю, что одиночки следует избегать (по крайней мере в Java).

Есть две разные вещи, которые следует учитывать: концепция и механизм для применения Singleton образца.

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

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

Если бы концепцию Синглтонов можно было отделить от бедных механизмов, они не были бы такими злыми. Одним из примеров является область @ Singleton , доступная в Guice. В контексте Guice он гарантирует один экземпляр, но не достигает этого с помощью злого частного конструктора/глобального механизма точки доступа.

Подозреваемые насущевые для эмуляторов X86 будут BOCHS и QEMU .

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

Создание последовательности случайных чисел - случайный генератор должен быть уникальным, не созданным для каждого использования. Можно захотеть реализовать это как уровень нити Singleton; Тем не менее, синглтон для всего процесса все еще уместен в этом случае.

Master Server принимает запросы от клиентов и передает эти запросы в подчиненный процесс. Подчиненный процесс может использовать Singleton для связи с главным сервером.

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

Я стараюсь не полагаться на Singleton, однако я предпочитаю раздумчивость, чтобы не использовать Singleton. Таким образом, я часто использую синглтон в сочетании с узором прототипа, которые позволяют зарегистрировать прототипы при библиотеке нагрузки (строительство глобальных объектов).

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

Использование Singleton для карты позволит мне иметь полностью отделенный код. Ни одна библиотека зависит от моей сервисной библиотеки, ни одна строка кода вне моей сервисной библиотеки не будет поручено зарегистрировать его услугу. На самом деле, так, чтобы я мог решить, какие сервисы встроен просто, просто изменив мою команду «ссылку» в Compile-Time: если я не связываю с библиотекой, его служба не встроена.

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