「ヘルパー」クラスを拡張するパブリック静的内部クラスを設計することで、コードがよりタイプセーフになり、私の意見では読みやすくなる場所がいくつかあることがわかりました。たとえば、「SearchCriteria」クラスがあるとします。私が検索するさまざまなものには多くの共通点があります (検索語と検索語の種類のグループ、日付範囲など)。これを静的な内部クラスで拡張することにより、拡張機能と検索可能なものを緊密に結合します。特定の違いがあるクラス。これは理論的には悪い考えのように思えますが (密結合が悪い!)、拡張はこの検索可能なクラス (1 つのクラス、1 つの目的) に固有のものです。
私の質問は、あなたの経験では、静的内部クラス (またはあなたの言語に相当するもの) を使用することで、コードが読みやすく/保守しやすくなりましたか、それとも EOF で噛まれてしまいましたか?
また、これがコミュニティ wiki の資料であるかどうかもわかりません。
私には完全に合理的に聞こえます。それを内部クラスにすることで、検索が容易になり、検索可能なクラスが変更されたときにレビューの対象となります。
密結合は、一方がたまたま他方を呼び出しているという理由だけで、実際には一緒に属していないものを結合する場合にのみ悪くなります。たとえば、あなたの場合のように、一方が他方をサポートするために存在する場合、それは「結束」と呼ばれ、それは良いことです.
内部クラスを使用する際の唯一の注意点は、内部クラスを定義するときに、その機能を他の場所で使用する必要がないことを確認してください。その機能は必然的に外部クラスと結合されます。すべてがまったく同じsetOrderyByNameDesc()メソッドを実装する内部クラスの束になってしまうことは望ましくありません。
クラスは再利用の単位ではないことに注意してください。したがって、クラス間のいくつかの結合は正常であり、予想されます。再利用の単位は通常、関連するクラスのコレクションです。
Pythonには、さまざまな構造があります。
パッケージ。それらにはモジュールが含まれています。これらは基本的に、Pythonの機械が少し投入されたディレクトリです。
モジュール。それらにはクラス（および関数）が含まれています。これらはファイルです。密接に関連するクラスをいくつでも含めることができます。多くの場合、「インナークラス」ビジネスはこのレベルで処理されます。
クラス。これらには、内部クラス定義とメソッド関数を含めることができます。時々（あまり頻繁ではありませんが）内部クラスが実際に使用されることがあります。クラス間のモジュールレベルの結合は通常完全に明確であるため、これはまれです。
「緩い結合」のポイントは、2つのクラスを分離して、「SearchCriteria」クラスでコードが変更された場合に、他のクラスで何も変更する必要がないようにすることです。あなたが話している静的な内部クラスは、コードの保守を悪夢にする可能性があると思います。SearchCriteriaを1つ変更すると、すべての静的クラスを検索して、更新のために現在壊れているクラスを特定できます。個人的には、何らかの理由で本当に必要な場合を除いて、そのような内部クラスには近づかないでしょう。