I metodi parziali sono considerati dannosi?

Question

In C # 3.0 Microsoft ha introdotto il supporto per qualcosa chiamato metodi parziali .

Li usi? Puoi descrivere come e perché?

Consideri l'uso di metodi parziali una buona pratica di programmazione o no?

Answer 1

I metodi parziali sono principalmente utili per l'estensione del comportamento del codice generato dallo strumento senza costi né nella valutazione del runtime né nel codice visibile all'utente in cui tale estensibilità non viene utilizzata.

In quanto tale, il loro uso è sensato e incoraggiato laddove necessario, ma tali occasioni saranno relativamente rare per la maggior parte degli utenti (che non scrivono strumenti per generare codice). Se stai scrivendo uno strumento del genere, dovresti considerare dove le persone possono interagire con il flusso del tuo codice generato e se tale utilizzo non può essere gestito facilmente attraverso meccanismi simili a eventi, raggiungendo al contempo gli obiettivi prestazionali e di usabilità previsti. Gli eventi sono intrinsecamente multicast e tale struttura potrebbe essere intrinsecamente contraria alla progettazione prevista dell'API. In alternativa, potrebbe essere necessario un valore di ritorno complesso o l'interazione con i parametri ref / out, infine l'estensione può essere complessa / fragile nonostante la sua utilità e come tale solo l'implementatore di classe parziale può essere in grado di gestirlo adeguatamente. Tutti questi motivi hanno la loro nicchia, se non essere metodi comuni e parziali possono risolverli efficacemente.

Consumatori che implementano metodi parziali dovrebbero usarli come impone il codice generato dallo strumento (se viene fornito un punto di estensione e ne hai bisogno, utilizzalo). Evitare di farlo perché si ritiene che la funzionalità sia confusa sarebbe uno scarso utilizzo del linguaggio e dell'API poiché questo è chiaramente il punto di estensione previsto.

Answer 2

Come le stesse classi parziali, sono utili solo in combinazione con il codice generato dallo strumento (designer). E lì forniscono un'alternativa semplice, leggera, agli eventi.

Answer 3

Ho avuto occasione di usare un metodo parziale su una libreria di classi che ho scritto. È stato possibile compilare la libreria in una delle diverse versioni, con l'uso di costanti definite, che avrebbe compilato o compilato vari blocchi di funzioni.

Ma sporcare il codice con #if / #endif per tutte le combinazioni di opzioni, incrociate con Compact Framework e framework desktop, ha portato a cose confuse.

Ho usato metodi parziali per semplificare quel pezzo - come una sorta di # if / # endif invisibile o implicito. Questo è simile al modo in cui vengono utilizzati in LINQ, a quanto ho capito.

D'altra parte, in fase di esecuzione non aggiungo questi metodi, come farebbe LINQ. Invece del modello linq, dove ci sono assembly separabili, e quando combinati si ottiene una funzione extra, nella mia classe lib, esiste una singola DLL creata per ogni combinazione di opzioni. Questo per facilitare la distribuzione e il consumo.

Answer 4

Le classi parziali fanno sì che C # e VB funzionino più come C e C ++ dove puoi spargere il codice che implementa una classe su diversi file come ritieni opportuno. Il loro scopo principale è supportare in modo chiaro i visual designer per cose come WPF. Lo considero un buon uso per le classi parziali.

Un altro uso che ho visto è quello di dividere un grande file sorgente in parti logiche. Ad esempio, classe BigForm potrebbe comprendere i file BigForm-BillingInfo.cs, BigForm-ShippingInfo.cs e BigForm-LineItems.cs. Questo di solito è un cattivo uso delle classi parziali, perché il refactoring in più classi o controlli è una migliore progettazione OOP (per riusabilità, ecc.).

Answer 5

Le classi parziali sono una funzione molto utile, ad esempio quando si dispone di un client e un server ed entrambi devono condividere i tipi di dati per la persistenza degli oggetti business. Hai il tuo lato server di classe normale, lo esponi lato client con il tuo servizio web e se vuoi decorare le cose lato client, in modo molto bello, puoi creare una versione parziale della tua classe (lato client hai una versione generata dal codice del versione del server tramite generazione proxy ecc.).

Volevo solo dire questo esempio, mentre faccio un uso esteso di funzionalità parziali, al giorno d'oggi, lavorando su un progetto Silverlight, persistendo oggetti disconnessi :)

// Ci scusiamo per non aver notato che la domanda si riferisce esplicitamente ai metodi. I metodi parziali sono molto utili per tessere la funzionalità del codice nei gestori di eventi, generati automaticamente in determinati scenari.

Answer 6

La cultura della programmazione Microsoft ha sempre favorito un "nastro adesivo" più flessibile " approccio. Questo risale almeno alle guerre Quick BASIC vs. Turbo Pascal. Le lingue Microsoft consentono le scorciatoie. Prendi ad esempio i delegati: un delegato è sostanzialmente un'interfaccia in cui hai dimenticato di progettare. I metodi parziali sono più o meno gli stessi.

Il titolo della tua domanda si riferisce alla famigerata lettera di Edsger Dijkstra a CACM e questo è molto appropriato. La lettera Dijkstra era la pistola ufficiale di partenza per le guerre di programmazione strutturate. Personalmente non penso che troverai la saggezza sostenendo una strada strutturata o non strutturata in tutte le situazioni.

Ho sempre pensato che questo conflitto fosse un prodotto delle differenze nelle prospettive di ingegneria rispetto all'informatica. I programmatori Eary Microsoft hanno programmato bare metal tutto il giorno. Dopo aver scritto abbastanza assemblatore, i dettami della programmazione strutturata sembrano un po 'sciocchi.

Il compromesso si riduce a: vorresti avere abbastanza corda per impiccarti, o ti piacerebbe essere costretto a riscrivere parti della tua architettura per soddisfare l'inflessibilità del linguaggio? Un team disciplinato può scrivere un buon codice in entrambi gli ambienti e non esiste una risposta giusta universale.

Tornando al quesiton a portata di mano: non credo che i metodi parziali siano una funzionalità linguistica eccezionale, ma se fossero necessari per far funzionare LINQ, vale sicuramente la pena tollerarli.