41

ヘルパー クラスを独自のファイルに配置するために、部分クラス修飾子をしばらく使用してきました。

今日、私たちは新しい人を迎えました。彼が最後に一緒に働いたチームでは、別のファイルにあるヘルパー クラスを変更すると、メインの部分クラス ファイルが変更に対応できなくなるため、部分クラスを許可していなかったとのことでした。 . また、ヘルパー クラスをメイン クラス内に配置することは、最後の手段としてのみ許可されていたため、すべてが分離されたままでした。

どう思いますか？このような部分クラスの使用に問題はありますか、それとも好みの問題ですか?

たとえば、私は通常、次のようなものを持っています。

  • MainClass.cs
  • MainClass.Helper1.cs
  • MainClass.Helper2.cs

... 

// Inside of MainClass.cs I have code like this:

public abstract partial class MainClass
{
    // ...
}

// Then in the MainClass.Helper1.cs I have:

partial class MainClass
{
   private class Helper1
   {
       // ...
   }
}
4

10 に答える 10

31

部分クラスは、主にデザイナーなどのコードジェネレーターの使用のためのものです-しかし、私はあなたが引用したアプローチを使用します-特にオブジェクトが複数の(自明ではない)インターフェイスを実装する場合、インターフェイスの実装ごとに1つのファイルに分割すると便利です. 私は通常、静的メソッド用のファイルも持っています。これは通常、インスタンス メソッドとは十分に異なるため、分離が保証されます。

于 2008-12-08T23:50:17.353 に答える
7

個人的には、このように部分クラスを使用することに問題はないと思いますが、それは私自身の意見です。「悪い習慣」のように見える唯一のことは、クラスに「Helper1」および「Helper2」という名前を付けることです (ただし、これは明確にするための例に過ぎない可能性があります)。

このような部分クラスを使用している場合は、(無料の) アドインvsCommands (Visual Studio 2008 用) を確認してください。これにより、プロジェクト ファイルを編集せずに、ソリューション エクスプローラーで (デザイナー ファイルと同様に) ファイルを非常に簡単にグループ化できます。

于 2008-12-08T23:10:29.210 に答える
5

簡単な答え: すべてのクラスがコードである場合、ヘルパー クラスは実際には必要ないため、パーシャルの必要性が無効になります。

長い答え: あなたの実践が明らかに間違っていると言うものがあるかどうかはわかりません。私の経験から、クラス全体を構成するいくつかの異なるファイルがある場合は、そうする正当な理由が必要です。

  1. 部分クラスは可読性をいくらか低下させます
  2. クラスに複数のヘルパー クラスが含まれている場合、それは設計が不十分である可能性があります。作成したクラスのヘルパー クラスを作成しなければならない状況に遭遇したことはないと思います。

ただし、部分クラスを使用する最も良い理由は、カスタム作業を失うことなくファイルを再生成できるようにするためのコード生成だと思います。

于 2008-12-08T23:10:36.030 に答える
2

私の経験では、通常のクラスと部分クラスの間に違いはありません。設計でクラスの大規模な構造が必要な場合、またはより多くのインターフェイスを実装する必要がある場合は、部分クラスを使用してください。どちらも同じです。

于 2012-12-28T02:19:14.417 に答える
2

私は部分クラスの大ファンではないので、自分では使用しません。

ただし、LINQ to SQL デザイナー コードに何かを追加する場合は、それらが役に立ち、使用しても問題ないと思いますが、それとは別に、その目的のためにコードを別のファイルに広げているかどうかを確認します。 、読み取りと管理が非常に難しくなる可能性があります。

おそらく、クラスが多くのファイルに分割されている場合、クラスが多くのことを行っている可能性があります...ただの考え:)

于 2008-12-08T23:09:49.103 に答える
2

私も実際に同じことをしたことがあります。すでに述べたように、部分クラスを解読すると、読みやすさにわずかな影響があります。

デカップリングは、私がこのソリューションを気に入っている主な理由です。プライベートな内部クラスは、それを表示したり使用したりすることができないため、他のすべてとの結合ははるかに少なくなります (ただし、親クラスのプライベート データにアクセスする可能性について話している可能性がありますが、これは通常悪い考えです)。

于 2008-12-09T00:10:51.600 に答える
1

上記と同様の理由で、通常は部分クラスを使用しません。

しかし！頻繁ではありませんが、クラス (通常は外部クラス) の単体テストを広範囲に行うと、巨大な単体テスト クラスが作成されることがあります。単体テスト クラスを部分クラスに分割すると、見やすく理解しやすくなります。

複数のインターフェイスから継承する場合のグループ化の考え方と同様に、単体テストを関数ごとにグループ化できます。

于 2014-09-18T10:39:45.413 に答える
1

入れ子になったクラスが十分に大きく、それらを独自のファイルに分割する必要があると感じる場合、それらはおそらく入れ子になったクラスであってはなりません。代わりに、MainClass と同じ名前空間の内部メンバーにします。

部分クラスは実際にはコード ジェネレーターをサポートするためだけに存在し、それらを使用してプログラマーが記述したコードを扱いやすいチャンクに分割することは、設計が不十分であることを示しています。

部分クラスでやってはいけないことの面白い例については、この記事を参照してください。

于 2008-12-08T23:42:23.420 に答える
0

ほとんどの場合、部分クラスはコード生成でのみ使用するため、クラスの動作を、カスタマイズが必要でコード生成に含まれない分離されたクラスで拡張できます。

于 2008-12-09T04:33:58.637 に答える
0

ツールのデフォルトの動作は、Coupling Not Cohesion の低レベル形式を作成することであることを覚えておくとよいと思います。懐疑的に見て、上記の特定の理由のいくつかで意味がない限り、オーバーライドしてください。しかし、それは良いデフォルトの動作ではありません。

于 2008-12-09T00:36:16.370 に答える