Не используйте Синглтон

20 Октября 2019 Программирование
2 0

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

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

Например, у вас есть код, который пишет в файл и запись в файл может происходить в разных методах – нужен ли тут синглтон, чтобы разделить один и тот же хэндл, для записи в файл? Нет. Я не могу себе представить код, в котором тут можно было бы выиграть от наличие синлтона, уж лучше просто хранить где-то указатель и передавать его. 

Синглтон не предназначен для хранения каких-то общих данных, это не очень хорошее решение. 

Синглтон ужасен, если вы хотите дать возможность получить доступ к определенному коду из любого места, как это было в ASP.NET с HttpContext. Я точно не знаю, как HttpContext реализован внутри, но уж очень похоже на то, что мы обсуждаем. 

Если вам нужно реализовать что-то типа единой точки для доступа к чему-то, то стоит 10 раз подумать – а действительно ли нужен в этом случае именно синглтон и действительно ли вам нужна эта единая точка. 

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

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

- позволяет убедиться, что есть только один экземпляр

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

- позволяет контролировать процесс создания

- позволяет контролировать количество экземпляров класса

Так вот я считаю, что второй и третий пункт не должны решаться через синглтон. Первый и последний – вполне реальные вариации, которые решаются с помощью этого паттерна очень красиво и элегантно и тут можно использовать. 

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

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

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

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

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

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

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым