新しいクラスを宣言する代わりにネストされたクラスを使用することには欠点がありますか？
同僚がJavaアプリケーションに加えた変更についてコードレビューを行っています。私はあまりよく知らないもの、つまりネストされたクラスを見つけました。
コードを確認すると、ネストされたクラスが通常のクラスのように使用されているようです-同僚にそれを尋ねたところ、ネストされたクラスとして配置した理由は、ソース管理の問題が原因でした。彼女がそれをコーディングした日に新しいクラスを作成することから。
今、これは私を悩ませています-この要素をコードに導入する理由はありませんが（アプリケーションでネストされたクラスを使用するクラスはほとんどありません）、私が考えることができる欠点もありません。入れ子になったクラスは、非常に緩やかに、元のクラスに関連しており、入れ子になったクラスが独立したクラスになるようにコードを書き直すには時間がかかります。
このネストされたクラスが独立するように、同僚にコードをやり直させる正当な理由はありますか？または、私は彼らに重要ではない何かに時間を無駄にするように頼んでいるだけでしょうか？
この方法でのクラスの実装には機能的な影響はないように見えることに注意してください。つまり、引数は、機能しないことを証明しようとするのではなく、ベストプラクティスまたは構造の悪さからのものでなければなりません（機能するため-それが適切かどうかわからない）。
ネストされたクラスがプライベートの場合、それはそのクラスの実装の詳細の一部です。このようなクラスが存在する可能性のある正当な理由はいくつかあります。データのカプセル化、2つの名前を持つインターフェースのプライベート実装の証明。
含まれているクラスの外部でクラスにアクセスできる場合、単一責任の原則が機能する可能性があります。その内部クラスは本当に外部クラスの責任ですか？あなたはそれが大まかに関連しているとだけ言うので、答えはおそらくありません。
入れ子のクラスはそれらを密結合します。これにより、2つのクラスに相当する機能が含まれるようになり、外部クラスがより複雑になります。そして、その外部クラスには2つの責任があります。これはすべて、チェックインの問題が原因です。
したがって、この場合もコードを再構築して、その内部クラスを、それが属する独自のファイルに移動することをお勧めします。
ソース管理の問題が原因で作成されたものであり、設計上の考慮事項よりもさらに深刻であると考えると、そうです。あなたはおそらくそれをリファクタリングするべきです。
ただし、コードが機能し、「ネストされたクラスがない」コーディングスタイルルールがない場合は、そのためにコードレビューに失敗することはお勧めしません。
私はコード品質の測定についてこの漫画を投稿する義務があります。
独立したクラスの代わりにネストされたクラスを作成する唯一の理由が事務的な制限であった場合（ソース管理は自動化された書記官です）、ネストされたクラスを独立したクラスにリファクタリングする必要があります。他に理由がない場合、これは簡単なリファクタリングになるはずです。