7

クラスメンバーの一部を公開する必要がある場合があります。たとえば、次の例では、コンポーネントへのclass Mechanic直接アクセスが必要になる場合がありEngineます。いくつかの理由から、すべてのフィールドにミューテーター (アクセサー) メソッドでアクセスする必要があることを何度も読みました。しかし、非 const 参照ゲッターを提供する場合に利点はありますか:

class Car
{
    public:
        Engine & engine()
        {
           return m_engine;
        }

        //as a consequence you will also need to provide const version
        const Engine & engine() const
        {
           return m_engine;
        }

    private:
       Engine m_engine;
}

エンジンコンポーネントを公開するだけではありません:

class Car
{
    public:
        Engine engine;
}

この例が気に入らない場合は、publicに置き換えることもできます。protected実生活では、System.inまたはに関しては Java に似たものがありますSystem.out。一部の人々の言うことに完全に準拠するには、 のような呼び出しを実行する必要があるようSystem.getInstance().getOut().println("hello world")です。そのような場合、多くの官僚的なコードを除いて、何のメリットもありません。

4

9 に答える 9

3

これらは、返す値が実際にヒープ上にある場合に役立ちます。

template<class T> class Singleton
{
private:
    static T* m_pSingleton;

public:
    T& getSingleton() { assert(m_pSingleton); return(*m_pSingleton); };

}; // eo class Singleton
于 2010-11-06T15:59:56.340 に答える
3

明示的なゲッターとセッターは、過度に官僚的である可能性があります。それはあなたの状況に依存します。

Enginegetterおよびsetter関数を使用する主な理由は、クラスのクライアントを将来の実装の潜在的な変更から分離することです（たとえば、メンバーを使用するのではなく、オンデマンドでオブジェクトを生成することにした場合にどうなるかを検討してください）変数）、またはスマートポインター、またはその他のコンテナーの背後に非表示にすることを決定します）。

クラスが非常に単純で（たとえば、 PODに近い）、変更される可能性が低い場合は、ゲッターとセッターを実装する必要があるという手間をかける価値がない可能性があります。

しかし、あなたの質問に答えるために、非定数ゲッターはおそらくあまり意味がありません。ゲッターのプロトタイプは次のようになりEngine & engine() constます。そうしないと、オブジェクトで呼び出すことができなくなりconst Carます。

于 2010-11-06T16:02:24.333 に答える
1

ゲッターを提供する利点の1つは、ゲッターの動作方法を変更する場合に、このクラスを使用するコードを再コンパイルする必要がないことです。ただし、パブリックフィールドがあり、後でゲッターを作成することにした場合は、すべてのコードを再コンパイルする必要があります。それ以外に、変数をプライベートにする重大な実用的な理由は見当たりません。ただし、これはすべて、外部ユーザーがエンジンへの参照を取得する方法を提供する必要がある場合にのみ当てはまることに注意してください。これを完全に排除する必要があるようにソフトウェアを設計することが可能であれば、それはより良いでしょう。

于 2010-11-06T16:00:14.317 に答える
1

そのようなゲッターを提供する合理的なポイントを見つけました。これにより、ソフトウェアの統合が容易になります (たとえば、インターフェイスを別の言語に翻訳して ABI をバインドする場合)。

于 2010-11-13T12:38:21.520 に答える
1

私がたまたま最近教育を受けたように、ゲッターとセッターは悪い設計のにおいがします。ただし、そのようにしたい場合は、関数をm_engine公開するだけでなく (ユーザーが介入する必要はありません)、取得および設定する関数 (ユーザーが定義) を提供することで、将来の変更のためのプラグイン ポイントが得られます。

于 2010-11-06T17:16:52.747 に答える
0

私にとって、それはここで理にかなっています：

image(i,j) = 234;
于 2010-11-06T16:00:03.523 に答える
0

クラスのプライベートメンバーを公開することを考える代わりに、それらのクラスのメソッドを呼び出すという方針に沿って考えてください。興味深いJavaの記事「ゲッターとセッターのメソッドが悪である理由」を読みました。これは、Javaと同じようにC++にも適用されます。

于 2010-11-06T16:03:50.603 に答える
0

はい、それは理にかなっています-保守性、検証、および一貫性のために。

将来、クラスの多くの側面を変更する必要が生じる可能性があります。アクセサーを提供すると、クライアント コードの破損を最小限に抑えることができます。

エンジンが有効なポインターであること、使用できない状態にないことなどを確認するために、必要なすべての検証ロジックをここに入力できます。

最後に、コードは一貫しています。メンバーの可視性を知るためにヘッダーを開く必要はありません。常に知っているだけです。これは、テンプレートでも役立ちます。

于 2010-11-06T17:53:04.480 に答える
0

この場合、 の状態が変更されると思われるので、Car.fix(const Mechanic&)エンジンを に与える関数が必要です。MechanicEngine.fix(const Mechanic&)Engine

クラスを使用する最初のアイデアは、データをそのアクセサ関数と結びつけることでした。内部データを返すだけのセッターまたはゲッターを実行すると、データがそのアクセサー機能と結び付けられていないことを意味します。つまり、クラスは完全ではありません。

クラスが発行する新しいデータのみを公開したい。Car.get_exhaust()とは言っCarても排気はなくて出すだけ、そう聞くと。;)

または、次のようにメカニックによってFire Riefle.fire()アクセスが修正されることはありません:そして、will は say を呼び出します。XDRiefle::TriggerTrigger.fix_by(Mechanic)fix_byMechanic.add_working_hour(0.5)

于 2012-11-14T18:05:27.260 に答える