Давайте рассмотрим плюсы и минусы шаблона проектирования Singleton

1656652816 davajte rassmotrim plyusy i minusy shablona proektirovaniya singleton

от Navdeep Singh

VydaRLmC3LSqibXW25Vx41-tO9aRBis6Jpm8

Паттерны проектирования — это концептуальные инструменты для решения сложных проблем программного обеспечения. Эти шаблоны являются простыми и элегантными решениями, которые развивались с течением времени и, возможно, стали общепризнанными как лучший способ решения проблем дизайна. — Я в своей электронной книге Реактивное программирование с помощью Swift 4

Шаблон проектирования Singleton

Шаблон Singleton инкапсулирует общий ресурс в одном уникальном экземпляре класса. Этот экземпляр управляет доступом к информации о состоянии ресурсов и хранилищах. Метод класса предоставляет ссылку на этот экземпляр, поэтому нет необходимости передавать ссылку. Любой объект, имеющий доступ к заголовку класса Singleton, может использовать Singleton.

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

Одним из примеров Cocoa Touch является физическое устройство, на котором работает iOS. Для программы выполняется только один iPhone или iPad с одним аккумулятором и экраном. UIDevice здесь является классом Singleton, поскольку он предоставляет один канал для взаимодействия с основными функциями. В случае, если уникальный ресурс имеет доступную для записи конфигурацию, такое несоответствие может привести к таким проблемам, как состояние гонки и взаимоблокировки. Поскольку они уникальны, Синглтоны действуют как элемент управления, обеспечивая упорядоченный доступ к общему ресурсу.

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

Реализация

Реализация шаблона Singleton обычно создает один объект с помощью фабричного метода, и этот экземпляр/объект в большинстве случаев называется общим экземпляром. Поскольку доступ к экземпляру передается через метод класса, необходимость в создании объекта отпадает. Давайте рассмотрим реализацию Singleton в коде.

Для этого примера мы использовали инструмент командной строки Xcode шаблон для создания проекта и названия его Singleton. Наш класс Singleton называется SingletonObjectкоторый мы создали как обычный класс Cocoa, и он является подклассом NSObject. Пока что настройки проекта выглядят так:

DrYEzG5i3dVViHfhA5b7kxvwdpti2SZvtLAp

Затем мы добавили метод класса под названием sharedInstance как обсуждалось ранее, поскольку именно так класс сделает Singleton доступным. Его возвращаемое значение равно SingleObject типа, следующим образом:

func sharedInstance() -> SingletonObject {         }

Функция хранит экземпляр в статической локальной ссылке под названием localSharedInstance. Статические локальные объекты очень похожи на глобальные объекты – они сохраняют свою ценность на протяжении всей жизни программы, но имеют ограниченный объем. Эти качества делают их идеальными для того, чтобы быть Singleton, поскольку они постоянны, но гарантируют, что наш Singleton доступен только через sharedInstance.

Это один из способов, посредством которого наша реализация Singleton гарантирует, что Singleton остается единственным. Базовая структура совместного экземпляра состоит из условного блока, который проверяет, был ли выделен экземпляр Singleton. Но, как ни странно, это более старый способ делать вещи (или, может быть, так и в других языках). В Swift, однако, реализация изменилась до просто одной строчки, и нам не нужен метод. Реализация выглядит так:

class SingletonObject: NSObject {    static let sharedInstance = SingletonObject()}

Просто, не правда ли?

Шаблон проектирования Singleton – плюсы и минусы

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

Некоторые разработчики критикуют Singletons по разным причинам. Мы рассмотрим эту критику и обсудим пути ее решения. Критика, в основном, делится на две категории:

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

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

Чтобы узнать другие обновления, вы можете следить за мной в Twitter на моем твиттере @NavRudraSambyal

Чтобы узнать больше о различных шаблонах проектирования и практических примерах, вы можете перейти по ссылке на мою книгу «Реактивное программирование в Swift 4».

Спасибо за прочтение, поделитесь им, если вы нашли это полезным 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *