C#部分クラスを使用するのが適切なのはいつですか?


回答:


423

部分クラスの最大の用途は、コードジェネレーター/デザイナーの作業を容易にすることです。部分クラスを使用すると、ジェネレーターは、必要なコードを簡単に出力でき、ユーザーによるファイルの編集を処理する必要がありません。同様に、ユーザーは2番目の部分クラスを使用して、クラスに新しいメンバーで注釈を付けることができます。これにより、問題を分離するための非常にクリーンなフレームワークが提供されます。

それを見るより良い方法は、部分クラスの前にデザイナーがどのように機能したかを確認することです。WinFormsデザイナは、コードを変更しないことについて強くコメントされたコメントで、領域内のすべてのコードを吐き出します。後で処理するために生成されたコードを見つけるには、あらゆる種類のヒューリスティックを挿入する必要がありました。これで、designer.csファイルを開くだけで、デザイナーに関連するコードのみが含まれていると確信できます。


70
部分的なクラスの前にどれほど悪いことがあったかについての悪夢を私に与えてくれた-1をあなたに与えたくなった:)
Jon B

9
@ジョン:)、私たちはすべてそれらの悪夢を持っていたと思います。
JaredPar 2010

18
36K行を超えるコードジェネレーター(またはおそらくそれ以上、正確には覚えていません)を作成すると、ソースが開かれたときにエディターがブロックされました。部分クラスにより、生成されたコードを4 GBのRAMなしで見ることができました。
Luca

6
これは、量産コードでの部分クラスの唯一の使用法であると言えるでしょう。私はそれを受け入れますが、リファクタリングに役立つかもしれません。
ゴードンマカリスター

5
@ゴードン-HumerGuの答えは私が反対するのはかなり難しいと思う別のものです。部分クラスは、C#でインターフェイスを実装し、インターフェイスメンバーをクラスメンバーから明確に分離するのに非常に便利です。stackoverflow.com/ questions
3601901

262

別の用途は、異なるインターフェースの実装を分割することです。例:

partial class MyClass : IF1, IF2, IF3
{
    // main implementation of MyClass
}


partial class MyClass
{
    // implementation of IF1
}

partial class MyClass
{
    // implementation of IF2
}

6
いい視点ね!これは私が以前に行って忘れていたものですが、インターフェイスメンバーを明確に表示するための優れた方法です(特にC#では、VB.NETがImplementsキーワードを使用してメソッドがインターフェイスに属していることを示すため)
STW

2
非常に良い点は、各インターフェースは開発者が実装できることです。また、インターフェースの実装を簡単に見つけるための良い方法でもあります。
kokabi 2014

3
クラスの宣言順にIF1とIF2のどちらであるかをどうやって知るのですか?
kuldeep

17
良い使い方ですが悪い例です。なぜああなぜあなたは1つの部分クラス上のすべてのインターフェイスを定義し、他の部分クラスで、同じインタフェースを実装するでしょう..?
inkredibl

4
ハ、私はこの質問を調べて、インターフェース実装の分離が部分クラスの標準的な使用であるかどうかを確認しました。他の人がそれを良いアイデアだと思っているのを見てうれしい。インターフェース定義を、それを実装する部分クラスと一緒に配置することについて、@ inkrediblに同意します。
キム

172

他の答えは別として...

神のクラスをリファクタリングする際の足がかりとして役立つことがわかりました。クラスに複数の責任がある場合(特に、コードファイルが非常に大きい場合)、コードを整理してリファクタリングするための最初のパスとして、責任ごとに1xの部分クラスを追加すると効果的です。

これは、実行動作に実際に影響を与えずにコードを読みやすくするのに役立つため、非常に役立ちます。また、責任が簡単にリファクタリングされたり、他の側面と密接に絡み合ったりする時期を特定するのにも役立ちます。

しかし-明確にする-これは開発の終了時に、あなたはまだ、クラスごとの(1人の責任たい、まだ悪いコードではありませんパーシャルクラスごとに)。それは単なる踏み石です:)


23
非常に素晴らしい:「...開発の最後でも、クラスごとに1つの責任が必要です(部分クラスごとではありません)...」
kokabi

私には、それは良いコーディングスタイルではありませんが、悪いコードをより見栄えよくすることができます。
themefield

私はこれに完全に同意します。それは悪いコードを修正するための良い足がかりです。神のクラスは、複数のファイルに分散しているかどうかにかかわらず、神のクラスの天気です。
神保

84
  1. 部分クラスを使用する複数の開発者複数の開発者が同じクラスで簡単に作業できます。
  2. コードジェネレータパーシャルクラスは、主にコードジェネレータによって使用され、さまざまな問題を個別に保持します。
  3. 部分メソッド部分クラスを使用して、開発者がメソッドを単純に定義し、他の開発者がそれを実装できる部分メソッドも定義できます。
  4. 部分的なメソッド宣言のみコードはメソッド宣言のみでコンパイルされ、メソッドの実装が存在しない場合、コンパイラーはそのコードを安全に削除でき、コンパイル時エラーは発生しません。

    ポイント4を検証するには、Winformプロジェクトを作成し、Form1コンストラクターの後にこの行を含めて、コードをコンパイルしてみます。

    partial void Ontest(string s);

部分クラスを実装する際に考慮すべきいくつかのポイントを次に示します。

  1. 部分クラスの各部分で部分キーワードを使用します。
  2. 部分クラスの各部分の名前は同じである必要がありますが、部分クラスの各部分のソースファイル名は異なる場合があります。
  3. 部分クラスのすべての部分は同じ名前空間にある必要があります。
  4. 部分クラスの各部分は同じアセンブリまたはDLLにある必要があります。つまり、異なるクラスライブラリプロジェクトのソースファイルに部分クラスを作成することはできません。
  5. 部分クラスの各部分は、同じアクセシビリティを持つ必要があります。(例:プライベート、パブリック、または保護)
  6. 部分クラスのクラスまたはインターフェースを継承すると、その部分クラスのすべての部分に継承されます。
  7. 部分クラスの一部がシールされると、クラス全体がシールされます。
  8. 部分クラスの一部が抽象クラスの場合、クラス全体が抽象クラスと見なされます。

1
Entity Frameworkから作成された部分クラスの編集に問題はありますか?テーブルから作成したクラス名をいくつか変更したい。
MarceloBarbosa

私も同じ懸念を抱いています。Entity Frameworkがデータベースをコードファーストの観点/アプローチ/実装から構築するために基本的に使用するモデルを構築するときに、部分クラスが「もしあれば」の利点を知りたい...
Chef_Code

@JimBalterこのリンクmsdn.microsoft.com/en-us/library/6b0scde8(v=vs.110).aspxをご利用ください。これは、実装が存在しない場合、コンパイラはコードの一部を削除し、コンパイル時エラーは受信されないことを示しています。
hellowahab

部分クラスのクラスまたはインターフェースを継承する場合、その部分クラスのすべての部分によって継承されます。
The Red Pea

56

1つの優れた使用法は、同じクラスに属する手書きのコードから生成されたコードを分離することです。

たとえば、LINQ to SQLは部分クラスを使用するため、特定の機能(多対多の関係など)の独自の実装を記述でき、それらのカスタムコードは、コードを再生成しても上書きされません。

WinFormsコードについても同様です。Designerで生成されたコードはすべて、通常は変更しない1つのファイルに入っています。手書きのコードは別のファイルに入ります。そうすれば、Designerで何かを変更しても、その変更が吹き飛ばされることはありません。


21

パーシャルクラスが自動コード生成で使用されることは事実です。1つの用途は、数千行のコードを含む大きなクラスファイルを維持することです。クラスが1万行になる可能性があることや、別の名前で新しいクラスを作成したくない場合は、決して知りません。

public partial class Product
{
    // 50 business logic embedded in methods and properties..
}

public partial class Product
{
    // another 50 business logic embedded in methods and properties..
}
//finally compile with product.class file.

別の考えられる用途は、複数の開発者が異なる場所に格納されているため、同じクラスで作業できることです。人々は笑うかもしれませんが、それが時々一握りであることができることをあなたは決して知りません。

Product1.cs

public partial class Product
{
    //you are writing the business logic for fast moving product
}

Product2.cs

public partial class Product
{
    // Another developer writing some business logic...
}

それが理にかなっていることを願っています!


13

部分クラスは複数のファイルにまたがっています。

C#クラス宣言で部分修飾子をどのように使用できますか?

部分クラスを使用すると、クラスを物理的に複数のファイルに分離できます。これは多くの場合、コードジェネレーターによって行われます。

通常のC#クラスでは、同じプロジェクトの2つの別々のファイルでクラスを宣言することはできません。しかし、partial修飾子を使用すると、できます。

これは、一方のファイルが一般的に編集され、もう一方のファイルが機械で生成されるか、ほとんど編集されない場合に役立ちます。

明確にするための例を次に示します。

class Program
{
    static void Main()
    {
        A.A1();
        A.A2();
    }
}

ファイルA1.csの内容:C#

using System;

partial class A
{
    public static void A1()
    {
        Console.WriteLine("A1");
    }
}

ファイルA2.csの内容:C#

using System;

partial class A
{
    public static void A2()
    {
        Console.WriteLine("A2");
    }
}

出力:

A1
A2

ここでは部分的に入力する必要があります。

partial修飾子を削除すると、次のテキストを含むエラーが発生します。

[名前空間 ' <global namespace>'には既に' 'の定義が含まれていますA]。

ヒント:

これを修正するには、partialキーワードを使用するか、クラス名の1つを変更します。

C#コンパイラは部分クラスをどのように扱いますか?

上記のプログラムを逆アセンブルすると(IL Disassemblerを使用)、ファイルA1.csおよびA2.csが削除されていることがわかります。クラスAが存在することがわかります。

クラスAは、メソッドA1とA2を同じコードブロックに含みます。2つのクラスが1つに統合されました。

A1.csおよびA2.csのコンパイル結果:C#

internal class A
{
    // Methods
    public static void A1()
    {
        Console.WriteLine("A1");
    }

    public static void A2()
    {
        Console.WriteLine("A2");
    }
}

概要

  • 部分クラスは、特定のC#プログラミング状況を簡略化できます。
  • これらは、Windowsフォーム/ WPFプログラムを作成するときにVisual Studioでよく使用されます。
  • マシン生成のC#コードは別です。
  • または、ここで説明全体を見つけることができます。

2
良い例であり、十分に文書化されています。
Chef_Code 2016

1
これは、imoに従う最も簡単な説明です。
Yusha 2018年

12

巨大なクラスで作業しているとき、またはチームで作業しているときは、すべてをできるだけクリーンに保ち、オーバーライドせずに(または常に変更をコミットして)編集できます。


11

部分クラスの主な用途は、生成されたコードです。WPF(Windows Presentation Foundation)ネットワークを見ると、UIをマークアップ(XML)で定義しています。そのマークアップは部分クラスにコンパイルされます。独自の部分クラスをコードに入力します。


8

効果的なリファクタリングに適さない十分に大きなクラスがある場合は、クラスを複数のファイルに分割すると、整理された状態を維持できます。

たとえば、ディスカッションフォーラムと製品システムを含むサイトのデータベースがあり、2つの異なるプロバイダークラスを作成したくない場合(明確にするために、プロキシクラスと同じものではありません)、次のことができます。次のような異なるファイルに単一の部分クラスを作成します

MyProvider.cs-コアロジック

MyProvider.Forum.cs-フォーラム専用のメソッド

MyProvider.Product.cs-製品のメソッド

これは、物事を整理しておくためのもう1つの方法です。

また、他の人が言ったように、クラスが次に再生成されるときに追加が破棄されるリスクを冒すことなく、生成されたクラスにメソッドを追加する唯一の方法です。これは、テンプレート生成(T4)コード、ORMなどで便利です。


2
私はパーシャルをリファクタリングへの足がかりとして主張しますが(私の答えの要点)、クリーンなコードを作成するための実際の解決策として提案することはしません。部分クラスがクラスの他の問題から明確に分離されている場合は、それをスタンドアロンクラスに昇格させるために余分な小さな労力を費やしてみませんか?
STW

@STW:多くのオブジェクトインスタンスが作成され、さまざまなタスクに使用される場合があります。さまざまなタスクを異なるクラスに分離するには、どのインスタンスがどのタスクに使用されたかを追跡する必要があります。ソースモジュール間でコードのブロックを単に移動するよりもはるかに大きな作業になる可能性があります。
スーパーキャット2010

4
@supercat-私は完全に理解していますが、そのようなスパゲッティのクリーンアップを行う必要があります。私はそのタイプのコードを正確にクリーンアップすることで多くの傷を負っています。これらの種類の混乱は、問題を継続的に発生させることが保証されており、長期的な見返りは、問題を単に無視することに比べて莫大です。そのようなコードは「におい」ではなく、ゴミ捨て場のようです。
STW

1
@supercat-「パーシャルが他の問題から明確に分離されている場合...それは小さな努力です」でそれを修飾しようとしました。通常、長期維持に大きな節約untangling意志の痛みを通って行く、そうでない場合はロゲイン
STW

2
ちなみに、最近はRoslynを変更しようと遊んでいますが、部分クラスを多用して書かれています。Roslynの主要なクラスの多くは、複数のファイルの部分クラスとして定義されています。そして、Roslynは、少なくとも私が非常に賢いC#プログラマであると考える人々によって書かれました。
RenniePet 2018

8

プリコンパイラ指令の代替として。

プリコンパイラディレクティブ(つまり#IF DEBUG)を使用すると、実際のリリースコードと混ざって、ぎこちないコードが作成されます。

このコードを含む個別の部分クラスを作成し、部分クラス全体をディレクティブでラップするか、そのコードファイルをコンパイラに送信しないようにする(事実上同じことを行う)ことができます。


Monogameはこの戦略を使用します。
Zamboni

6

サービス参照は、生成されたコードをユーザーが作成したコードから分離するために部分クラスが役立つもう1つの例です。

サービス参照を更新するときに、サービスクラスを上書きせずに「拡張」できます。


6

私が見た別の用途は、

データアクセスロジックに関する大きな抽象クラスの拡張

Post.cs、Comment.cs、Pages.csという名前のさまざまなファイルがあります...

in Post.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of post..
}


in Comment.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of comment..
}

in Pages.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of Pages..
}

6

ほとんどの人partialは、生成されたコードファイルがあるクラスまたはインターフェイスにのみ使用する必要があると述べています。私は同意しません、そしてここに理由があります。

1つの例として、C#のSystem.Mathクラスを見てみましょう。それはclassです。70以上のメソッドをすべて同じ単一のコードファイルに詰め込もうとはしません。維持するのは悪夢です。

各数学メソッドを個別の部分クラスファイルに配置し、すべてのコードファイルをプロジェクトのMathフォルダーに配置すると、整理が大幅に簡単になります。

同じことが、多様な機能を大量に持つ他の多くのクラスにも当てはまります。たとえば、PrivateProfile APIを管理するためのクラスは、単一のプロジェクトフォルダー内の部分クラスファイルのクリーンなセットに分割されることでメリットが得られる場合があります。

個人的には、ほとんどの人が「ヘル​​パー」または「ユーティリティ」クラスと呼ぶものを、メソッドまたはメソッド機能グループごとに個別の部分ファイルに分割します。たとえば、あるプロジェクトでは、文字列ヘルパークラスにほぼ50のメソッドがあります。これは、リージョンを使用しても、長く扱いにくいコードファイルになります。メソッドごとに個別の部分クラスファイルを使用すると、保守が大幅に簡単になります。

これを行うときは、部分クラスの使用に注意し、プロジェクト全体ですべてのコードファイルのレイアウトを統一します。たとえば、クラスのパブリック列挙型とクラスのプライベートメンバーをCommon.csまたは同様の名前のファイルに配置し、それらが含まれている部分的なファイルのみに固有でない限り、ファイル全体に分散させるのではなく、

クラスを個別のファイルに分割すると、現在のファイルの2つの異なるセクションを同時に表示できるテキストエディターのスプリッターバーも使用できなくなることに注意してください。


4

部分クラスを使用すると、ソースファイルを追加するだけで、適切に設計されたプログラムに機能を追加できます。たとえば、ファイルインポートプログラムは、既知のファイルを処理するモジュールを追加することで、それらを追加するように設計できます。たとえば、メインのファイルタイプコンバーターには小さなクラスを含めることができます。

部分的なパブリッククラスzzFileConverterRegistrar
    イベントレジスター(ByVal mainConverter as zzFileConverter)
    Sub registerAll(ByVal mainConverter as zzFileConverter)
        RaiseEventレジスター(mainConverter)
    End Sub
終了クラス

1つ以上のタイプのファイルコンバーターを登録する各モジュールには、次のようなものが含まれます。

部分的なパブリッククラスzzFileConverterRegistrar
    Private Sub RegisterGif(ByVal mainConverter as zzFileConverter)がMe.Registerを処理する
        mainConverter.RegisterConverter( "GIF"、GifConverter.NewFactory))
    End Sub
終了クラス

メインファイルコンバータークラスは「公開」されていないことに注意してください。アドインモジュールがフックできる小さなスタブクラスを公開するだけです。名前の競合のわずかなリスクがありますが、各アドインモジュールの「レジスタ」ルーチンが、処理するファイルのタイプに応じて名前が付けられている場合は、おそらく問題になりません。そのようなことが心配な場合は、登録サブルーチンの名前にGUIDを付けることができます。

編集/補遺 明確に言うと、これの目的は、さまざまな個別のクラスがメインプログラムまたはクラスにそれらを知らせる手段を提供することです。メインファイルコンバーターがzzFileConverterRegistrarで行う唯一のことは、そのインスタンスを1つ作成し、RegisterAllメソッドを呼び出して、Registerイベントを発生させることです。そのイベントをフックしたいモジュールは、それに応答して任意のコードを実行できます(それが全体のアイデアです)が、他の名前と一致する名前のメソッドを定義する以外に、zzFileConverterRegistrarクラスを不適切に拡張することでモジュールができることはありません。不適切に作成された拡張機能が別の不適切に作成された拡張機能を破壊する可能性は確かにありますが、その解決策は、拡張機能を破壊したくない人が単純に適切に書き込むことです。

部分クラスを使用せずに、メインファイルコンバータークラス内のどこかに、次のようなコードを含めることができます。

  RegisterConverter( "GIF"、GifConvertor.NewFactory)
  RegisterConverter( "BMP"、BmpConvertor.NewFactory)
  RegisterConverter( "JPEG"、JpegConvertor.NewFactory)

ただし、別のコンバーターモジュールを追加するには、コンバーターコードのその部分に入り、新しいコンバーターをリストに追加する必要があります。部分的な方法を使用すると、これは不要になりました。すべてのコンバーターが自動的に含まれます。


機能しますが、これらのモジュールを動的にロードする単純なプラグインシステムの方がはるかに優れており、モジュールが相互に破損するリスクを排除できます(再コンパイルを必要とせずに、実行時にモジュールをロードできます)
STW

Registerイベントをフックして自分自身を登録するルーチンを呼び出す以外は、モジュールがzz_クラスで何もしない場合、モジュールが相互に破損するリスクをかなり最小限に抑えることができます。プラグインでは存在しないと思われるリスクは何ですか。プラグインは、エンドユーザーが新しいモジュールを「プラグイン」する必要がある場合に最適です。ただし、すべての機能を1つのexeファイルにまとめたい場合もあります。新しく追加されたファイルへの参照を手動で追加しなくても、ソースファイルをプラグインできると便利です。
スーパーキャット2010

1
リスクは、「...何も実行しない場合[...]を除いて...」の行にかなりよく含まれており、セキュリティと安定性は完全に開発者の慣例に従っており、0%の保証を提供します。あなたのユースケースがそれらをコンパイルすることである場合(完全に有効で、良心のトレードオフである必要があります)、別のクラスでモジュールを定義し、いくつかのIModuleインターフェースを実装するだけではどうですか?
STW 2010

それは「賢い」状態が悪化した場合のように聞こえます。これらは「モジュール」ではなく、単一のクラスであり、コンパイル時に多くの動作と責任が1つにまとめられます。これを行うのより良い方法がたくさんあります-あなたは、実装するクラスのためのアセンブリにコンパイルをスキャンするためにリフレクションを使用することができIModule、あなたはMEF(多くのちょうど1)、などなどのようなプラグイン・フレームワークを使用することができます
STW

3

部分クラスは最近、複数の開発者が1つのファイルに追加するソース管理を支援し、新しいメソッドがファイルの同じ部分に追加されました(Resharperによって自動化)。

これらのgitへのプッシュにより、マージの競合が発生しました。新しいメソッドを完全なコードブロックとして受け取るようにマージツールに指示する方法が見つかりませんでした。

この点で部分クラスを使用すると、開発者は自分のファイルのバージョンに固執することができ、後で手動でマージすることができます。

例-

  • MainClass.cs-フィールド、コンストラクターなどを保持します
  • MainClass1.cs-開発者が実装する新しいコード
  • MainClass2.cs-新しいコードの別の開発者クラスです。

3

MSDNから:

1.コンパイル時に、部分型定義の属性がマージされます。たとえば、次の宣言について考えてみます。

[SerializableAttribute]
partial class Moon { }

[ObsoleteAttribute]
partial class Moon { }

これらは、次の宣言と同等です。

[SerializableAttribute]
[ObsoleteAttribute]
class Moon { }

以下は、すべての部分タイプ定義からマージされます。

  • XMLコメント

  • インターフェース

  • ジェネリック型パラメーター属性

  • クラス属性

  • 会員

2.別のこととして、ネストされた部分クラスも部分的になる可能性があります。

partial class ClassWithNestedClass
{
    partial class NestedClass { }
}

partial class ClassWithNestedClass
{
    partial class NestedClass { }
}

1

以下は、部分クラスのいくつかの利点のリストです。

UI設計コードとビジネスロジックコードを分離して、読みやすく、理解しやすくすることができます。たとえば、Visual Studioを使用してWebアプリケーションを開発し、新しいWebフォームを追加すると、「aspx.cs」と「aspx.designer.cs」の2つのソースファイルがあります。これらの2つのファイルは、partialキーワードを持つ同じクラスを持っています。「.aspx.cs」クラスにはビジネスロジックコードがあり、「aspx.designer.cs」にはユーザーインターフェイスコントロールの定義があります。

自動生成されたソースを使用する場合、ソースファイルを再作成せずにコードをクラスに追加できます。たとえば、LINQ to SQLを使用してDBMLファイルを作成します。これで、テーブルをドラッグアンドドロップすると、designer.csに部分クラスが作成され、すべてのテーブル列にクラスのプロパティが含まれます。UIグリッドにバインドするには、このテーブルにさらに列が必要ですが、データベーステーブルに新しい列を追加したくないので、その列の新しいプロパティを持つこのクラスの別のソースファイルを作成できます。部分クラスである。そのため、データベーステーブルとDBMLエンティティ間のマッピングには影響しますが、追加のフィールドを簡単に取得できます。つまり、システムが生成したコードをいじることなく、自分でコードを記述できるということです。

複数の開発者がクラスのコードを同時に書くことができます。

大きなクラスを圧縮することにより、アプリケーションをよりよく維持できます。インターフェースの実装に応じて複数のソースファイルを作成できるように、複数のインターフェースを持つクラスがあるとします。ソースファイルに部分クラスがある実装されたインターフェースを理解し、維持することは簡単です。


1

重要なサイズ/複雑さのネストされたクラスを含むクラスがあるときはいつでも、クラスにマークpartialを付け、ネストされたクラスを別のファイルに入れます。[クラス名]。[ネストされたクラス名] .csというルールを使用して、ネストされたクラスを含むファイルに名前を付けます。

次のMSDNブログでは、保守性のためにネストされたクラスで部分クラスを使用する方法について説明しています。http//blogs.msdn.com/b/marcelolr/archive/2009/04/13/using-partial-classes-with-nested-classes-for- maintenanceability.aspx


1

私はこの質問が本当に古いことを知っていますが、部分クラスに私の見解を追加したいと思います。

私が部分クラスを個人的に使用する1つの理由は、プログラム、特にステートマシンのバインディングを作成するときです。

たとえば、OpenGLはステートマシンであり、すべてグローバルに変更できるメソッドのヒープがありますが、私の経験では、非常に多くのメソッドが存在するOpenGLに似たものをバインドすると、クラスは容易に10k LOCを超える可能性があります。

部分的なクラスは、私のために、このダウンを破るだろう迅速な方法を見つけることで私を助けて。


0

部分クラスは主にコードジェネレーターを支援するために導入されているため、私たち(ユーザー)は、ASP.NETの.designer.csクラスのような生成されたクラスへのすべての作業/変更を失うことなく、生成するほとんどすべての新しいツールを生成しますコードLINQ、EntityFrameworks、ASP.NETは生成コードに部分クラスを使用するため、部分クラスとメソッドを利用してこれらの生成コードのロジックを安全に追加または変更できますが、部分クラスを使用して生成コードに要素を追加する前に十分に注意してくださいビルドを中断すると簡単ですが、ランタイムエラーが発生すると最悪です。詳細については、こちらを確認してくださいhttp://www.4guysfromrolla.com/articles/071509-1.aspx


0

私は答えで明確に見つけることができなかった2つの使用法に注意します。

クラスアイテムのグループ化

一部の開発者は、コメントを使用してクラスのさまざまな「部分」を分離しています。たとえば、チームは次の規則を使用する場合があります。

public class MyClass{  
  //Member variables
  //Constructors
  //Properties
  //Methods
}

部分クラスを使用すると、さらに一歩進んで、セクションを個別のファイルに分割できます。慣例として、チームは各ファイルにそれに対応するセクションのサフィックスを付ける場合があります。したがって、上記ではMyClassMembers.cs、MyClassConstructors.cs、MyClassProperties.cs、MyClassMethods.csのようなものになります。

他にも触れたように、クラスを分割する価値があるかどうかは、この場合のクラスの大きさによって異なります。小さい場合は、すべてを1つのマスタークラスに含める方が簡単です。ただし、これらのセクションのいずれかが大きくなりすぎた場合は、マスタークラスを適切に保つために、そのコンテンツを別の部分クラスに移動できます。その場合の慣例として、セクション見出しの後に「部分クラスを参照」のようなコメントを残すことが挙げられます。例:

//Methods - See partial class

ステートメントの使用範囲の管理/名前空間

これはおそらくまれなことですが、使用するライブラリの2つの関数の間に名前空間の衝突がある可能性があります。単一のクラスでは、多くの場合、これらのいずれかにusing句を使用できます。その他の場合は、完全修飾名またはエイリアスが必要です。部分クラスでは、各名前空間とusingステートメントのリストが異なるため、2つの関数セットを2つの別々のファイルに分けることができます。


解決名前空間の衝突へのメカニズムが使用して、ネームスペースの名前変更、例えば、ありますusing Library1 = The.Namespace.You.Needglobal::Root.Of.Namespace
fjch1997

うん、それは弱いユースケースだと思う。ただし、名前を完全に修飾する必要がない方が少し便利です。部分クラスを使用する理由よりも、意図しない副作用が多い。
Colm Bhandal
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.