У меня есть другая перспектива ответить на это.
При работе на разных уровнях, например, в приложении MVC, контроллеру нужны службы для вызова бизнес-операций. В таких сценариях контейнер инжекции зависимостей может использоваться для инициализации служб, чтобы исключить исключение NullReferenceException. Это означает, что вам не нужно беспокоиться о проверке нулевого значения и просто вызвать службы с контроллера, как будто они всегда будут доступны (и инициализированы) как одиночный или прототип.
public class MyController
{
private ServiceA serviceA;
private ServiceB serviceB;
public MyController(ServiceA serviceA, ServiceB serviceB)
{
this.serviceA = serviceA;
this.serviceB = serviceB;
}
public void MyMethod()
{
// We don't need to check null because the dependency injection container
// injects it, provided you took care of bootstrapping it.
var someObject = serviceA.DoThis();
}
}
В первом подходе ваш синглтон будет создан после загрузки класса Singleton
. В другом случае он будет создан после вызова метода getInstance()
. Singleton
класс может иметь много причин для загрузки, прежде чем вы назовете getInstance
. Таким образом, вы, скорее всего, инициализируете его намного раньше, когда вы его используете, и это побеждает цель ленивой инициализации. Если вам нужна ленивая инициализация, это отдельная история.
Простой шаблон объявления конструирует singleton, когда загружается класс Singleton. Идиома инициализации по запросу конструирует синглтон при вызове Singeton.getInstance (), то есть при загрузке класса SingetonHolder.
Таким образом, это те же, за исключением времени; второй вариант позволяет отложить инициализацию. Когда выбрать тот или иной, зависит (помимо всего прочего) от того, какую работу вы выполняете в конструкторе Singleton. Если это много, вы можете увидеть улучшенное время запуска приложения с инициализацией по требованию.
Тем не менее, мой совет - стараться не делать слишком много, чтобы простейший шаблон работал на вас.
-dg
Ну, что я могу сказать. Этим статьям 7-9 лет.
Теперь у нас есть> Java 1.5, где у нас есть полномочия перечисления enum
. Согласно «Josh Block» Лучший способ написать одноэлемент - написать одноэлементное перечисление
public enum MySingleton{
Singleton;
// rest of the implementation.
// ....
}
. Но для вашего вопроса, я думаю, нет никакой проблемы в использовании любой из реализаций. Я предпочитаю первый вариант, потому что его простой, простой для понимания.
Но следите за отверстиями в петле, чтобы мы могли одновременно создавать больше объектов этого класса в одной JVM, сериализуя и десериализовать объект или сделать клон объекта.
Также сделать класс окончательным, потому что мы можем нарушить Singleton, расширив класс.