почему существуют классы java singleton? Когда вам нужно использовать один

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

Зачем использовать синглтоны?

Вы можете погуглить "синглтон", чтобы найти самые разные причины. Из JavaWorld:

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

Зачем использовать синглтон вместо класса со всеми статическими методами?

Несколько причин

1. Вы можете использовать наследование
2. Вы можете использовать интерфейсы
3. Это упрощает модульное тестирование самого одноэлементного класса.
4. Это позволяет проводить модульное тестирование кода, зависящего от синглтона.

Для # 3, если ваш синглтон был пулом соединений с базой данных, вы хотите убедиться, что ваше приложение имеет только один экземпляр, но выполнить модульное тестирование самого пула соединений с базой данных, не затрагивая базу данных (возможно, используя конструктор области пакета или статический метод создания):

public class DatabaseConnectionPool {
  private static class SingletonHolder {
    public static DatabaseConnectionPool instance = new DatabaseConnectionPool(
        new MySqlStatementSupplier());
  }

  private final Supplier<Statement> statementSupplier;

  private DatabaseConnectionPool(Supplier<Statement> statementSupplier) {
    this.statementSupplier = statementSupplier;
  }

  /* Visibile for testing */
  static DatabaseConnectionPool createInstanceForTest(Supplier<Statement> s) {
    return new DatabaseConnectionPool(s);
  }

  public static DatabaseConnectionPool getInstance() {
    return SingletonHolder.instance;
  }

  // more code here
}

(обратите внимание на использование инициализации по запросу держателя шаблон)

Затем вы можете провести тестирование DatabaseConnectionPool, используя метод createInstanceForTest в области пакета.

Обратите внимание, однако, что наличие статического getInstance() метода может вызвать «статическое цепляние», когда код, зависящий от вашего синглтона, не может быть протестирован на единицу. Статические синглтоны часто не считаются хорошей практикой из-за этого (см. это сообщение в блоге)

Вместо этого вы можете использовать структуру внедрения зависимостей, такую ​​как Spring или Guice, чтобы гарантировать, что ваш класс имеет только один экземпляр в производственной среде, при этом позволяя тестировать код, использующий этот класс. Поскольку методы в синглтоне не статичны, вы можете использовать фреймворк для имитации, например JMock, для имитации своего синглтона в тестах.

Класс только со статическими методами (и частным конструктором) - это вариант, в котором нет никакого экземпляра (0 экземпляров).

Синглтон - это класс, для которого существует ровно 1 экземпляр.

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

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

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

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

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

Например, представьте, что у вас есть синглтон поставщика соединений, который создает соединения с БД.

public class DBConnectionProvider implements ConnectionProvider {}

Если бы это был класс со статическими методами, вы не могли бы внедрить зависимость, например:

public void doSomeDatabaseAction(ConnectionProvider cp) {
   cp.createConnection().execute("DROP blah;");
}

Это должно быть

public void doSomeDatabaseAction() {
   DBConnectionProvider.createConnection().execute("DROP blah;");
}

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

Используйте шаблон singleton для инкапсуляции ресурса, который должен создаваться (инициализироваться) только один раз для каждого приложения. Обычно вы делаете это для ресурсов, которые управляют доступом к общему объекту, например к базе данных. Синглтон может контролировать количество одновременных потоков, которые могут получить доступ к этому общему ресурсу. т.е. поскольку существует единый пул соединений с базой данных, он может контролировать, сколько соединений с базой данных передается тем потокам, которым они нужны. Регистратор - другой пример, посредством которого регистратор гарантирует, что доступ к общему ресурсу (внешнему файлу) может управляться соответствующим образом. Часто синглтоны также используются для загрузки ресурсов, создание которых является дорогостоящим (медленным).

Обычно синглтон создается так, синхронизируясь с getInstance:

public class Singleton {

    private static Singleton instance;

    private Singleton(){
         // create resource here
    }

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }

        return instance;
    }
}

Но так же справедливо и создать его так,

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton(){
        // create resource here
    }

    public static Singleton getInstance() {
        return instance;
    }
}

Оба метода создадут единственный экземпляр загрузчика классов PER.

Синглтон имеет преимущество перед классом со статическими переменными и методами: это экземпляр объекта, который может наследовать от класса (пример: приложение с одним основным JFrame) и расширять один или несколько интерфейсов (и, таким образом, рассматриваться как любой другой объект, реализующий эти интерфейсы).

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

На мой взгляд, статические классы, используемые вместо синглтонов, еще хуже. Статические классы следует в основном использовать для группировки связанных функций, не имеющих общего ресурса. java.util.Collections - хороший пример. Это просто набор функций, не привязанных ни к какому объекту.

С другой стороны, синглтоны - это настоящие объекты. В идеале синглтон должен быть реализован без учета шаблона синглтона. Это позволит вам легко переключиться на использование нескольких экземпляров, если вам это вдруг понадобится. Например, у вас может быть только одно соединение с базой данных, но тогда вам придется работать с другой, совершенно не связанной базой данных одновременно. Вы просто превращаете свой синглтон в «даблтон» или «триплет» или что-то еще. Если вам нужно, вы также можете сделать его конструктор общедоступным, что позволит создавать столько экземпляров, сколько захотите. Все это не так просто реализовать с помощью статических классов.

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

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

Когда вам нужно его использовать? Есть много объектов, которые нам нужен только один из: пулы потоков, кеши, диалоговые окна, объекты, которые обрабатывают предпочтения и параметры реестра, объекты, используемые для ведения журнала, и объекты, которые действуют в качестве драйверов устройств для таких устройств, как принтеры и графические карты. Для многих из этих типов объектов, если бы нам пришлось исследовать более одного, мы бы столкнулись со всевозможными проблемами, такими как некорректное поведение программы или чрезмерное использование ресурсов.

Что касается использования синхронизации, это определенно дорого, и единственное время, когда актуальна синхронизация, это в первый раз или в уникальном экземпляре, когда-то созданном, у нас больше нет необходимости синхронизировать снова. После первого раза синхронизация не требует дополнительных затрат :(

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

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

Они также используются с другими узорами. См. Можно ли создать наблюдаемый класс как синглтон ?