Statische Methoden in Interfaces?

[jago]

Hi,

wir wissen alle, dass statische Methoden in Interfaces nicht erlaubt sind. Aber warum spricht eigentlich was dagegen, dass man eine Gruppe von Klassen ein solches Interface implementieren laesst und dann davon ausgehen kann, dass die gewuenschte Statische Methode existuert. Haette das irgendwelche Nebeneffekte?

Danke,
jago

 

[maki]

statische Methoden in Interfaces?
Sinnfrei!

 

[jago]

statische Methoden in Interfaces?
Sinnfrei!

Naja...bisher muss ich immer erst eine Instanz einer Klasse haben um eine Methode zu nutzen. Wenn diese Methode statisch waere saehe es anderst aus. Oft ist es aber schwierig so eine Instanz zu generieren oder es macht auch keinen Sinn, da es sich um unterschiedliche Factory Klassen handelt meiner Vorstellung nach alle das gleiche Set an statischen Methoden implementieren soll - klar koennte man das auch mit normalen Interface-Methoden loesen wenn die Factory-Klassen alle Singletons sind...uuupps...aber die getInstance() Methode des Singletons muss ja immer statisch sein

Waer also noch ein weiterer Nutzen fuer statische Methoden in Singletons - ich koenne also ein
Interface Singleton<T> erstellen mit
T getInterface()
Und dann class SingletonKlasse implements Singleton<SingletonKlasse>

...statische Methoden in Interfaces sehe ich also doch als sinnvoll an.



Belehr mich gerne eines Besseren aber bitte mit einer ordentlichen Argumenten, nicht indem man die akzeptierte Meinung statische Methoden == sinnfrei nachbetet.

 

[maki]

Wenn du mehr als ein einziges Singleton in deiner Anwendung hast, machst du etwas falsch, nämlich das Design
Mach dir doch eine Registry, oder nutze ein DI Framework, wie zB. SPring, oder manuell ohne Framework per setter/Contructor injection.

Abgesehen davon das Interfaces etwas mit Vererbung und Polymorphie zu tun haben und static eben genau das nicht kann/unmöglich macht, ist static in Interfaces voll daneben

 

[Guest]

Wenn du mehr als ein einziges Singleton in deiner Anwendung hast, machst du etwas falsch, nämlich das Design
Mach dir doch eine Registry, oder nutze ein DI Framework, wie zB. SPring, oder manuell ohne Framework per setter/Contructor injection.

Abgesehen davon das Interfaces etwas mit Vererbung und Polymorphie zu tun haben und static eben genau das nicht kann/unmöglich macht, ist static in Interfaces voll daneben

Was? Man kann sehr wohl mehrere Klassen die Singletons sind in einer Anwendung haben. Hast du eigentlich implizit in jeder Anwendung, da Java intern mehrere Singleton-Klassen nutzt. Aber das war ja auch nur ein Beispiel und dein Spring Rat macht gar keinen Sinn.

Es geht darum, mehreren Klassen eine gemeinsame statische Schnittstelle zu verpassen. Interfaces etwas mit Vererbung und Polymorphie zu tun aber das heisst ja nicht dass man es dabei belassen muss. Wenn man das durch statische Interfaces erweitert koennten Interfaces eine zusaetzliche Bandbreite von neuen Funktionen abdecken.

 

[Guest]

Und ja man bricht hier nicht mit der Objektorientierung!

Man erhaelt das Class-Objekt eines Typs! Alle Class-Objekte diesen Typs, also auch alle Class-Objekte von abgeleiteten Klassen wuerden dann diese statische Methode implementieren.

 

[SlaterB]

Klassen werden nicht dynamisch angesprochen,

durch die Vorgabe in Interfacen könntest du vielleicht dafür sorgen, dass Klasse X eine statische Operation y braucht, und sonst der Compiler meckert,
aber welchen Nachteil hast du, wenn das nicht passiert?

die einzige Möglichkeit, auf diese Operation y zuzugreifen, ist explizit
X.y(); im Quellcode zu schreiben,
und du diesem Zeitpunkt merkt man dann, dass die Operation fehlt und ergänzt sie,

sinnlose Features werden nicht eingebaut,
diese neue Bandbreite hat bisher noch niemand gebraucht, bedeutet dir diese Erkenntnis nichts?
irgendwann ist auch gut und man kann das Thema ruhen lassen

> also auch alle Class-Objekte von abgeleiteten Klassen

nun bewegst du dich aber endgültig von der Realität weg,
Klassen sind nun mal extra keine Objekte, damit es keine Objekte sind,

du kannst nicht Klassen von Objekten selber wieder zu Objekten machen..

 

[BjörnBu]

Wie ist das denn gemeint? Mir würden zwei Arten einfallen, wie es gemeint sein könnte.

Fall 1 das interface definiert die statische methode nur und jede Klasse implementiert sie anderes -> sinnfrei. Wie sollte sich <Interface>.<methode>() verhalten?

Fall2 das interface implementiert die Methode schon vollständig und sie soll den Klassen zur Verfügung stehen. Genau an diesem Punkt sollte das Interface eine abstrakte Klasse sein. Ein Interface ist ja eine Schnittstelle und bringt an sich erstmal keine Funktionalität mit.

Außerdem: Spinnt man den Gedanken weiter kommt man an genau die Probleme, die man mit Mehrfachvererbung hätte... Wie verhält sich eine Klasse die zwei interfaces implementiert, die eine Methode mit gleicher Signatur unterschiedlich implementieren?

Beide Fälle machen meiner Meinung nach keinen Sinn. Hast du es also anders gemeint?

 

[SchonWiederFred]

Was passiert, wenn eine Klasse K von zwei Interfaces A und B erbt, die beide eine statische Methode m implementieren?

 

[Guest]

http://www.tutorials.de/forum/1555937-post5.html

 

[Guest]

Was? Man kann sehr wohl mehrere Klassen die Singletons sind in einer Anwendung haben.

Man kann seine Anwendung auch komplett aus Singletons bauen, nur hat das dann wenig mit Objektorientierung und Design zu tun. Deswegen sowenig wie möglich Singletons aber am besten gar keine.