Статический класс членов против нормального c-подобного интерфейса - PullRequest
Новая
       41

Статический класс членов против нормального c-подобного интерфейса

5 голосов
/ 12 февраля 2011

Привет.
Прочитав здесь о шаблоне Service Locator, я подумал, действительно ли класс, в котором есть только статические члены, действительно подходит, или если нормальное c-подобное взаимодействиене будет более подходящим.Я вижу людей, которые бегают вокруг ключевого слова class все время, когда оно им даже не нужно.
Пример со статическим классом членов, взятым со связанной страницы: 

class Locator
{
public:
    static IAudio* GetAudio() { return service_; }

    static void Register(IAudio* service)
    {
        service_ = service;
    }

private:
    static IAudio* service_;
};

Вот как можносделайте это тоже: 

// in .h
namespace Locator{
    IAudio* GetAudio();
    void Register(IAudio* service);
}

// in .cpp
namespace Locator{
    namespace {
        IAudio* service_;
    }

    IAudio* GetAudio() {
        return service_;
    }
    void Register(IAudio* service) {
        service_ = service;
    }
}

Оба примера можно назвать точно так же, как Locator::GetAudio() и Locator::Register(...).Одно из вышеперечисленного превосходит другое?Они одинаковы?Есть, может быть, лучшие способы сделать это?Или это просто личные предпочтения?Спасибо за любую помощь.:)

Ответы [ 2 ]

3 голосов
/ 12 февраля 2011

Ваше предложение с пространствами имен имеет небольшой недостаток в удобстве сопровождения - если вам по какой-то причине нужно изменить интерфейс, вы должны помнить, что нужно изменить и интерфейс (.h), и реализацию (.cpp), или несоответствиене может быть обнаружен до времени ссылки.Если вы используете class, то компилятор может обнаружить ошибку, такую ​​как несоответствие ряда параметров.

С другой стороны, поскольку реализация (service_) в вашемрегистр появляется только в файле .cpp, вы можете изменить частную реализацию локатора без принудительной перекомпиляции кода, который зависит от локатора.(Обычные шаблоны на основе классов могут обеспечить такую ​​же инкапсуляцию.)

Это довольно незначительные различия.Публичное пространство имен, содержащее функции, почти такое же, как класс с только статическими функциями-членами.

0 голосов
/ 12 февраля 2011

Одной из веских причин для использования интерфейсов классов является согласованность.

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

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

метки / псевдонимы пространств имен труднее передать (по сравнению с параметрами types / typedefs / template).это полезно, если ваши интерфейсы похожи, и вы используете много общего программирования, или если вы просто хотите реализовать тесты.

...