ビデオの再生と記録に使用されるクラスのコレクションに取り組んでいます。play()、stop()、などのメソッドを使用して、パブリック インターフェイスのように機能する 1 つのメイン クラスがあります。次にpause()、record()ビデオのデコードとビデオのエンコードを行う主力クラスがあります。
C++ にネストされたクラスが存在することを知ったばかりで、プログラマーがそれらを使用することについてどう考えているか知りたいです。私は少し警戒しており、利点/欠点が何であるかはよくわかりませんが、（私が読んでいる本によると）私のような場合に使用されるようです.
この本は、私のようなシナリオでは、クライアントが使用することを意図していないクラス用の個別のファイルがないように、インターフェイスクラス内に主力クラスをネストすること、および可能性のある名前の競合を回避することが良い解決策であることを示唆しています? これらの正当化についてはわかりません。ネストされたクラスは、私にとって新しい概念です。プログラマーがこの問題についてどう思うか知りたいだけです。
ここでネストされたクラスを使用するのは少し気が進まないでしょう。「マルチメディア ドライバー」用の抽象基本クラスを作成してバックエンドの作業 (主力) を処理し、フロントエンドの作業用に別のクラスを作成した場合はどうなるでしょうか。フロントエンド クラスは、実装されたドライバー クラスへのポインター/参照を (適切なメディアの種類と状況に対して) 取得し、主力構造に対して抽象操作を実行できます。
私の哲学は、両方の構造が連携して使用されるという前提の下で、クライアントが洗練された方法でアクセスできるようにすることです。
QtのQTextDocumentのようなものを参照します。ベア メタル データ処理への直接的なインターフェイスを提供しますが、権限を QTextEdit などのオブジェクトに渡して操作を行います。
ネストされたクラスを使用して、メインクラスの実装に必要な（小さな）ヘルパークラスを作成します。または、たとえば、インターフェイス（抽象メソッドを持つクラス）を定義します。
この場合、ネストされたクラスの主な欠点は、それらを再利用するのが難しくなることです。おそらく、別のプロジェクトでVideoDecoderクラスを使用したいと思うでしょう。これをVideoPlayerのネストされたクラスにすると、エレガントな方法でこれを行うことはできません。
代わりに、他のクラスを別々の.h / .cppファイルに入れて、VideoPlayerクラスで使用できるようにします。VideoPlayerのクライアントは、VideoPlayerを宣言するファイルを含めるだけでよく、それをどのように実装したかを知る必要はありません。
ネストされたクラスを使用するかどうかを決定する 1 つの方法は、このクラスが補助的な役割を果たしているのか、それとも独自の役割を果たしているのかを考えることです。
別のクラスを支援するためだけに存在する場合は、通常、ネストされたクラスにします。それには多くの注意事項があり、矛盾しているように見えるものもありますが、すべて経験と直感にかかっています。
さて、Interfaceクラスで主力クラスへのポインターを使用し、それらをパラメーターとして公開したり、インターフェイスメソッドで型を返したりしない場合は、これらの主力クラスの定義をインターフェイスヘッダーファイルにインクルードする必要はありません（代わりにそれらを前方宣言します）。そうすれば、インターフェースのユーザーはバックグラウンドのクラスについて知る必要がなくなります。
このためにクラスをネストする必要はありません。実際、個別のクラスファイルを使用すると、プロジェクトが大きくなるにつれて、コードがはるかに読みやすくなり、管理しやすくなります。また、後でサブクラス化する必要がある場合にも役立ちます（たとえば、さまざまなコンテンツ/コーデックタイプの場合）。
PIMPLパターンの詳細は次のとおりです（セクション3.1.1）。
半古いSunC++コンパイラと、標準で動作が変更されたネストされたクラスの可視性で問題が発生しました。もちろん、これはネストされたクラスを実行しない理由ではありません。古いコンパイラを含む多くのプラットフォームでソフトウェアをコンパイルする場合は、注意が必要です。
戦略パターンを使用できる場合のように聞こえます
実装クラスをユーザーから隠すことが適切な場合もあります。このような場合は、パブリック クラス定義内よりも foo_internal.h 内に配置する方が適切です。そうすれば、あなたの foo.h の読者は、あなたが何に悩まされたくないのかを知ることはできませんが、インターフェイスの具体的な実装のそれぞれに対してテストを書くことができます。
内部クラスは、外部クラスになる予定のパブリック インターフェイスを使用して別のクラスとして実装できない場合にのみ使用してください。内部クラスは、クラスのサイズ、複雑さ、責任を増大させるため、慎重に使用する必要があります。
あなたのエンコーダー/デコーダークラスは、戦略パターンにより適しているように聞こえます
覚えておくべきもう1つのことは、仕事関数のさまざまな実装（デコードやエンコードなど）を想定しているかどうかです。その場合、関数を実装するさまざまな具象クラスを持つ抽象基本クラスが間違いなく必要になります。実装のタイプごとに個別のサブクラスをネストすることは実際には適切ではありません。
ネストされたクラスを避ける理由の 1 つは、他の言語で使用するためにコードを swig ( http://www.swig.org ) でラップする場合です。Swig は現在、ネストされたクラスに問題があるため、ネストされたクラスを公開するライブラリとのインターフェイスは非常に面倒です。