# abstract - interface Unterschied



## toxice (3. Okt 2005)

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 (3. Okt 2005)

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 (3. Okt 2005)

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


----------



## Icewind (3. Okt 2005)

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


----------



## m@nu (3. Okt 2005)

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 (3. Okt 2005)

m@nu hat gesagt.:
			
		

> 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 (3. Okt 2005)

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


----------



## Toasterwilli (4. Okt 2005)

deathbyaclown hat gesagt.:
			
		

> m@nu hat gesagt.:
> 
> 
> 
> ...



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


----------



## Guest (4. Okt 2005)

deathbyaclown hat gesagt.:
			
		

> m@nu hat gesagt.:
> 
> 
> 
> ...


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


----------



## Roar (4. Okt 2005)

Anonymous hat gesagt.:
			
		

> deathbyaclown hat gesagt.:
> 
> 
> 
> ...


SWT is auch kein interface


----------



## Guest (4. Okt 2005)

OK, dann SwingConstants


----------



## bygones (4. Okt 2005)

Toasterwilli hat gesagt.:
			
		

> 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 (4. Okt 2005)

deathbyaclown hat gesagt.:
			
		

> > 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 (4. Okt 2005)

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 (28. Jan 2006)

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 (28. Jan 2006)

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 (28. Jan 2006)

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 (28. Jan 2006)

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 (28. Jan 2006)

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


----------



## Roar (28. Jan 2006)

Samuel hat gesagt.:
			
		

> 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 (28. Jan 2006)

Samuel hat gesagt.:
			
		

> 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 (28. Jan 2006)

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 (28. Jan 2006)

Samuel hat gesagt.:
			
		

> 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


----------

