Singleton Pattern - это лучше практика?

Question

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

Vs.

Singleton::FooHelper(); 

Где FooHelper определяется:

class Singleton 
{ 
    ... 

    static void FooHelper() 
    { 
     Singleton::Instance()->Foo(); 
    } 
    ... 
} 

ли второе решение считается плохой практикой? Я бы не выполнял вспомогательные функции для всех методов Singleton, только те, которые очень часто используются клиентским кодом.

Answer 1

Это не плохая практика, пока 1 ° оригинальный Foo() метод по-прежнему общедоступны и 2 ° схема присвоения имен делает это очевидным, что FooHelper() эквивалентно вызову Foo() на экземпляре.

Конечно, если вы оказываетесь всегда называя FooHelper() и никогда не называя Foo(), пересмотреть свой дизайн: точка одноточечного (в отличие от равнинной глобальной-функции-в-пространства имен подхода) является то, что это объект — так по крайней мере некоторые части вашего кода должны использовать его как таковые.

Answer 2

Одна из идей - полностью избавиться от синглтона. Сделайте его подходящим классом с надлежащим владельцем в вашей системе, к которому должны пройти другие классы, чтобы овладеть этим объектом. Затем вы можете получить к нему доступ, как «обычный» объект, и он не будет выглядеть таким резким.

Многие люди считают singletons an anti-pattern. Большая проблема с ними, которую я обнаружил, - это очень сложно обобщить ваш код, когда вы найдете необходимость в этот день. По мере того, как компьютеры становятся быстрее и получают больше ядер, где я работаю, мы теперь находим, что хотим иметь возможность запускать более одной из наших основных программ на одной и той же машине одновременно. Самая большая проблема для этого - это все синглы, которые мы глупо закодировали.

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