Чому можна використовувати вкладені класи в C ++?

Чи може хтось, будь ласка, вказати мені на деякі приємні ресурси для розуміння та використання вкладених класів? У мене є такий матеріал, як Принципи програмування та такі речі, як цей Центр знань IBM - Вкладені класи

Але у мене все ще виникають проблеми з розумінням їхнього призначення. Може хтось, будь ласка, допоможе мені?

Вкладені класи класні для приховування деталей реалізації.

Список:

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. оголосити два класи: SomeSpecificCollectionі Element- погано, тому що ім'я "Елемент" є загальним для того, щоб викликати можливе зіткнення імені

2. ввести простір імен someSpecificCollectionта оголосити класи someSpecificCollection::Collectionта someSpecificCollection::Element. Немає ризику зіткнення імені, але чи може він отримати більше багатослівного?

3. оголосити два глобальні класи SomeSpecificCollectionі SomeSpecificCollectionElement- що має незначні недоліки, але, ймовірно, добре.

4. оголосити глобальний клас SomeSpecificCollectionі клас Elementйого вкладеним класом. Тоді:

   • ви не ризикуєте будь-якими зіткненнями імен, оскільки елемент не знаходиться у глобальному просторі імен,
   • при здійсненні SomeSpecificCollectionви посилаєтесь на просто Element, а скрізь SomeSpecificCollection::Element- як - що виглядає + - те саме, що і 3., але більш чітко
   • стає зрозуміло просто, що це "елемент певної колекції", а не "конкретний елемент колекції"
   • видно, що SomeSpecificCollectionце теж клас.

На мою думку, останній варіант, безумовно, найбільш інтуїтивний і, отже, найкращий дизайн.

Дозвольте наголосити - це не велика різниця від створення двох глобальних класів з більш багатослівними іменами. Це просто крихітна деталь, але їм це робить код більш зрозумілим.

Введення іншої області в межах класу

Це особливо корисно для введення typedefs або enums. Я просто опублікую тут приклад коду:

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, ви отримаєте лише перерахунки з потрібної запропонованої області. Це також зменшує ризик помилки.

Звичайно, це може не знадобитися для невеликих занять, але якщо у вас є багато перераховань, то це полегшує роботу клієнтських програмістів.

Таким же чином, ви могли б "організувати" велику купу типів у шаблоні, якщо у вас коли-небудь виникне потреба. Іноді це корисна модель.

Ідіома PIMPL

PIMPL (скорочення покажчика на 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клас, який має ідентифікаційний номер, код типу та ім’я поля. Якщо я хочу здійснити пошук vectorцих Fields за ідентифікаційним номером або іменем, я можу побудувати функтор для цього:

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

Тоді код, який потребує пошуку цих Fields, може скористатися matchрамками в межах самого Fieldкласу:

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

Можна реалізувати шаблон Builder з вкладеним класом . Особливо в C ++, особисто я вважаю це семантично чистішим. Наприклад:

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

Замість:

class Product {}
class ProductBuilder {}