Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Java (oder generell): Konstruktoren in Interfaces?
Hi,
kann man Konstruktoren in Interfaces definieren, um sicherzustellen, dass alle Implementierungen z. B. einen Konstruktor mit einem String-Parameter bereitstellen? Java hat bei mir gemeckert. Gibt es konzeptionell einen Grund dagegen?
Gruesse,
-Steppenwolf
Gibt es und am besten kann das palmcron erklaeren 
Es haengt irgendwie damit zusammen, dass Interfaces nicht die Implementierung vorschreiben sollen, und der Konstruktor ist Teil der Implementierung.
Hmm,
Interfaces sollen die Schnittstellen beschreiben, nicht die Implementierung, ja. Aber ein Konstruktor ist auch nur eine Schnittstelle - was der “Ableiter” damit macht, ist seine Sache.
Aber ich lasse mich gerne aufklaeren - palmcron, zu Wort :)!
Ein Konstruktor initialisiert die internen Daten; und was er dazu braucht haengt davon ab, wie die Daten intern repraesentiert sind.
Ausserdem instanziierst du ja sowieso immer eine Klasse und kein Interface, so dass ein Interface-Konstruktor auch nicht so viel Sinn macht.
Ich finde schon, dass das Sinn macht, zumindest soweit, wie ein Interface generell Sinn macht.
Ich wollte ja auch keinen Interface-Konstruktor, sondern ein Konstruktor-Interface deklarieren! Damit will ich bloss sagen, dass z. B. ein Konstruktor in jeder implementierenden Klasse vorhanden sein muss, der einen String als Parameter anbietet.
Natuerlich arbeitet der Konstruktor auf internen Daten - aber das macht wohl jede Methode! Wenn ich in einem Interface eine Methode void bla (String blubb) deklariere, dann schreibe ich den implementierenden Klassen ja auch vor, dass sie intern den String irgendwie verwenden (verwerfen waere ja nicht Sinn der Sache).
Ich sehe aber ein, dass es problematisch ist, was den Namen angeht - weil der Konstruktor immer den Namen der Klasse bzw. hier dann den Namen des Interfaces haette…
ich finde konstruktor interfaces wären schon gut, gibts aber nicht.
das mit internen daten is doch blödsinn. den namen find ich auch überhaupt nicht problematisch.
allerdings hat sowas nur sinn, wenn man nicht genau weiss welche klasse man instanziiert. in c++ gibt es immer einen compilerfehler, wenn man new mit einer klasse verwendet, die keinen passenden kontruktor hat.
in java oder c# schaut das allerdings anders aus. da merkt mans unter umständen erst, wenn die fehlerhafte klasse zur laufzeit instanziiert wird, und eine exception auftritt. nicht sehr optimal…
Ein Interface wird benötigt, damit man über eine Referenz des Interface-Typs auf die Funktionen einer davon abgeleiteten Klasse zugreifen kann.
Man wird aber niemals einen Konstruktor-Aufruf über ein Interface ausführen, denn was sollte dann passieren?
Eine Instanz des Interfaces erstellen? Geht nicht, da es ja keinerlei Implementierung enthält.
Eine Instanz einer vom Interface abgeleiteten Klasse erstellen? Aber von welcher?
sowas könnte man sicher irgendwie machen, klar gibts das in den jetzigen sprachen nicht…
Das geht nicht, sagen Eclipse und Google.
Vielleicht kannst du aus dem Interface eine abstrakte Klasse machen, dort kannst du einen Konstruktor der einen String entgegennimmt einbauen.
Den Konstruktor müsstest du allerdings gleich implementieren, nur definieren reicht nicht.
(Was dir wahrscheinlich nicht hilft, weil du sonst nicht hier fragen würdest ;))
Soweit ich das verstanden hab, moechte er alle Subklassen zwingen, einen bestimmten Konstruktor zu implementieren.
(Was nicht geht; ich seh allerdings auch nicht, warum das noetig sein sollte…)