問題タブ [nested-class]

ビデオの再生と記録に使用されるクラスのコレクションに取り組んでいます。play()、stop()、などのメソッドを使用して、パブリック インターフェイスのように機能する 1 つのメイン クラスがあります。次にpause()、record()ビデオのデコードとビデオのエンコードを行う主力クラスがあります。

C++ にネストされたクラスが存在することを知ったばかりで、プログラマーがそれらを使用することについてどう考えているか知りたいです。私は少し警戒しており、利点/欠点が何であるかはよくわかりませんが、（私が読んでいる本によると）私のような場合に使用されるようです.

この本は、私のようなシナリオでは、クライアントが使用することを意図していないクラス用の個別のファイルがないように、インターフェイスクラス内に主力クラスをネストすること、および可能性のある名前の競合を回避することが良い解決策であることを示唆しています? これらの正当化についてはわかりません。ネストされたクラスは、私にとって新しい概念です。プログラマーがこの問題についてどう思うか知りたいだけです。

例えば：

コンパイラからこのエラーが生成されます。

'A' と 'AB' を含む循環基底クラスの依存関係

ネストされたクラスは、外部クラスのプライベート メンバーへのアクセスに関する特別な規則を除いて、通常のクラスと同じように動作すると常に考えていましたが、2 つのクラス間で暗黙の継承が発生していると思いますか?

クラス'Application'があるとします。初期化するには、コンストラクターで特定の設定が必要です。また、設定の数が多すぎて、独自のクラスに配置する必要があると仮定しましょう。

このシナリオの次の2つの実装を比較してください。

実装1：

実装2：

私にとっては、2番目のアプローチが非常に望ましいです。2つのクラス間の関係を強く強調しているため、読みやすくなっています。どこでもApplicationクラスをインスタンス化するコードを書くと、2番目のアプローチはよりきれいに見えます。

ここで、Settingsクラス自体に同様の「関連」クラスがあり、そのクラスにも同様のクラスがあると想像してみてください。そのようなレベルを3つだけ実行すると、「ネストされていない」場合にクラスの命名が手に負えなくなります。ただし、ネストした場合でも、物事はエレガントなままです。

上記にもかかわらず、StackOverflowで、ネストされたクラスは外部に表示されない場合にのみ正当化されると言っている人を読んだことがあります。つまり、それらが含まれているクラスの内部実装にのみ使用される場合です。よく言われる反対意見は、クラスのソースファイルを含むサイズを肥大化させることですが、部分的なクラスはその問題の完璧な解決策です。

私の質問は、ネストされたクラスの「公開された」使用になぜ警戒するのかということです。そのような使用に反対する他の議論はありますか？

Delphi 2009 でカスタム TObjectList の子孫を取得しました。その列挙子を少し操作して、MoveNext メソッドにフィルタリング機能を追加して、特定のオブジェクトをスキップさせたいと考えています。MoveNext は、仮想メソッドである DoMoveNext によって呼び出されるため、これをオーバーライドすることは難しくありません... 1 つのことを除いて。TObjectList の TEnumerator は独自のクラスではありません。TObjectList 宣言内でネストされた型として宣言されています。

子孫クラスで TEnumerator.DoMoveNext をオーバーライドする簡単な方法はありますか、または TEnumerator 全体を再実装する必要がありますか? それほど大きなクラスではありませんが、できれば冗長性を最小限に抑えたいと思います...

私が取り組んでいる現在のクラス ライブラリには、「フィールド」から継承され、読みやすさを維持するためにネストされる 50 を超える特定の「フィールド」タイプを持つ基本クラス (フィールド) があります。例えば...

これまでのところ、すべて問題ないように見え、次のようにコードを使用できます。

しかし、なぜこれも同様に機能するのでしょうか? コンパイラ/IDE インテリセンスがこれらの「FieldA」を連鎖し続けることを可能にするために、ここで何が起こっているのでしょうか?

決してアプリケーションを壊すわけではありませんが、それは独特だと思いました。Boo (ライブラリに使用されている実際の言語) でも同じことを行います。

「ヘルパー」クラスを拡張するパブリック静的内部クラスを設計することで、コードがよりタイプセーフになり、私の意見では読みやすくなる場所がいくつかあることがわかりました。たとえば、「SearchCriteria」クラスがあるとします。私が検索するさまざまなものには多くの共通点があります (検索語と検索語の種類のグループ、日付範囲など)。これを静的な内部クラスで拡張することにより、拡張機能と検索可能なものを緊密に結合します。特定の違いがあるクラス。これは理論的には悪い考えのように思えますが (密結合が悪い!)、拡張はこの検索可能なクラス (1 つのクラス、1 つの目的) に固有のものです。

私の質問は、あなたの経験では、静的内部クラス (またはあなたの言語に相当するもの) を使用することで、コードが読みやすく/保守しやすくなりましたか、それとも EOF で噛まれてしまいましたか?

また、これがコミュニティ wiki の資料であるかどうかもわかりません。

JUnit テストでプライベート メンバーにアクセスするために、ネストされたクラスを使用します。それらは常に「TestProxy」という名前です。

ビルド時にmaven2を使用してそれらを削除し、jarファイルに含めないようにしたいと思います。

• 設定オプションはありますか?
• プラグインでできる？もしそうなら、プロトタイプはいいですね！;-)

ありがとう

編集: なぜプライベート メソッドを使用するのですか? サードパーティのシステムからデータを注入する必要がありますが、JUnit テストの実行ごとに呼び出すことはできません。そして、プライベート データのパブリック セッターは本当に必要ありません。そうしないと、遅かれ早かれ別のプログラマーがそれを悪用する可能性があります。

どうしてこれなの？いくつかの拡張メソッドをロックダウンして、自分のクラスの 1 つだけで使用できるようにできると本当に便利だと思います。特定の拡張メソッドをどこでも利用できるようにしたくありません...そして、それらは通常の静的メソッドよりもはるかに見栄えがします:P

明確にするために：

これらの拡張メソッドが必要な理由は、DataGridView を持つ Form を拡張しているためです。そして、私は次のような行に非常にうんざりしています:

私ができるように拡張メソッドが欲しい

つまり、この拡張メソッドは、このクラスの外ではまったく役に立ちません。しかし、それはコードをずっときれいにします。もちろん、通常のメソッドも作成できます。これは不可能だったので、最終的にそれを行いました。

とにかく、拡張メソッドを作成して使用できる場所にこのような制限を設けることを選択した理由について、誰かが適切な議論を持っているかどうかを知りたいと思っていました. 静的クラスになければならないのは完全に理にかなっています。ネストされた静的クラスに入れることはできません...少なくとも私には...

私の同僚は、Eclipseのコードフォーマットと警告の設定のいくつかをより厳密にすることを提案しました。これらの変更の大部分は理にかなっていますが、Javaでこの1つの奇妙な警告が表示されます。「問題」を再現するためのテストコードは次のとおりです。

!!!とのライン 新しい警告設定を使用して、Eclipseでこの警告が表示されます。

囲んでいるコンストラクターWeirdInnerClassJavaWarning.InnerClass（）へのアクセスは、合成アクセサーメソッドによってエミュレートされます。可視性を高めると、パフォーマンスが向上します。

これは何を意味するのでしょうか？「プライベート静的クラス」を「保護された静的クラス」に変更すると、警告が消えます。これは私には意味がありません。

編集：私はついに「正しい」修正を見つけました。ここでの本当の問題は、このネストされたプライベート静的クラスにパブリックコンストラクターがないことです。その1つの調整により、警告が削除されました。

クラスをプライベートのネストされたクラスにし（したがって、囲んでいるクラスのサブクラスを含め、他のクラスがそのクラスにアクセスできないようにします）、静的クラスにします。

ネストされたクラスをプライベートではなく保護することが「問題」を修正する別の方法である理由はまだわかりませんが、それはEclipseの癖/バグかもしれません。

（申し訳ありませんが、より明確にするために、InnerClassではなくNestedClassと呼ぶべきでした。）