Typen / Klassen als Parameter verwenden

[Meflin]

Zitat von implementation:

Aber damit sollte sich das erste Beispiel bewältigen lassen.

Naja nicht ganz. Zwar kann man damit sowas anlegen:

Code:

Type[] KnownClasses = new Type[] { typeof(ClassA), typeof(ClassB) };

Aber wie komme ich nun vom Type wieder zur Klasse? Ein Eintrag aus dem Array kennt ja nun logischerweise die (statischen) Methoden meiner Klassen nicht (ist ja auch vom Typ Type) und ein cast ist nicht möglich

Code:

foreach (Type t in KnownClasses) {
    // ? t.foo()
}

[implementation]

Die Lösung ist eine Methode von System.Type, nämlich InvokeMember

[Khabarakh]

Ich denke, ein konkretes Anwendungsbeispiel wäre langsam hilfreich . Von Dependency Injection bis zu Funktionaler Programmierung (Higher-Order-Functions) gibt es manchmal sogar bessere Lösungen als virtuelle statische Methoden.

Eine virtuelle statische Methode direkt umzusetzen, ohne Verlust von statischer Typisierung, wirst du aber nur erreichen, indem du sie zur Instanzmethode machst und dafür ggf. in eine eigene Klasse auslagerst.

[implementation]

Zitat von Khabarakh:

Von Dependency Injection bis zu Funktionaler Programmierung (Higher-Order-Functions) gibt es manchmal sogar bessere Lösungen als virtuelle statische Methoden.

In C# gibt es nicht einmal virtuelle statische Methoden
Daher ist das erste Beispiel sowieso Schwachsinn.
Da müsste Microsoft erstmal Delphi's Klassenmethoden abgucken.

[Meflin]

Zitat von Khabarakh:

Ich denke, ein konkretes Anwendungsbeispiel wäre langsam hilfreich .

Nungut... es soll eine Reihe von "Events" verwaltet werden... Im Endeffekt Daten, die über einen Socket empfangen werden. Für jeden möglichen Befehl gibt es eine Unterklasse von

Code:

    abstract class ServerEvent
    {
        public static string command() {
            return "";
        }

        public static void handler() { } 
    }

Alle bekannten Events sollen nun bei einem Dispatcher registriert werden (der ServerEvent.Command aus den TCP Daten liest und dann ServerEvent.handler() passend aufruft).

Mit der im Eingangspost gezeigten Smalltalk-Variante wäre ich da voll zufrieden

Vermutlich gibt es dafür auch völlig andere Lösungsansätze; sollte meine Idee tatsächlich nur schwer umsetzbar sein, werde ich wohl auch umstellen...

[Khabarakh]

Nicht so kompliziert denken und einfach Instanzmethoden daraus machen ? Ich sehe da keinen Nachteil - und wie gesagt können sich dadurch sogar ganz andere Möglichkeiten eröffnen :

Code:

   class Dispatcher
   {
      [ImportMany]
      IEnumerable<ServerEvent> EventHandlers { get; set; }

      public Dispatcher()
      {
         // Here be MEF magic...
         var catalog = new DirectoryCatalog(@".\");
         var container = new CompositionContainer(catalog);
         container.Composeparts(this);
      }

      void Receive()
      {
         ServerEvent handler = EventHandlers.First(h => h.Command == command);
         handler.Handle();
      }
   }

   public abstract class ServerEvent
   {
      public virtual string Command { get { return ""; } }
      public void Handle();
   }

   [Export(ServerEvent)]
   class IAmATeapotServerEvent : ServerEvent { ... }

Wirf eine weitere Assembly mit einer ServerEvent-Ableitung in den bin-Ordner und MEF wird sie ohne weiteres Zutun ebenfalls dem Dispatcher zuordnen. Und jetzt sag mir, dass das mit statischen virtuellen Methoden eleganter lösbar sei .

[Meflin]

Das klingt natürlich wirklich nett. Einen Haken hat das ganze allerdings: das gibts alles erst ab .Net 4 oder? Ich bin aber an 3.5 gebunden, durch andere Libraries...

Zitat von Khabarakh:

Nicht so kompliziert denken und einfach Instanzmethoden daraus machen ? Ich sehe da keinen Nachteil - und wie gesagt können sich dadurch sogar ganz andere Möglichkeiten eröffnen

Ist ja nicht so dass ich was gegen Instanzen hätte Nur bei meinem Ansatz wären sie einfach überflüssig gewesen...

[Phoenix]

Du kannst doch einfach per reflection hergehen, die statischen Methode ermitteln und aufrufen.
Um die Typen zu finden die diese Methode implementieren kannst du im Prinzip hergehen und mittels linq abfragen, welche typen eine statische Methode dieses namens haben. Das ist aber nicht gerade Performant, weil die Abfrage alle typen nach der Methode abfragt.

[Meflin]

Zitat von Phoenix:

Du kannst doch einfach per reflection hergehen, die statischen Methode ermitteln und aufrufen.

Naja gehen täte das sicherlich. Aber hübsch finde ich das nun auch nicht gerade.

Mal gucken ob ich nicht doch auf 4 umsteigen kann...

[Khabarakh]

Zitat von Meflin:

Das klingt natürlich wirklich nett. Einen Haken hat das ganze allerdings: das gibts alles erst ab .Net 4 oder?

Integriert ja, ansonsten... . Wenn du darin Overkill siehst, kann ich dir das aber schlecht verübeln, also würde ich in Anlehnung an Phoenix' Code den MEF-Composition-Teil durch

Code:

EventHandlers = Assembly.GetEntryAssembly().GetTypes().Where(t => t.IsSubclassOf(typeof(ServerEvent))).ToList();

ersetzen.

Zitat von Meflin:

Ich bin aber an 3.5 gebunden, durch andere Libraries...

Hm? Wenn du einen Breaking Change in 4.0 treffen solltest, gebe ich dir einen aus .

Zitat von Meflin:

Ist ja nicht so dass ich was gegen Instanzen hätte Nur bei meinem Ansatz wären sie einfach überflüssig gewesen...

Und Herr Hejlsberg dachte wahrscheinlich umgekehrt, dass ein Feature überflüssig ist, das sich (zumindest in Fällen wie diesem) ohne wirklichen Verlust auch auf einfacherem Weg realisieren lässt. Wie Eric Lippert es einmal sagte: Jedes Sprachfeature beginnt bei -500...
Und ohne dir nahe treten zu wollen, oder überhaupt zu wissen, wie tief du schon in der CLR drinsteckst, ist es imo ein beeinträchtigender Fehler von Umsteigern, in einer managed Sprache Instanzierungen zählen zu wollen. Sagt mir jedenfalls meine eigene Erfahrung - man muss loslassen können, um zu genießen .

@Sebastian: Uh, jetzt musst du mir aber dringend erklären, wo du nun noch einen Vorteil von statischen Methoden + Reflection siehst.