我正在處理用於視頻回放和錄製的類的集合。我有一個類似公共接口的主類，使用的方法有play(),,record()等等。然後我有用於視頻解碼和視頻編碼的主力類。我應該在這種情況下使用嵌套類嗎？
我剛剛瞭解到C++中嵌套類的存在，我很想知道程序員是怎麼想的。我有點警惕，並不確定它的好處/缺點，但它們似乎（根據我正在閱讀的書）將用於像我這樣的情況。
這本書提出，在像我這樣的場景中，一個好的解決方案是將嵌套在接口類中的勞動力類，所以沒有單獨的客戶端不打算使用的類的文件，並且爲了避免任何可能的命名衝突？我不知道這些理由。嵌套類對我來說是一個新概念。只是想看看程序員對這個問題的看法。
我會有點不情願在這裏使用嵌套類。如果您爲「多媒體驅動程序」創建抽象基類以處理後端工作（主力），併爲前端工作創建單獨的類，那該怎麼辦？前端類可以採用指向/實現的驅動程序類的引用（適用於適當的介質類型和情況），並在主馬結構上執行抽象操作。
我的理念是繼續努力，讓客戶能夠以優美的方式接觸到這兩種結構，就在他們將一起使用的假設下。
我會在Qt中引用類似於QTextDocument的東西。您提供了裸機數據處理的直接界面，但將權限傳遞給像QTextEdit這樣的對象來完成操作。
決定是否使用嵌套類的一種方法是考慮這個類是否扮演支持角色或它自己的角色。
如果它僅用於幫助另一個類的目的，那麼我通常會將它作爲一個嵌套類。對此有一些警告，其中一些看起來矛盾，但一切都歸結爲經驗和直覺。
聽起來像在那裏你可以使用strategy pattern
有時候，適當的對用戶隱藏實現類的情況下 - 在這種情況下，最好把它們放在一個foo_internal.h不是公共類定義中。這樣，你的foo.h的讀者就不會看到你不喜歡的東西，但是你仍然可以針對你的界面的每個具體實現編寫測試。
您將使用嵌套類來創建實現主類所需的（小）輔助類。或者例如，定義一個接口（一個具有抽象方法的類）。
在這種情況下，嵌套類的主要缺點是這使得難以重用它們。也許你想在另一個項目中使用VideoDecoder類。如果你使它成爲VideoPlayer的一個嵌套類，你不能以優雅的方式做到這一點。
相反，將其他類放在單獨的.h/.cpp文件中，然後您可以在VideoPlayer類中使用它們。 VideoPlayer的客戶端現在只需要包含聲明VideoPlayer的文件，但仍然不需要知道如何實現它。
只有在無法使用可能的外部類public interface將其實現爲單獨的類時，才應該使用內部類。內部類增加了類的大小，複雜性和責任，所以應該謹慎使用它們。
您的編碼器/解碼器類聽起來更符合Strategy Pattern
一個原因，以避免嵌套類是如果你打算用包裹痛飲（http://www.swig.org）的代碼與其他語言的使用。 Swig目前在嵌套類中存在問題，因此與暴露任何嵌套類的庫進行接口會變得非常痛苦。
我們遇到了一個半舊的Sun C++編譯器和嵌套類的可見性問題，該問題在標準中發生了變化。當然，如果你打算在包括舊編譯器在內的許多平臺上編譯你的軟件，那麼這不是不要做你的嵌套類的理由。
要記住的另一件事是，你是否設想你的工作功能（如解碼和編碼）的不同實現。在這種情況下，你肯定會想要一個具有不同具體類的抽象基類來實現這些功能。爲每種類型的實現嵌套一個單獨的子類是不合適的。
那麼，如果您在Interface類中使用指向您的主力類的指針，並且不要在接口方法中將它們作爲參數或返回類型公開，則不需要在接口頭中包含這些工作馬的定義文件（你只需要轉發聲明他們）。這樣，你的界面的用戶將不需要知道背景中的類。
你絕對不需要爲此嵌套類。實際上，隨着項目的增長，單獨的類文件實際上會使您的代碼更易讀，更易於管理。如果您需要繼承子類（比如說不同的內容/編解碼器類型），它也將在以後幫助您。
以下是關於PIMPL pattern（3.1.1節）的更多信息。