Cattive abitudini? L'utilizzo non canonico di C# utilizzando la dichiarazione

Question

C# ha l'istruzione using, in particolare per gli oggetti IDisposable. Presumibilmente, qualsiasi oggetto specificato nell'istruzione using conserverà una sorta di risorsa che dovrebbe essere liberata in modo deterministico.

Tuttavia, mi sembra che ci siano molti progetti in programmazione che hanno un inizio e una fine singoli, definiti, ma mancano di un supporto linguistico intrinseco. Il costrutto using offre l'opportunità di utilizzare le funzionalità incorporate di un editor di codice per, almeno, evidenziare chiaramente e naturalmente l'ambito di tale progetto o operazione.

Quello che ho in mente è il tipo di operazione che inizia spesso con un metodo BeginXXX() e EndXXX(), anche se ci sono un sacco di sapori diversi, come ad esempio l'esecuzione di codice asincrono che coinvolge una "start" e di una "join".

Prendi questo esempio ingenuo.

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

Che cosa succede se, invece, il metodo Start restituito un oggetto la cui IDisposable.Dispose metodo esegue l'operazione di join.

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

O, meglio ancora, quello che ho espressamente avevo in mente: ho un oggetto che fa la grafica altamente specializzati copiarlo sul video e ha un metodo di Begin() e End() (un disegno presente anche in DirectX e XNA). Invece ...

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

Sembra essere più naturale e leggibile, ma è sconsigliabile, visto che utilizza l'interfaccia IDisposable e la using dichiarazione a fini non intenzionali? In altre parole, questo sarebbe alla pari con o verloading un operatore in modo non intuitivo?

Answer 1

Questa è una pratica perfettamente accettabile. Questi sono chiamati tipi Factored e il Framework Design Guidelines consiglia di fare proprio questo.

In sostanza, se il tipo esegue il wrapping di un'operazione con una durata specifica, utilizzando IDisposable e l'istruzione using diventa una cosa appropriata da considerare.

In realtà ho bloggato circa this specific topic here, pure.

Answer 2

Penso che dovresti usare IDisposable per quello a cui è destinato, e nient'altro. Cioè, se la manutenibilità è importante per te.

Answer 3

Direi che è accettabile - in effetti, l'ho usato in alcuni progetti in cui volevo che un'azione fosse attivata alla fine di uno specifico blocco di codice.

Wes Deyer utilizzato nel suo LINQ to ASCII programma di arte, lo chiamò azione usa e getta (Wes lavora sul C squadra # compilatore - mi fiderei suo giudizio: 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 
} 

Ora si può tornare che da una funzione, e fare qualcosa di simile:

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

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

Answer 4

si tratta di un modello comune, ma personalmente, credo che non ci sono scuse per abusare ID è possibile quando si riesce a ottenere lo stesso effetto in modo molto più ovvio con delegati anonimi e/o lambda; cioè .:

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

Answer 5

Solo perché è possibile (o perché Phil Haack dice che va bene), non significa che si dovrebbe.

La regola pratica di base: se riesco a leggere il codice e capire cosa sta facendo e quale era l'intento, è accettabile. Se, d'altra parte, hai bisogno di spiegare cosa hai fatto, o perché lo hai fatto, probabilmente fara 'saltare gli sviluppatori junior mantenendo il codice.

Ci sono molti altri modelli che possono realizzare questo con una migliore incapsulamento.

La linea di fondo: questa "tecnica" non ti compra nulla e agisce solo per confondere altri sviluppatori.

Answer 6

Consiglio contro di esso; la mia convinzione è che il codice sia efficacemente comunicare con il manutentore del codice, non con il compilatore, e dovrebbe essere scritto tenendo presente la comprensione del manutentore. Provo ad usare "usando" solo per disporre di una risorsa, in genere una risorsa non gestita.

Sono in minoranza. La maggior parte delle persone sembra utilizzare "uso" come un fine generale "Voglio un po 'di codice di pulizia per l'esecuzione anche se viene generata un'eccezione" meccanismo.

Non mi piace perché (1) abbiamo già un meccanismo per questo, chiamato "try-finally", (2) utilizza una funzione per uno scopo per cui non è stata progettata e (3) se la chiamata a il codice di pulizia è importante, quindi perché non è visibile nel punto in cui viene chiamato? Se è importante, voglio essere in grado di vederlo.