Можно ли заменить синглтон на Factory?

Я согласен, что иногда это имеет смысл. Однако это зависит от того, что вы создаете.

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

Не поймите меня неправильно, архитектура очень важна, но не переусердствуйте.

На мой взгляд, основным недостатком синглтонов является тесная связь (со всеми вытекающими последствиями, такими как плохое тестирование и т. Д.).

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

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

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

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

Вы можете заменить синглтон на IoC, и действительно, похоже, есть много плохих предчувствий к синглтону как к антипаттерну, и даже Гамма сказал, что ему жаль, что он не исключил его из книги GoF ...

Factory - определенно альтернатива Синглтону, и я бы предпочел первый второму. Синглтоны очень сложно тестировать и приводят к сильной связи. Фабрики, если они правильно реализованы (с использованием чистых интерфейсов и т. Д.), Приводят к более тестируемому коду и меньшему количеству взаимосвязей.

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

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

Я бы рекомендовал прочитать это от Мишко Хевери и две последующие статьи 1 и 2. Здесь он описывает, в чем разница между объектом с одним экземпляром и объектом Singleton, как в шаблоне проектирования, и что предпочтение следует отдавать первому из них.

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

Синглтон, конечно, антипаттерн. А если вы используете TDD - вам следует избегать таких решений. Любая инфраструктура IoC, такая как Windsor или Unity, может эмулировать эту функциональность без ужасных статических классов. Однако, если вы не используете TDD и ваш проект довольно прост, вы можете его использовать. Кстати, я бы порекомендовал IoC Framework, а не самодельные фабрики. Не изобретайте колесо.