Warum sollte man verschachtelte Klassen in C ++ verwenden?

Kann mich bitte jemand auf einige nette Ressourcen hinweisen, um verschachtelte Klassen zu verstehen und zu verwenden? Ich habe Material wie Programmierprinzipien und solche Dinge wie dieses IBM Knowledge Center - Verschachtelte Klassen

Aber ich habe immer noch Probleme, ihren Zweck zu verstehen. Könnte mir bitte jemand helfen?

Verschachtelte Klassen sind cool, um Implementierungsdetails auszublenden.

Aufführen:

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

Hier möchte ich Node nicht verfügbar machen, da andere Benutzer sich möglicherweise für die Verwendung der Klasse entscheiden. Dies würde mich daran hindern, meine Klasse zu aktualisieren, da alles, was verfügbar gemacht wird, Teil der öffentlichen API ist und für immer beibehalten werden muss . Indem ich die Klasse privat mache, verstecke ich nicht nur die Implementierung, sondern sage auch, dass dies meine ist, und ich kann sie jederzeit ändern, sodass Sie sie nicht verwenden können.

Schauen Sie sich an std::listoder std::mapsie enthalten alle versteckte Klassen (oder doch?). Der Punkt ist, dass sie möglicherweise oder möglicherweise nicht, aber da die Implementierung privat und versteckt ist, konnten die Builder der STL den Code aktualisieren, ohne die Verwendung des Codes zu beeinflussen, oder viel altes Gepäck in der STL herumliegen lassen, weil sie es benötigen um die Abwärtskompatibilität mit einem Dummkopf aufrechtzuerhalten, der beschlossen hat, die darin verborgene Node-Klasse zu verwenden list.

Verschachtelte Klassen sind wie normale Klassen, aber:

• Sie haben zusätzliche Zugriffsbeschränkungen (wie alle Definitionen innerhalb einer Klassendefinition).
• Sie verschmutzen den angegebenen Namespace nicht , z. B. den globalen Namespace. Wenn Sie der Meinung sind, dass Klasse B so eng mit Klasse A verbunden ist, die Objekte von A und B jedoch nicht unbedingt miteinander verbunden sind, möchten Sie möglicherweise, dass auf die Klasse B nur über das Scoping der A-Klasse zugegriffen werden kann (dies wird als A bezeichnet) ::Klasse).

Einige Beispiele:

Klasse öffentlich verschachteln, um sie in einen Bereich der relevanten Klasse zu setzen

Angenommen, Sie möchten eine Klasse haben, die Klassenobjekte SomeSpecificCollectionaggregiert Element. Sie können dann entweder:

1. Deklarieren Sie zwei Klassen: SomeSpecificCollectionund Element- schlecht, da der Name "Element" allgemein genug ist, um einen möglichen Namenskonflikt zu verursachen

2. Führen Sie einen Namespace ein someSpecificCollectionund deklarieren Sie Klassen someSpecificCollection::Collectionund someSpecificCollection::Element. Kein Risiko eines Namenskonflikts, aber kann es noch ausführlicher werden?

3. deklarieren Sie zwei globale Klassen SomeSpecificCollectionund SomeSpecificCollectionElement- was kleinere Nachteile hat, aber wahrscheinlich in Ordnung ist.

4. Deklarieren Sie globale Klasse SomeSpecificCollectionund Klasse Elementals verschachtelte Klasse. Dann:

   • Sie riskieren keine Namenskonflikte, da sich Element nicht im globalen Namespace befindet.
   • In der Implementierung von SomeSpecificCollectionbeziehen Sie sich auf gerecht Elementund überall sonst als SomeSpecificCollection::Element- was + aussieht - das gleiche wie 3., aber klarer
   • Es wird ganz einfach, dass es "ein Element einer bestimmten Sammlung" ist, nicht "ein bestimmtes Element einer Sammlung".
   • Es ist sichtbar, dass dies SomeSpecificCollectionauch eine Klasse ist.

Meiner Meinung nach ist die letzte Variante definitiv das intuitivste und damit beste Design.

Lassen Sie mich betonen - Es ist kein großer Unterschied, zwei globale Klassen mit ausführlicheren Namen zu erstellen. Es ist nur ein kleines Detail, aber imho macht es den Code klarer.

Einführung eines anderen Bereichs innerhalb eines Klassenbereichs

Dies ist besonders nützlich für die Einführung von Typedefs oder Enums. Ich werde hier nur ein Codebeispiel posten:

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
};

Man wird dann anrufen:

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

Wenn man sich jedoch Vorschläge zur Code-Vervollständigung ansieht Product::, werden oft alle möglichen Aufzählungswerte (BOX, FANCY, CRATE) aufgelistet, und es ist leicht, hier einen Fehler zu machen (die stark typisierten Aufzählungen von C ++ 0x lösen das irgendwie, aber egal ).

Wenn Sie jedoch mithilfe verschachtelter Klassen zusätzlichen Bereich für diese Aufzählungen einführen, könnte dies folgendermaßen aussehen:

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
};

Dann sieht der Anruf so aus:

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

Product::ProductType::Wenn Sie dann eine IDE eingeben , erhalten Sie nur die Aufzählungen aus dem gewünschten vorgeschlagenen Bereich. Dies verringert auch das Fehlerrisiko.

Natürlich wird dies für kleine Klassen möglicherweise nicht benötigt, aber wenn man viele Aufzählungen hat, erleichtert dies den Client-Programmierern die Arbeit.

Auf die gleiche Weise könnten Sie eine große Anzahl von Typedefs in einer Vorlage "organisieren", falls Sie dies jemals benötigen würden. Es ist manchmal ein nützliches Muster.

Die PIMPL-Sprache

Die PIMPL (kurz für Pointer to IMPLementation) ist eine nützliche Redewendung, um die Implementierungsdetails einer Klasse aus dem Header zu entfernen. Dies reduziert die Notwendigkeit, Klassen abhängig vom Header der Klasse neu zu kompilieren, wenn sich der "Implementierung" -Teil des Headers ändert.

Es wird normalerweise mit einer verschachtelten Klasse implementiert:

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

Dies ist besonders nützlich, wenn für die vollständige Klassendefinition die Definition von Typen aus einer externen Bibliothek erforderlich ist, die eine schwere oder nur hässliche Header-Datei enthält (nehmen Sie WinAPI). Wenn Sie PIMPL verwenden, können Sie WinAPI-spezifische Funktionen nur in einschließen .cppund niemals einschließen .h.

Ich benutze nicht viel verschachtelte Klassen, aber ich benutze sie ab und zu. Insbesondere, wenn ich einen Datentyp definiere und dann einen STL-Funktor definieren möchte, der für diesen Datentyp entwickelt wurde.

Betrachten Sie beispielsweise eine generische FieldKlasse mit einer ID-Nummer, einem Typcode und einem Feldnamen. Wenn ich eines vectordieser Fields nach ID-Nummer oder Name durchsuchen möchte , kann ich einen Funktor dafür erstellen:

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_;
  };
};

Dann kann Code, der nach diesen Fields suchen muss, den matchGültigkeitsbereich innerhalb der FieldKlasse selbst verwenden:

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

Man kann ein Builder-Muster mit verschachtelter Klasse implementieren . Besonders in C ++ finde ich es semantisch sauberer. Beispielsweise:

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

Eher, als:

class Product {}
class ProductBuilder {}