Как следует из названия, это самый простой шаблон проектирования среди всех остальных. Его диаграмма классов имеет только один класс, да, только класс. Но, несмотря на его простоту, его очень сложно использовать, так как нам нужно слишком много думать о будущем. Многие разработчики предлагают не использовать шаблон Singleton. Это повышает ремонтопригодность. Но в некоторых случаях это очень полезно. Давайте посмотрим, зачем нам нужен шаблон Singleton.

Потребность в одноэлементном шаблоне

Могут быть определенные сценарии, когда вам нужен только один объект класса. Некоторыми примерами являются VideoCall (который может сделать из него только один объект), файловая система, диспетчер очереди печати и т. Д.

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

Выполнение

Чтобы создать экземпляр объекта, нам нужен конструктор или конструктор по умолчанию. Что, если мы создадим приватный конструктор? Теперь вы можете создать экземпляр этого класса? Нет. Чтобы получить доступ к частному методу любого класса, нам нужен либо его объект, либо мы можем получить доступ к частному методу изнутри самого класса. Первый вариант не годится для нашего случая, поэтому мы остановились на втором. Можете ли вы получить к нему доступ в статическом методе? Да, ты можешь. Итак, мы создаем статический метод, и из него мы будем вызывать наш конструктор. Вот и все. И это наш шаблон Singleton. Давайте посмотрим на код для большей ясности:

Как вы можете видеть, мы объявили конструктор закрытым, поэтому любой может напрямую создавать экземпляр этого класса или использовать новое ключевое слово. Если вам нужен его объект, вам нужно вызвать метод getInstance(), он вернет вам уникальный объект Singleton. Поскольку мы проверяем, что uniqueInstance имеет значение null или нет. если мы запрашиваем объект в первый раз, тогда uniqueInstance будет иметь значение null, поэтому он создаст свой новый экземпляр и вернет его. Но во второй раз, uniqueIinstance не будет нулевым. Он вернет вам тот же объект.

Это приводит к тому, что клиент создает только один объект типа Singleton без каких-либо забот. Давайте посмотрим, насколько проста его диаграмма классов:

Проверить диаграмму классов

Это все только один класс. Это самый простой шаблон дизайна. У него есть одна статическая переменная, которая отвечает за хранение его уникального экземпляра, и метод getInstance() для создания только одного объекта.

Использование

  1. Используйте его, когда клиенту нужен только экземпляр класса, и он легко доступен.

Преимущества

  1. Класс Singleton имеет строгий контроль над тем, как, когда и где используется его объект.
  2. Лучше, чем глобальные переменные.
  3. Вы можете легко подклассировать его и настроить приложение с экземпляром класса, который вам нужен во время выполнения.
  4. Вы можете контролировать количество переменных, которые использует приложение.

Недостатки:

  1. Класс Singleton потерпит неудачу в случае многопоточной системы.
  2. Это нарушает принцип единой ответственности.
  3. Это тесно связанное программирование.
  4. Написание модульных тестов для класса Singleton может быть затруднено.

И с этим вы узнали концепцию, реализацию, плюсы и минусы шаблона Singleton. Теперь вы готовы выйти и использовать Singleton в своем коде.

У нас есть решение, позволяющее избавиться от первого недостатка, мы рассмотрим его позже. Если кто-то заинтересован, не стесняйтесь обращаться ко мне в Linkedin, мы можем это обсудить.

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