內部類的任何解決方案或編程提示？

Question

我在這裏有一些疑問。希望你們可以分享一些編程技巧。只是好奇地想知道，如果我按照下面的代碼進行操作，是不是一種很好的編程習慣。

class Outer { 
public: 
    class Inner { 
    public: 
     Inner() {} 
    } 

    Outer() {} 
}; 

我一直在做這結構，我只希望我的結構被暴露在我的課，而不是全球性的。但這裏的情況有所不同，我現在正在使用一堂課？你們以前面對過這種情況嗎？非常感謝你的任何建議;）

Answer 1

這不是一個日常事物，但它也不是聞所未聞的。如果在客戶端使用Outer時有一個只對客戶端程序有意義的類（Inner），您可以這樣做。

Answer 2

如果您只希望在某個文件中公開某個類，則可以使用該文件中的一個未命名的名稱空間。然後，該名稱空間內的任何代碼僅在該文件中可用。

namespace 
{ 
    //stuff 
} 

Answer 3

我會打破答案分爲兩個部分：

1. 的情況下，你只組織代碼，您應該使用的類的命名空間 - 如果內部類是不是一個實體只能在類內部使用（特別是只在類中構造），那麼內部類是一個好主意 - 另一個示例STL函數對象。
2. 在C++中，結構和類之間絕對沒有區別，除非結構默認具有公共成員。因此，當你有課時，沒有什麼真正的區別 - 這更多的是風格問題。

Answer 4

在許多情況下，這是一個很好的做法。這裏有一個我們實現鏈接列表：

template <class T> 
class MyLinkList { 
    public: 
class Node { 
    public: 
    Node* next; 
    T data; 
    Node(const T& data, Node* node) : next(node), data(data) {} 
}; 

class Iterator { 
    public: 
    Node* current; 
    Iterator(Node* node) : current(node) {} 
    T& operator*() { return current->data; } 
    void operator++(int) { current = current->next; } 
    bool operator!=(int) { return current != NULL; } 
}; 

    private: 
Node* head; 

}

以上僅僅是摘錄的是不打算完整或編譯的。重點是要顯示Node和Iterator是MyLinkList類的內部類。之所以這樣做是有道理的，是爲了傳達這樣一個事實，即Node和Iterator不是獨立的，而是需要由MyLinkList進行限定（例如MyLinkList :: Iterator它）

Answer 5

這是純粹是一種風格問題，但我認爲在C++社區中使用名爲detail的名稱空間對於純粹是幫助程序的類或純粹用於其他類的實現的類型通常更常見。使用名稱空間代替內部類有幾個優點，其中包括：更大的兼容性（例如，編譯器在內部類中解析名稱的方式在Visual C++和GCC之間可能會有令人難以置信的差異），更多的封裝（在內部/外部變體中，內部類可以更好地訪問外部類實例的成員），更簡單的實現（您不必在實現文件中每次都完全限定幫助器類，因爲您可以在其中放入使用指令。 cpp「源文件）。如果您打算使用內部類，那麼您需要做出有意識的決定，將其作爲API的一部分。

使用命名空間

namespace collection 
{ 
    namespace detail 
    { 
     class LinkedListNode 
     { 
      //... 
     }; 
    } 

    class LinkedList 
    { 
      // ... 
    }; 
} 

使用內部類

namespace collection 
{ 
     class LinkedList 
     { 
      // ... 
      class LinkedListNode 
      { 
       // ... 
      }; 
      // ... 
     }; 
}