悪い練習ですか？ステートメントを使用しているC＃の非標準的な使用

Question

C＃には、特にIDisposableオブジェクト用のusingステートメントがあります。おそらく、usingステートメントで指定されたオブジェクトは、確定的に解放されるべき何らかの種類のリソースを保持するでしょう。

しかし、私は、単一の明確な開始点と終了点を持つが、固有の言語サポートがないプログラミングには多くの設計があるように思えます。 using構成は、コードエディタの組み込み機能を使用して、そのような設計または動作の範囲を少なくとも明確かつ自然に強調する機会を提供する。

私が心に留めていることは、「開始」と「結合」を含む非同期コードの実行など、さまざまな種類がありますが、頻繁にBeginXXX()とEndXXX()メソッドで始まる操作の種類です。

この簡単な例をご覧ください。

webDataOperation.Start(); 
GetContentFromHardDrive(); 
webDataOperation.Join(); 
// Perform operation that requires data from both sources 

何場合は、代わりに、Startメソッドは、そのIDisposable.Dispose方法結合操作を実行したオブジェクトが返されました。

using(webDataOperation.Start()) { 
    GetContentFromHardDrive(); 
} 
// Perform operation that requires data from both sources 

それとも、いっそ、私は、特に念頭に置いていた：私は専門性の高いグラフィックスは、ブリット行い、Begin()とEnd()方法（また、DirectXの中に存在し、XNAデザイン）を持つオブジェクトを持っています。代わりに...

using(blitter.BlitOperation()) { 
    // Do work 
} 
// Use result 

より自然で読みやすいように見えますが、それが意図しない目的でIDisposableインタフェースとusing文を使用して見て、お勧めできませんか？換言すれば、これは、と直観的ではなく、直観的ではない方法でオペレータをペイロードするでしょうか？

Answer 1

これは完全に許容される方法です。これは因数分解型と呼ばれ、Framework Design Guidelinesはこれを行うことを推奨します。

基本的に、型が特定の有効期間内に操作をラップする場合は、IDisposableとusingステートメントを使用して考慮する必要があります。

実際にはthis specific topic hereについてもブログしました。

Answer 2

私はIDisposableを何を意図しているのか、それ以外のものは使用しないといけないと思います。つまり、メンテナンス性があなたにとって重要であれば。

Answer 3

私は、実際には、特定のコードブロックの最後にトリガーされたアクションをいくつかのプロジェクトで使用しました。

ウェスDeyerはASCIIアートプログラムに彼のLINQでそれを使用して、彼は（ウェスは、C＃コンパイラチームで動作します - 私は彼の判断を信頼したい：Dを）：使い捨てアクションと呼ん

http://blogs.msdn.com/wesdyer/archive/2007/02/23/linq-to-ascii-art.aspx

class ActionDisposable: IDisposable 
{ 
    Action action; 

    public ActionDisposable(Action action) 
    { 
     this.action = action; 
    } 

    #region IDisposable Members 

    public void Dispose() 
    { 
     this.action(); 
    } 

    #endregion 
} 

は今、あなたは関数からということを戻し、このような何かを行うことができます。

using(ExtendedConsoleWriter.Indent()) 
{ 
    ExtendedConsoleWriter.Write("This is more indented"); 
} 

ExtendedConsoleWriter.Write("This is less indented"); 

Answer 4

それは一般的なパターンですが、個人的に、私はIDを乱用するの言い訳はありませんと信じていますあなたが匿名の代理人やラムダを使って同じ効果をはるかに明白な方法で達成することができるときは、そういうものです。すなわち：

blitter.BlitOperation(delegate 
{ 
    // your code 
}); 

Answer 5

（フィル・ハークが、それは大丈夫だと言うのでまたは）あなたは、あなたがすべきという意味ではありませんすることができますという理由だけで。

基本的なルール：あなたのコードを読んで、それが何をしているのか、あなたの意図が何であるのかを理解できれば、それは受け入れられます。一方で、あなたが何をしたのか、なぜそれをしたのか説明する必要がある場合、おそらく中流の開発者がコードを管理しています。

カプセル化を強化してこれを実現できる他の多くのパターンがあります。

結論：この「テクニック」はあなたに何も買わず、他の開発者を混乱させます。

Answer 6

私はそれに反対します。私の信念は、コードはコンパイラではなくコードのメンテナーと効果的にやりとりすることであり、メンテナーの理解を念頭に置いて書かなければならないということです。私は、リソース（通常は管理されていないリソース）を処分するためだけに "使用する"ことを試みます。

私は少数派です。ほとんどの人は一般的な目的として "using"を使用しているようです。 "例外がスローされてもクリーンアップコードを実行したい"という仕組みです。

（1）私たちはすでに「try-finally」と呼ばれるメカニズムを持っています。（2）意図しない目的のために機能を使用しています。クリーンアップコードは重要ですが、なぜそれが呼び出された時点でそれが見えないのですか？それが重要なら、私はそれを見ることができるようにしたい。