最近、メソッドが多すぎて太りそうなクラスを考えていました。
レガシーコード...
これには、さまざまな「Etntities」ですべてのタイプの CRUD を実行する多くのビジネス ロジックに関するメソッドがあります。
私が考えていた
質問: このようなリファクタリングの長所と短所を挙げていただけますか?つまり、ファット コンクリート クラスを部分クラスにして、よりスリムな部分クラスに分割します。
私が考えることができる 1 つの長所は、ソース管理における競合/マージの削減です。並列チェックアウトの数と、開発者が自分の作業をチェックインするときに常に発生するマージの頭痛の種を減らすことができます。多くの開発者が同じクラスで頻繁に作業している場合、大きなプロだと思います。
クラスを処理するための単純さについてのみ話していると思います。コンパイル時に同じ結果が生成されるため、パフォーマンスまたは動作の長所と短所はあってはなりません。
クラス、構造体、またはインターフェイスの定義を 2 つ以上のソース ファイルに分割することができます。各ソース ファイルにはクラス定義のセクションが含まれており、アプリケーションのコンパイル時にすべての部分が結合されます。
今、私が考えることができる長所と短所に答えます（単純さについてのみ）：
私はリファクタリングに行きます。特に、ファイルを開く代わりに F12 (またはその他のキー) をクリックしてメソッドに移動する必要がある、IDE によって提供されるすべての機能を考慮してください。
大規模なクラスを部分的なクラスに分割すると、短期的には作業が楽になる可能性がありますが、クラスで発生しているコードの膨張に対する適切な解決策ではありません。
私の経験から、既存の大きなクラスを分割することの唯一の利点は、そのクラスで他の開発者と作業するときにコードを常にマージする必要がないことです。ただし、無関係な機能が1つのクラスにパッケージ化されるというコアの問題がまだあります。
部分的なクラスへの分解を、完全なリファクタリングの最初のステップとして扱うことをお勧めします。関連するメソッドとメンバーを（物事を壊すことなく）独自の部分クラスに簡単に抽出できる場合は、これを基礎として使用して、完全にスタンドアロンのクラスを作成し、それらの間の関係を再考できます。
編集：このアドバイスは、何年にもわたる「ここにもう1つのメソッドを追加するだけ」の結果として、レガシーコードが1つのクラスで無関係な機能を持っているという仮定の下で与えられていることを明確にする必要があります。機能が部分的なクラスに分散しているのには本当の理由があります。たとえば、以前は1つのファイルに非常に大きなインターフェイスがあるコードに取り組んだことがありますが、製品の機能の領域に基づいてすべてのメソッドが部分的なクラスにグループ化されています。大丈夫だと思います。
クラスをリファクタリングする方法が気になる場合は、SOLID設計原則を読むことをお勧めします。
単一の責任の原則 (SOLID の S) に焦点を当てる必要があると思います。これは、オブジェクトが 1 つの責任のみを持つべきであると述べています。
私の答えは、部分クラスを使用することが有益かどうかというあなたの質問に直接答えているわけではないと思いますが、コードを整理する方法について少なくともいくつかのアイデアを与えるはずの SOLID 設計原則に焦点を当てると信じています。
部分クラスは、カスタム コードを上書きせずに拡張したいコードが生成された (そしていつでも再生成できる) クラスを拡張する方法としてのみ見られます。これは、フォーム生成コードや Entity Framework DbContext 生成コードなどで確認できます。
大規模なレガシー クラスのリファクタリングは、単一の責任を個別のクラスにグループ化して分離することによって行う必要があります。