✔ Kein Konstruktor und static in Interfaces?

Y

yan1

Erfahrenes Mitglied
Hallo..

ich frage mich warum man keine statischen Methoden in Interfaces deklarieren kann?

Ich habe bisher noch keinen Weg gefunden, wie man einem Interface sagen kann, dass die erbende Klasse einenen Leeren Konstruktor haben muss.

Da ich ein Plugin System machen will, wo Klassen zu meinem Programm hinzugefügt werden können, die dieses Interface erben, muss ich auch sichergestellt haben, dass diese neuen Klassen auch einen leeren Konstruktor haben müssen, ich muss ja schließlich dann ein Objekt erzeugen.

Jetzt habe ich mir gedacht, ok, mir ist der Konstruktor egal, die Klasse muss halt eine Methode haben, die heisst: GetInstance(). Diese Methode GetInstance() müsste aber dann statisch sein, sonst hat ja das ganze auch wieder keinen Sinn, da ich dann um diese Methode aufrufen zu können erst wieder eine Instanz dieser neuen Klasse erstellen muss, und mir schon wieder nicht sicher bin, ob diese Klasse eh einen leeren Konstruktor hat....

Habt ihr eine Idee wie ich das lösen könnte? Na klar, ich könnte beim Activator einfach abprüfen ob das instanzieren dieser Klasse geklappt hat, aber ich möchte das schon vorher einschränken können ;)

Lg, Yanick
 
Also, grundlegend implementiert man ein Interface und erbt nicht davon. Das ist mal die eine Geschichte. Weiters stellt ein Interface eine Schnittstellenbeschreibung dar, in der natürlich keinerlei Implementierungen Platz finden. Eine statische Methode wäre eine Implementierung, also ab in entsprechende Klasse.

"Dein Problem" ist auch gar nicht, ob im Konstruktor etwas ausgeführt wird oder nicht, sondern vielmehr, ob der Konstruktor eine Übergabe von diversen Daten via Properties etc. benötigt, um korrekt durchlaufen zu können.

Wie stellst du dir dein Plugin-System eigentlich vor? Denn, wenn du dies dynamisch machen willst, dann bringt dir eine statische Methode herzlich wenig, da du ja via Reflection an die Klasse ran musst und dir ohnehin via Reflection eine Instanz daraus besorgst.

Sollen andere Personen für deine Anwendung Plugins schreiben? Wenn ja, würde ich dies eher zur Programmierrichtlinie machen. Denn grundsätzlich kann es dir egal sein, was der Programmierer im Konstruktor macht, solange sein Plugin fehlerfrei lädt. Ist jetzt vielleicht ein pragmatischer Ansatz, aber dafür ohne viel Aufwand zu erledigen.

Eine andere Möglichkeit ist eben, dass du entsprechende Methoden (StartPlugin, UnloadPlugin) vorsiehst, über die die Initialisierung bzw. die Aufräumarbeiten vorgenommen werden müssen. Ändert zwar relativ wenig daran, dass der Entwickler trotzdem Code im Konstruktor ausführen lassen kann, aber die entsprechenden richtigen Plätze werden dadurch vorgesehen.
 
Nein, ich glaube du hast mich falsch verstanden.

Ich will sicher sein, dass ich die Klasse die sich in dem Library enthalten ist, auch sicher via Reflection instanzieren kann! Wenn diese Klasse jetzt nur einen öffentlichen Konstruktor hat, der ein Haufen Parameter benötigt, kann ich sie nich instanzieren, es würde einen Laufzeitfehler geben.

Wenn ich im Interface irgendwie festlegen könnte, dass die Klasse, die es implementiert (bin immer zu faul diesen Ausdruck zu verwenden, ist im Grunde ja egal, da ein Interface in meinen Augen so etwas wie eine vereinfachte Abstrakte Klasse ist, und man diese ja auch erbt ;-) ), einen Konstruktor hat, der keine Parameter hat (das habe ich mit leeren Konstruktor gemeint ;-) ), könnte ich mir sicher sein, dass ich diese Klasse via Reflections auch wirklich instanzieren kann.

Da ich aber nicht herausgefunden ob/wie das geht, habe ich mir gedacht, ich lege im Interface eine statische Methode fest, die diese Klasse auch enthalten muss, die GetObject() heisst, und diese keine Parameter hat. So kann es mir egal sein ob die Klasse einen Konstruktor hat, der versch. Parameter benötigt. Diese Methode gibt mir eine vollständige Instanz der eigenen Klasse zurück, mit der ich dann arbeiten kann.

//EDIT: Natürlich muss der Entwickler des Plugins diese GetObject() auch selbst implementieren..

Also im Grunde genommen schreibe ich diese Plugin selbst, ich will sie aber so machen, dass falls jemand Zeit/Lust egal was hat^^, die Plugins auch selbst schreiben kann.

Lg, Yanick
 
Zuletzt bearbeitet:
Also jede Klasse besitzt auch einen Konstruktor ohen Parameter, sprich den Standard-Konstruktor. Über den Typ der jeweiligen Klasse kannst du eine Liste der Konstruktoren erhalten, wo du dann auch jeweils abfragen kannst, welche Parameter sie benötigen. Einfach über den Default-Konstruktor instanzieren und dann überprüfen ob das Objekt erstellt wurde.

PS: Keine Panik, ich weiß schon was du mit leerem Konstruktor gemeint hast. Dafür mach ich das schon lange genug ....
 
Also jede Klasse besitzt auch einen Konstruktor ohen Parameter, sprich den Standard-Konstruktor.
Zum Vergrößern anklicken....
Ja das ist richtig, aber deswegen ist er noch lang nicht öffentlich aufrufbar! Wenn ein zweiter, nicht leerer Konstruktor definiert worden ist, dann kann ich die Klasse nicht über Activator.CreateInstance(objectType) instanzieren.. :'(
 
Also im Normalfall sollte der Konstruktor nicht private sein, ausser bei diversen Spielereien á la Singleton und Co.

Weiters kannst du sehr einfach herausfinden, ob es einen parameterlosen Konstruktor gibt oder nicht UND es besteht auch die Möglichkeit via Activator Konstruktoren zu verwenden, die Parameter benötigen. Blöd natürlich nur dann, wenn man nicht weiß, welche Argumente genau verlangt werden bzw. die Inhalte der Argumente. Aber anbei ein Beispielcode:
C#: 
Type objType = asm.GetType("TestAssembly.Person");
if (objType != null) 
{
    bool foundParameterlessConstructor = false;
    ConstructorInfo[] cis = objType.GetConstructors();
    foreach (ConstructorInfo ci in cis) 
    {
        if (ci.GetParameters().Length == 0) 
        {
            foundParameterlessConstructor = true;
            break;
        }
    }
    if (foundParameterlessConstructor) 
    {
        object o = Activator.CreateInstance(objType);
        Console.WriteLine(o.GetType().FullName);
    } 
    else 
    {
        object[] param = new object[1];
        param[0] = "first name";
        object o = Activator.CreateInstance(objType, param);
        Console.WriteLine("no parameterless constructor found");
    }
}
Daher würde ich aus deiner Sicht eine Überprüfung auf den entsprechenden Konstruktor einbauen und eine Fehlermeldung ausgeben, dass das Plugin nicht geladen werden kann. Beim ersten Test wird der Entwickler dann nochmals in die Doku gucken, warum denn das Plugin nicht geladen werden kann.
 
Genau so werde ich das auch jetzt machen.

Aber zurück zu meiner ursprünglichen Frage:

Ist es mir möglich, dass ich im Interface festlege, dass die implementierende Klasse einen öffentlichen leeren Konstruktor haben muss, dann müsste der Programmierer eigentlich gar nicht in die Doku sehen!

Aber so der wichtige Punkt ist das eigentlich eh nicht, ich werds mal so programmieren, wie es Norbert Eder in seinem Beispielcode gemacht hat.

Also jetzt muss ich einmal ein grosses Dankeschön aussprechen für deine Hilfe :-)

Lg, Yanick
 
Nein, da im Interface keine Konstruktor-Definitionen zugelassen sind. Macht ja auch keinen Sinn, das das Interface ja nur eine Schnittstelle beschreibt und über die konkrete Implementierung keine Ahnung hat.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück