C ++でネストされたクラスを使用するのはなぜですか？

誰かがネストされたクラスを理解して使用するためのいくつかの素晴らしいリソースに私を向けることができますか？プログラミング原則のような資料や、このIBM Knowledge Center-Nested Classesなどの資料があります。

しかし、私はまだ彼らの目的を理解するのに苦労しています。誰かが私を助けてくれませんか？

ネストされたクラスは、実装の詳細を隠すのに最適です。

リスト：

class List
{
    public:
        List(): head(nullptr), tail(nullptr) {}
    private:
        class Node
        {
              public:
                  int   data;
                  Node* next;
                  Node* prev;
        };
    private:
        Node*     head;
        Node*     tail;
};

ここでは、他の人がクラスを使用することを決定する可能性があるため、Nodeを公開したくありません。公開されたものはすべてパブリックAPIの一部であり、永久に維持する必要があるため、クラスを更新できません。クラスをプライベートにすることで、実装を非表示にするだけでなく、これは私のものであり、いつでも変更できるので、使用できなくなります。

見てください、std::listまたはstd::mapすべて非表示のクラスが含まれています（またはそうですか？）。要はそうかもしれないし、そうでないかもしれませんが、実装はプライベートで非表示になっているため、STLのビルダーは、コードの使用方法に影響を与えたり、STLの周りに古い荷物を置いたりすることなく、コードを更新できました。内部に隠されているNodeクラスを使用したいと思った愚か者との後方互換性を維持するためlist。

ネストされたクラスは通常のクラスと同じですが、次のようになります。

• （クラス定義内のすべての定義と同様に）追加のアクセス制限があります。
• それらは与えられた名前空間、例えばグローバル名前空間を汚染しません。クラスBがクラスAに深く関連しているように感じても、AとBのオブジェクトが必ずしも関連していない場合は、クラスBにアクセスするには、Aクラス（Aと呼ばれる） ：：クラス）。

いくつかの例：

関連するクラスのスコープに配置するための、クラスを公にネスト

クラスのSomeSpecificCollectionオブジェクトを集約するクラスが必要だとしますElement。その後、次のいずれかを行うことができます。

1. 2つのクラスを宣言しますSomeSpecificCollectionとElement-悪い、名前「要素」は、一般的に十分可能名前の衝突を起こさせるためにあるので、

2. 名前空間someSpecificCollectionを導入し、クラスsomeSpecificCollection::Collectionを宣言しますsomeSpecificCollection::Element。名前の衝突のリスクはありませんが、さらに冗長になる可能性はありますか？

3. と2つのグローバルクラスSomeSpecificCollectionを宣言しますSomeSpecificCollectionElement-これには小さな欠点がありますが、おそらく大丈夫です。

4. ネストされたクラスとしてグローバルクラスSomeSpecificCollectionとクラスElementを宣言します。次に：

   • Elementはグローバル名前空間にないため、名前が衝突する危険はありません。
   • SomeSpecificCollectionあなたの実装では、だけElementで、他の場所ではSomeSpecificCollection::Element-と同じように+-と見なされますが、より明確です。
   • 「コレクションの特定の要素」ではなく、「特定のコレクションの要素」であることが簡単にわかります
   • SomeSpecificCollectionクラスでもあることは明らかです。

私の意見では、最後のバリアントは間違いなく最も直感的であり、したがって最高のデザインです。

強調させてください-より詳細な名前で2つのグローバルクラスを作成することと大きな違いはありません。それはほんの少しの詳細ですが、imhoはコードをより明確にします。

クラススコープ内に別のスコープを導入する

これは、typedefまたはenumを導入する場合に特に役立ちます。ここにコード例を投稿します。

class Product {
public:
    enum ProductType {
        FANCY, AWESOME, USEFUL
    };
    enum ProductBoxType {
        BOX, BAG, CRATE
    };
    Product(ProductType t, ProductBoxType b, String name);

    // the rest of the class: fields, methods
};

次に、次のように呼び出します。

Product p(Product::FANCY, Product::BOX);

しかし、のコード補完の提案を見ると、Product::すべての可能な列挙値（BOX、FANCY、CRATE）がリストされていることがよくあり、ここでミスを犯しやすいです（C ++ 0xの強く型付けされた列挙型はそれを解決しますが、気にしないでください） ）。

しかし、ネストされたクラスを使用してこれらの列挙型に追加のスコープを導入すると、次のようになります。

class Product {
public:
    struct ProductType {
        enum Enum { FANCY, AWESOME, USEFUL };
    };
    struct ProductBoxType {
        enum Enum { BOX, BAG, CRATE };
    };
    Product(ProductType::Enum t, ProductBoxType::Enum b, String name);

    // the rest of the class: fields, methods
};

その後、呼び出しは次のようになります。

Product p(Product::ProductType::FANCY, Product::ProductBoxType::BOX);

次にProduct::ProductType::IDEを入力すると、提案された目的のスコープから列挙型のみが取得されます。これにより、ミスをするリスクも軽減されます。

もちろん、これは小さなクラスには必要ないかもしれませんが、列挙型がたくさんあると、クライアントプログラマーにとって簡単になります。

同様に、必要に応じて、テンプレート内で多数のtypedefを「整理」することができます。それは時々便利なパターンです。

PIMPLイディオム

PIMPL（Pointer to IMPLementationの略）は、ヘッダーからクラスの実装の詳細を削除するのに役立つイディオムです。これにより、ヘッダーの「実装」部分が変更されるたびに、クラスのヘッダーに応じてクラスを再コンパイルする必要がなくなります。

通常、ネストされたクラスを使用して実装されます。

Xh：

class X {
public:
    X();
    virtual ~X();
    void publicInterface();
    void publicInterface2();
private:
    struct Impl;
    std::unique_ptr<Impl> impl;
}

X.cpp：

#include "X.h"
#include <windows.h>

struct X::Impl {
    HWND hWnd; // this field is a part of the class, but no need to include windows.h in header
    // all private fields, methods go here

    void privateMethod(HWND wnd);
    void privateMethod();
};

X::X() : impl(new Impl()) {
    // ...
}

// and the rest of definitions go here

これは、完全なクラス定義が重いまたは単に醜いヘッダーファイル（WinAPIを使用）を持つ外部ライブラリからの型の定義を必要とする場合に特に役立ちます。PIMPLを使用する場合は、WinAPI固有の機能をだけで囲み、に.cpp含めないでください.h。

ネストしたクラスはあまり使用しませんが、時々使用します。特に、ある種のデータ型を定義した後、そのデータ型用に設計されたSTLファンクタを定義したい場合は、

たとえばField、ID番号、タイプコード、フィールド名を持つジェネリッククラスを考えてみます。ID番号または名前のいずれかvectorでこれらFieldのを検索する場合は、それを実行するファンクタを作成します。

class Field
{
public:
  unsigned id_;
  string name_;
  unsigned type_;

  class match : public std::unary_function<bool, Field>
  {
  public:
    match(const string& name) : name_(name), has_name_(true) {};
    match(unsigned id) : id_(id), has_id_(true) {};
    bool operator()(const Field& rhs) const
    {
      bool ret = true;
      if( ret && has_id_ ) ret = id_ == rhs.id_;
      if( ret && has_name_ ) ret = name_ == rhs.name_;
      return ret;
    };
    private:
      unsigned id_;
      bool has_id_;
      string name_;
      bool has_name_;
  };
};

次に、これらFieldのを検索する必要があるコードはmatch、Fieldクラス自体のスコープを使用できます。

vector<Field>::const_iterator it = find_if(fields.begin(), fields.end(), Field::match("FieldName"));

入れ子のクラスでビルダーパターンを実装できます。特にC ++では、個人的には意味的にクリーンだと思います。例えば：

class Product{
    public:
        class Builder;
}
class Product::Builder {
    // Builder Implementation
}

のではなく：

class Product {}
class ProductBuilder {}