5

ちょっと、そこ。ここ
で 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(...)。上記のいずれかが他のものよりも優れていますか? 彼らは同じですか？これを達成するためのより良い方法はありますか？それとも個人的な好みの問題ですか？助けてくれてありがとう。:)

4

2 に答える 2

0

クラス インターフェイスを使用する正当な理由の 1 つは、一貫性です。

多くの場合、Locatorクラス内の共有データの実装またはサブクラスの使用がサポートされます。したがって、静的データの名前空間とクラスを組み合わせるよりも、コードベース全体で 1 つのアプローチを使用することが (多くの人にとって) 望ましい (実装によってはサービスを拡張または特化する可能性があるため)。

多くの人は静的データを扱うのが好きではありません。上記の例には、スレッド セーフ、所有権、データの有効期間などの問題があります。データと実装が (ファイル スコープではなく) クラス スコープに制限されている場合は、保守が容易になります。これらの問題は、プログラムの複雑さが増すにつれて大きくなります。あなたが投稿した例は非常に単純です。

名前空間ラベル/エイリアスは、渡すのがより困難です (型/typedefs/テンプレート パラメーターと比較して)。これは、インターフェースが似ていて、大量の汎用プログラミングを使用している場合、または単にテストを実装したい場合に役立ちます。

于 2011-02-12T10:11:34.827 に答える