Bir etkinliği gönderen her zaman genel bir Nesne olmalı mı?

C # 'daki olayları programlarken, şu şekilde bir temsilci oluşturmanız tavsiye edilir :

delegate XEventHandler(object sender, XEventArgs e);

Sorum delegenin ilk argümanında object sender. Her zaman jenerik olmak zorunda objectmı? Bir gönderene sahip olmak objecther zaman buna benzer bir kodla sonuçlanır.

val = ((ConcreteType)sender).Property;

veya daha ayrıntılı,

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

Güçlü yazılan gönderenlere karşı yapılan bir argüman, diğer nesnelerin olay hakkında endişelenmeden olayı iletebilmesidir . Bu GUI ortamlarında mantıklı gelse de, GUI dışında fayda sağlayabileceğinden emin değilim.

Gönderenin sınıfı her zaman biliniyorsa (en azından soyut bir sınıf olarak)? Örneğin, ListChangedsoyut bir Listsınıfta bir olay uyguluyorsam ve diğer sınıflar bunu devralacaksa (örn LinkedList. ArrayList), Temsilci türünü bir gönderenle tanımlamak doğru Listmudur?

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

Yoksa konvansiyonel olanı object senderdaha spesifik bir türe dönüştürmenin bir dezavantajı olur mu?

Bu noktada, çoğunlukla (oldukça güçlü) bir sözleşmedir. Yani, bu kurala uymayan bir kütüphane yazmanız garip olacaktır.

Olay Tasarım Kuralları ki:

DO kullanımını objectolay işleyicisi ilk parametrenin türü olarak ve diyoruz sender.

Bununla birlikte, mevcut rehberliğin etkinlikler için kendi özel temsilcinizi tanımlamamanız gerektiğini, ancak EventHandler<T>mümkünse bunun yerine kullanmanız gerektiğini söylediğini unutmayın .

Tasarıma gelince, aynı zamanda olayın orijinal tasarımcısı tarafından başlangıçta öngörülmeyen bağlamlarda bile olay işleyicilerinin yeniden kullanılmasını teşvik ettiğini tahmin ediyorum.

Tavsiyenin nedeni, mevcut kodda ve özellikle genel arayüzde mutlaka değişiklik yapılmasını gerektirmeyen gelecekteki değişikliklere izin vermesidir.

Etkinlik mekanizması yine de "VB6" tarzı etkinlikler için kullanılabilir, ancak imzayı değiştirmeniz gerekirse (veya daha da kötüsü: aynı etkinliklerin yeni sürümlerini oluşturmanız gerekirse) mevcut tüm tüketicileri değiştirmeniz gerekir. Önerilen yaklaşımla, yeni öğeler mevcut olanlardan miras kaldığı sürece, mevcut kodu düzeltmeden imzayı güncelleyebilirsiniz.