Un evento C # deve avere un tipo di oggetto come primo parametro?

Question

Un evento C # deve avere un tipo di oggetto come primo parametro?

#1 da (9 voti)
#2 da (6 voti)

6

Ho una classe TCPClient . Ha diversi ClientEvent s. Originariamente seguiva lo schema standard

public delegate void ClientEvent(object sender, ClientEventArgs e);

Solo TCPCLient utilizza questo evento. Ma sono piuttosto determinato a mantenere le cose il più standard possibile (tutte le cose basate sugli eventi che ho visto usano object sender ). Tuttavia, ciò a cui non vedo il punto, è che devi lanciare sender in TCPClient ogni volta.

 private static void Client_OnReconnect(object sender, ClientEventArgs e) {
            TCPClient client = (TCPClient)sender; 
        }

C'è qualche ragione per cui non dovrei usare

public delegate void ClientEvent(TCPClient client, ClientEventArgs e);

come il mio evento?

c#

posta user2410532 13.12.2015 - 18:14

fonte

2 risposte

Leggi altre domande sui tag c#

Ha senso dichiarare campi privati usando un'interfaccia come loro tipo? Qualcosa di sbagliato nell'avere pseudonimi su un server di produzione?

score 9 · Answer 1

I am pretty determined to keep things as standard as possible

Buona. Non lo stai facendo però. Le linee guida standard possono essere trovate qui:

MSDN - Design di eventi per .NET Framework

Hai violato le linee guida

use System.EventHandler<TEventArgs> instead of manually creating new delegates to be used as event handlers.

Naturalmente le linee guida sono linee guida , non regole . Le linee guida continuano a notare che se per qualche motivo decidi di violare questa linea guida ...

use object as the type of the first parameter of the event handler, and call it sender.

La tua domanda è:

Is there any reason I shouldn't just use delegate void ClientEvent(TCPClient client, ClientEventArgs e) as my event?

Cioè, se è il caso che il mittente sarà sempre un TCPClient , perché non codificarlo nel sistema di tipi?

Bene, questo viola le linee guida del design, ma ovviamente è mere domande. Perché questa linea guida? Il ragionamento è dovuto al fatto che la tua affermazione che il mittente di questo evento sarà sempre e per sempre TCPClient è uno che storicamente si è spesso rivelato essere violato. Tu pensi che sì, voglio solo gestire gli eventi click sui pulsanti, quindi il mittente può essere Button , e poi sprint di qualche designer UX vuole cambiare completamente metà dei pulsanti in scimmie cliccabili, e ora l'evento click deve essere applicato a entrambi i pulsanti e le scimmie, e blah blah blah, vedi come va.

Ancora una volta: le linee guida sono linee guida, non regole. Se si ha fiducia che codificare questa limitazione nel sistema di tipi è più alto del rischio di avere qualche designer dire "hey, puoi cambiare metà dei client in TCPMonkey, quanto può essere difficile?" quindi con tutti i mezzi per farlo.

score 6 · Answer 2

Il parametro sender è tale che il callback può riconoscere l'oggetto che lo sta invocando. In alcune situazioni, è utile saperlo. Se non ti serve, allora, non ne hai bisogno, e non ci sono motivi tecnici, di livello linguistico o di struttura per cui devi necessariamente usarlo.