Neden C ++ 'da iç içe sınıflar kullanılır?

Birisi beni iç içe dersleri anlamak ve kullanmak için güzel kaynaklara yönlendirebilir mi? Programlama Prensipleri ve IBM Bilgi Merkezi - İç İçe Sınıflar gibi bazı materyallerim var

Ama hala amaçlarını anlamakta güçlük çekiyorum. Birisi bana yardım edebilir mi?

Yuvalanmış sınıflar uygulama ayrıntılarını gizlemek için iyidir.

Liste:

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

Burada düğümü ifşa etmek istemiyorum çünkü diğer insanlar sınıfı kullanmaya karar verebilir ve maruz kalan herhangi bir şey genel API'nin bir parçası olduğu ve sonsuza kadar sürdürülmesi gerektiği için sınıfımı güncellememi engeller . Sınıfı özel yaparak, sadece benim olduğunu söyleyeceğim uygulamayı gizlemekle kalmam, bunu istediğiniz zaman değiştirebilirim, böylece kullanamazsınız.

Bakın std::listya std::mapda hepsi gizli sınıflar içeriyor (ya da var mı?). Mesele şu ki olabilir ya da olmayabilir, ancak uygulama özel ve gizli olduğu için STL'nin oluşturucuları, kodu nasıl kullandığınızı etkilemeden veya ihtiyaç duydukları için çok sayıda eski bagajı bırakmadan kodu güncelleyebildiler. içeride gizli olan Node sınıfını kullanmak istediklerine karar veren bazı aptallarla geriye dönük uyumluluk sağlamak list.

Yuvalanmış sınıflar normal sınıflar gibidir, ancak:

• ek erişim kısıtlamaları vardır (bir sınıf tanımındaki tüm tanımlar gibi),
• Onlar verilen ad kirletmeyen genel ad alanını örneğin,. B sınıfının A sınıfına o kadar derinden bağlı olduğunu düşünüyorsanız, ancak A ve B nesnelerinin ille de ilişkili olmadığını düşünüyorsanız, B sınıfının yalnızca A sınıfının kapsamını kullanarak erişilebilir olmasını isteyebilirsiniz (A olarak adlandırılır. ::Sınıf).

Bazı örnekler:

İlgili sınıfın kapsamına koymak için genel olarak sınıflandırma

Sınıf SomeSpecificCollectionnesnelerini toplayacak bir sınıfa sahip olmak istediğinizi varsayalım Element. Daha sonra aşağıdakilerden birini yapabilirsiniz:

1. iki sınıf bildirin: SomeSpecificCollectionve Element- kötü, çünkü "Element" ismi olası bir isim çatışmasına neden olacak kadar genel

2. bir ad alanı tanıtmak someSpecificCollectionve sınıfları bildirmek someSpecificCollection::Collectionve someSpecificCollection::Element. İsim çatışması riski yok, ama daha ayrıntılı olabilir mi?

3. iki küresel sınıf ilan SomeSpecificCollectionve SomeSpecificCollectionElement- küçük dezavantajları vardır, ama muhtemelen sorun yok.

4. global sınıfı SomeSpecificCollectionve sınıfı Elementiç içe sınıfı olarak ilan eder. Sonra:

   • Öğe genel ad alanında olmadığı için hiçbir adın çakışması riskini almazsınız,
   • uygulamanızda SomeSpecificCollectionadil Elementve başka her yerdeSomeSpecificCollection::Element , 3 ile aynı görünen, + görünen, ancak daha açık olan
   • "koleksiyonun belirli bir öğesi" değil, "belirli bir koleksiyonun öğesi" olması çok basit
   • o SomeSpecificCollectionda bir sınıftır.

Bence son varyant kesinlikle en sezgisel ve dolayısıyla en iyi tasarım.

Vurgulayayım - Daha ayrıntılı isimlerle iki küresel sınıf yapmaktan büyük bir fark yok. Bu sadece küçük bir detay, ama imho kodu daha net hale getiriyor.

Sınıf kapsamı içinde başka bir kapsamın tanıtımı

Bu özellikle typedefs veya enum'ları tanıtmak için kullanışlıdır. Buraya bir kod örneği göndereceğim:

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

Biri arayacak:

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

Ancak, kod tamamlama önerilerine bakarken Product:: genellikle listelenen tüm olası numaralandırma değerlerini (BOX, FANCY, CRATE) alır ve burada bir hata yapmak kolaydır (C ++ 0x'in güçlü yazılan numaralandırmalar bunu çözer, ama boş verin) ).

Ancak, yuvalanmış sınıfları kullanan bu numaralandırmalar için ek kapsam eklerseniz, işler şöyle görünebilir:

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

Sonra çağrı şöyle görünür:

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

Sonra yazarak Product::ProductType:: bir IDE , yalnızca önerilen kapsamdan numaralandırmalar alınacaktır. Bu aynı zamanda hata yapma riskini de azaltır.

Tabii ki bu, küçük sınıflar için gerekli olmayabilir, ancak çok sayıda numaralandırma varsa, istemci programcıları için işleri kolaylaştırır.

Aynı şekilde, ihtiyaç duymanız halinde, bir şablonda çok sayıda typedef'i "organize edebilirsiniz". Bazen faydalı bir model.

PIMPL deyimi

PIMPL (Pointer'dan IMPLementation'a kısaltma), bir sınıfın uygulama ayrıntılarını başlıktan kaldırmak için yararlı bir deyimdir. Bu, başlığın "uygulama" kısmı her değiştiğinde sınıfın başlığına bağlı olarak sınıfların yeniden derlenmesi ihtiyacını azaltır.

Genellikle iç içe bir sınıf kullanılarak uygulanır:

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

Tam sınıf tanımının, ağır veya sadece çirkin bir üstbilgi dosyasına (WinAPI al) sahip bazı harici kitaplıklardan tanım gerektirmesi özellikle yararlıdır. PIMPL kullanıyorsanız, WinAPI'ye özgü işlevleri yalnızca içine ekleyebilir .cppve asla içine dahil edemezsiniz .h.

İç içe dersleri çok fazla kullanmıyorum ama arada sırada kullanıyorum. Özellikle bir tür veri türü tanımladığımda ve o veri türü için tasarlanmış bir STL işlevi tanımlamak istediğimde.

Örneğin, Fieldkimlik numarası, tür kodu ve alan adı olan genel bir sınıf düşünün . vectorBu Fields birini kimlik numarası veya ad ile aramak istiyorsanız , bunu yapmak için bir işlev oluşturabilir:

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

Sonra bu Fields aramak için gereken kod sınıf matchiçinde Fieldkendi kapsamı kullanabilirsiniz :

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

Yuvalanmış sınıfla bir Builder kalıbı uygulanabilir . Özellikle C ++ 'da kişisel olarak anlamsal olarak daha temiz buluyorum. Örneğin:

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

Ziyade:

class Product {}
class ProductBuilder {}