abstract - interface Unterschied

[toxice]

Hallo,
ich schreib am Donnerstag eine Arbeit über die Grundlagen von Java.
Habe mir den Stoff gestern mal komplett durchgelesen, doch nun habe ich folgende Frage:
Was ist der Unterschied zwischen einer abstracten Klasse und einem Interface??
Bitte genaue Antworten.
THX :applaus:

 

[Bleiglanz]

abstrakte Klasse:

Methoden können ausprogrammiert werden ODER mit abstract deklariert werden, dann müssen sie in einer Unterklasse ausprogrammiert werden, man kann sogar ganz normale Konstruktoren programmieren usw.

Um eine "Instanz" zu erhalten muss man "Vererben", wird mit "extends" angezeigt


Interface:

es gibt überhaupt keine Möglichkeit etwas zu programmieren, alle Methoden sind automatisch public abstract, ein Interface ist also eine reine Sammlung von Methodensignaturen

Um eine "Instanz" zu erhalten, braucht man ein Objekt das alle Methoden implementiert (mit "implements" angezeigt)

 

[bygones]

Eine abstrakte Klasse kann Variablen definieren und Methoden implementieren.
Interfaces geben nur die Methodendefinition an.

 

[Icewind]

und man kann mehrere Interfaces implementieren aber nur von einer klasse ableiten

 

[m@nu]

interfaces können auch dazu verwendet werden, einfach "nur" eine sammlung von statischen, finalen objekten zur verfügung zu stellen (z.b. konstanten fürs gui etc.)

 

[bygones]

interfaces können auch dazu verwendet werden, einfach "nur" eine sammlung von statischen, finalen objekten zur verfügung zu stellen (z.b. konstanten fürs gui etc.)

Bad Practice... sollte man nicht machen... (obwohl es sowohl Sun selbst so macht...)

 

[m@nu]

naja, statisch halt schlussendlich... :-/
jop... die swing-konstanten sind doch über diese methode verfügbar, oder?

 

[Toasterwilli]

interfaces können auch dazu verwendet werden, einfach "nur" eine sammlung von statischen, finalen objekten zur verfügung zu stellen (z.b. konstanten fürs gui etc.)

Bad Practice... sollte man nicht machen... (obwohl es sowohl Sun selbst so macht...)

Und warum, wenn ich fragen darf? Kann sein, dass ich beim Thema Code-Hygiene noch etwas Nachholbedarf habe... :wink:

 

[Guest]

interfaces können auch dazu verwendet werden, einfach "nur" eine sammlung von statischen, finalen objekten zur verfügung zu stellen (z.b. konstanten fürs gui etc.)

Bad Practice... sollte man nicht machen... (obwohl es sowohl Sun selbst so macht...)

Sag's den Typen vom Eclipse Projekt. Die stecken alles in die Klasse SWT
als Konstanten rein. :? Ich könnte kotzen. :autsch:

 

[Roar]

interfaces können auch dazu verwendet werden, einfach "nur" eine sammlung von statischen, finalen objekten zur verfügung zu stellen (z.b. konstanten fürs gui etc.)

Bad Practice... sollte man nicht machen... (obwohl es sowohl Sun selbst so macht...)

Sag's den Typen vom Eclipse Projekt. Die stecken alles in die Klasse SWT
als Konstanten rein. :? Ich könnte kotzen. :autsch:

SWT is auch kein interface

 

[Guest]

OK, dann SwingConstants

 

[bygones]

Und warum, wenn ich fragen darf? Kann sein, dass ich beim Thema Code-Hygiene noch etwas Nachholbedarf habe... :wink:

Ein Interface dient als Definition von Schnittstellen, etwas, was die betreffende Klasse ist bzw. kann. Ein reines Konstanteninterface karikatiert das Ganze und missbraucht den Sinn eines Interfaces....

OK, dann SwingConstants

das hat nix mit dem Eclipse Leuten zu tun - das ist Sun. Und wie oben erwähnt halten sich die Sun Leute leider nicht daran !

 

[Guest]

OK, dann SwingConstants

das hat nix mit dem Eclipse Leuten zu tun - das ist Sun. Und wie oben erwähnt halten sich die Sun Leute leider nicht daran !

Klar. Ich meinte es nur als Beispiel für Konstanten in einem Interface.
Auch das bei SWT (OK, eine Klasse, kein Interface) sind es einfach zu viele Sachen an einem Haufen.
Die Folge davon ist, dass unnötig viele Konstanten initialisiert werden, selbst wenn sie gar nicht benötigt
werden. Ich ziehe es vor, die Dinger dort zu lassen, wo sie hingehören, statt alles global zu definieren.

 

[Gast]

alles an einem ort hat aber auch vorteile, laesst sich so zum bsp besser aus einer konfigurationsdatei laden, weil man dann nicht auf diverse verschiedene klassen zugreifen muss (welche dann ja auch erzeugt wuerden) und beim zugriff aehnlich, man muss nicht suchen wenn es mehrere moegliche orte gibt...
meine meinung: nachdenken statt nachmachen ^^

 

[Samuel]

Sorry, das ich so einen alten Thread ausgrabe, aber ich schreib auch bald Prüfung

Was ich sagen wollte, ist nicht einer der wichtigsten Unterschieden zwischen abstrakten Klassen und Interfaces die Möglichkeite mit der abstrakten Klasse einen Containtern für Polymorphie zu schaffen, um jeder Subklasse Methoden und Attribute zu geben, die in dem Container gebraucht werden?

Beispiel: Wenn ich eine abstrakte Klasse Vertrag habe, welche den Rumpf einer Funktion "Status" behinaltet, weil man in einem Programm alle Arten von Verträgen in eine Liste packen will und dort bei allen status aufrufen. Mit interfaces müsste ja jeder Vertrag diese implementieren, machts einer nicht, schießt man sich damt ins Knie.
Wenn man aber von Vertrag erbt, zwingt der Compiler die Methode zu implementieren, ob man will oder nicht.

So ungefähr richtig?

 

[Beni]

Der Compiler reklamiert auch wenn man eine Methode vergisst, die in einem Interface definiert wurde. Bei deinem Beispiel kann man sich nicht ins Knie schiessen :wink:

Ich würde den wichtigsten Unterschied darin sehen, dass abstrakte Klassen bereits fertige Methoden haben dürfen, Interfaces aber nur die Methodensignaturen.

 

[Samuel]

Sehe ich nicht so, durch eine abstrakte Klasse hat man keine Wahl, als davon zu erben, andersrum müssten dann ale "Arten" von Veträgen ein Interface implementieren, vergißt das mal jemand, hast du den Salat

 

[Roar]

also mich zwingt niemand von ner klasse zu erben. folgendes ist genau gleichwertig:

abstract class Vertrag {
public String status();
}

ist das gleiche wie

interface Vertrag {
public String status();
}

und salat hat man nur wenn man was falsch macht.

 

[Samuel]

Das ist mir klar, aber Schnittstellen müssen geschaffen werden und was macht mehr Sinn, eine abstrakte Klasse Vertrag, oder ein Interface?

 

[Roar]

Das ist mir klar, aber Schnittstellen müssen geschaffen werden und was macht mehr Sinn, eine abstrakte Klasse Vertrag, oder ein Interface?

hä :? anstrakte klassen müssen auch "geschaffen" werden :?
bei dem beispiel oben sind beide methoden genau gleichwertig, da macht keine methode mehr sinn. mehr sinn macht eine abstrakte klasse nur, wenn man auch die methoden implementiert, wie Beni sagte. ansonsten ist ein interface vorzuziehen.

 

[Beni]

Das ist mir klar, aber Schnittstellen müssen geschaffen werden und was macht mehr Sinn, eine abstrakte Klasse Vertrag, oder ein Interface?

Beides. Ein Interface Vertrag, und eine abstrakte Klasse die einige Methoden von Vertrag implementiert. Damit kann der Programmierer stets entweder Code sparen, oder alles selbst machen, je nachdem, was gerade besser passt.

 

[bygones]

wie Beni meint beides bereitzustellen ist schön - manchmal aber auch unnötig...

Im Grunde musst du eben wissen, ob es für deine Klasse schon eine Vererbungshierarchie gibt, so dass abstrakte Klassen schonmal wegfallen. Des weiteren, sobald du Methoden implementieren kannst oder Variablen definieren willst, ist natürlich das Interface unsinn.

Und falls es noch nicht gesagt wurde:

Ein Interface ist eine Spezialform einer abstrakten Klasse

 

[byte]

Beispiel: Wenn ich eine abstrakte Klasse Vertrag habe, welche den Rumpf einer Funktion "Status" behinaltet, weil man in einem Programm alle Arten von Verträgen in eine Liste packen will und dort bei allen status aufrufen. Mit interfaces müsste ja jeder Vertrag diese implementieren, machts einer nicht, schießt man sich damt ins Knie.
Wenn man aber von Vertrag erbt, zwingt der Compiler die Methode zu implementieren, ob man will oder nicht.

So ungefähr richtig?

Der Compiler zwingt Dich auch, die Methoden des Interface zu implementieren, wenn Du "implements DeinInterface" hinter die Klasse schreibst. Aber durch ne abstrakte Klasse kannst Du halt schon einen Teil der Implementierung vorschreiben, während Interfaces das gänzlich an die implementierende Klasse delegieren.

Demnach könnte ein Vertrag, der das Interface implementiert, immer den Status "alles super" zurückgeben, Du hast da keinen Einfluß mehr auf die Art und Weise, wie das ganze implementiert ist.

/edit: huch, viel zu langsam ... ???:L