Шаблон Singleton решает многие ваши проблемы. Вы знаете, что вам нужен единственный экземпляр. Вы получаете гарантию, что этот экземпляр будет инициализирован перед использованием. Архитектура остается простой благодаря наличию глобальной точки доступа. Все прекрасно. Ну что может не понравиться в этом классическом шаблоне проектирования?
Если подумать, то весьма многое. Как ни соблазнительно применение синглтонов, они, как показывает опыт, приносят больше вреда, чем пользы. Они затрудняют тестирование и усложняют сопровождение. К сожалению, это понимание не столь распространено, как хотелось бы, и синглтоны сохраняют свое обаяние для множества программистов. Хотя есть основания задуматься, так ли они хороши:
• Ограничение на число экземпляров класса часто иллюзорно. Во многих случаях утверждение, что в будущем не понадобятся дополнительные экземпляры, ничем не подкреплено. Домыслы в основе архитектуры приложения обязательно приведут к неприятностям в будущем. Технические требования меняются. Хорошая архитектура это учитывает. Синглтоны — нет.
• Синглтоны создают неявные зависимости между концептуально независимыми модулями кода. Беда в том, что, во-первых, эти зависимости незаметны, а во-вторых, создают ненужные связи между модулями. Этот запашок в коде становится острее, когда вы пытаетесь писать модульные тесты, основанные на слабом связывании и возможности выборочно применять реализации-макеты вместо настоящих. Синглтоны не дают осуществлять такое простое моделирование.
• Синглтоны неявно хранят состояние, что опять-таки препятствует модульному тестированию. Модульное тестирование предполагает, что тесты независимы друг от друга, благодаря чему их можно выполнять в любом порядке, а программу можно возвращать в известное состояние перед выполнением каждого модульного теста. Как только появляются синглтоны с изменяемым (mutable) состоянием, обеспечить такие условия может оказаться затруднительно. Кроме того, такое глобально доступное долгоживущее состояние затрудняет интерпретацию кода человеком, особенно в многопоточной среде.
• Многопоточность создает дополнительные капканы в использовании шаблона синглтона. Поскольку простая блокировка доступа не очень эффективна, получила распространение так называемая блокировка с двойной проверкой (DCLP). К несчастью, иногда это просто другая разновидность рокового влечения. Оказалось, что во многих языках DCLP не является потоково-безопасной, и даже в тех, где она является потоково-безопасной, сохраняются возможности для ее неправильной работы.
Избавление от синглтонов может стать в окончательном итоге сложной задачей:
• Явное уничтожение объектов синглтонов не поддерживается. В отдельных контекстах это может оказаться проблемой, например в архитектуре с подключаемыми модулями, где модуль можно безопасно выгрузить, только если все его объекты удалены из памяти.
• При завершении программы порядок неявной зачистки синглтонов не определен. Это может вызвать проблемы в приложениях, содержащих синглтоны с взаимными зависимостями. При завершении таких приложений одни синглтоны могут продолжать обращаться к другим, которые к тому моменту уже уничтожены.
Некоторые из перечисленных недостатков можно преодолеть с помощью специальных механизмов. Однако за это приходится расплачиваться усложнением кода, чего удалось бы избежать, если бы в проекте использовались иные подходы к архитектуре.
Поэтому ограничьте использование шаблона Singleton теми классами, для которых действительно не должно никогда создаваться более одного экземпляра. Не стоит пользоваться глобальной точкой входа в синглтон в произвольных участках кода. Прямое обращение к синглтону должно происходить лишь в нескольких четко определенных местах и быть доступным коду в целом только через узкий интерфейс. Весь остальной код не знает, как реализован интерфейс — через синглтон или какой-то другой класс, — а потому не зависит от реализации. В результате всего этого разрушаются связи, мешающие модульному тестированию, и облегчается сопровождение. Так что надеюсь, что, когда вы в следующий раз решите реализовать синглтон или к нему обратиться, вы дважды подумаете, стоит ли это делать.