Синглтон-паттерн - какая практика лучше?

Question

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

Singleton::Instance()->Foo();

против

Singleton::FooHelper();

Где определен FooHelper:

class Singleton
{
    ...

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

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

Answer 1

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

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

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

Answer 2

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

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