# Ist die abstract class das selbe wie ein interface ?



## Azazel (21. Aug 2016)

Moin,
Kürzlich lernte ich diese beiden Klassen, aber mir ist der Sinn danach, dass beide das selbe sind.
Naja, nicht das selbe, aber man kann mit beiden das selbe Erreichen.

In einem Interface werden halt eben nur static Felder/Methoden erstellt.


----------



## Xyz1 (21. Aug 2016)

Azazel hat gesagt.:


> In einem Interface werden halt eben nur static Methoden erstellt.



Nicht richtig, abstrakte Methoden, wenn schon, keine Implementierungen, das auch der wesentliche Unterschied.

Edit: http://stackoverflow.com/questions/512877/why-cant-i-define-a-static-method-in-a-java-interface


----------



## Azazel (21. Aug 2016)

Alles Klar^^


----------



## thecain (21. Aug 2016)

Java 8 sagt hallo


----------



## Xyz1 (21. Aug 2016)

Ja, in Java 8 ist das möglich, das wurde etwas vermischt. (Fragt sich, wie lange noch) Ich sollte mal die Links lesen, die ich gib.  Aber es bleibt dabei, dass eine Teilweise Logikimplementierung in eine abstrakte Klasse zugehörig ist - da von Interfaces normalerweise keine Instanz erstellt werden darf. ... Alles Weitere, das wäre jetzt schon eine Abhandlung, die ich nicht gib kann.


----------



## 4a61766120617274697374 (21. Aug 2016)

Ein guter C++ Programmierer hat mir den Unterschied folgendermassen erklärt. 

Eine abstrakte Klasse verwendest du, wenn du die Logik deiner Implementierung zum grössten Teil kennst und daher in der Oberklasse schon implementieren kannst. So sind nur noch die Methoden abstrakt, bei denen du noch nicht weisst, wie diese in den einzelnen Klassen dann implementiert werden sollen.

Interfaces verwendest du, wenn du gar nicht weisst wie du die einzelnen Methoden implementieren sollst. Z.B. eine Login Klasse hat ein einloggen() und ausloggen(). Da du aber nicht weisst, wie ein einloggen und ausloggen in deinen Unterklassen implementiert wird, erstellt du deine Oberklasse als Interface.

Das mal zum "wann verwende ich was". Zudem kommen noch Feinheiten dazu, dass eine abstrakte Klasse nicht instanziiert werden kann und dass du mehrere Interfaces implementieren kannst etc. Den Rest kannst du bei Google nachlesen.

Ich hoffe ich konnte dir weiterhelfen.


----------



## stg (22. Aug 2016)

Wenn das wirklich die Aussage dieses C++-Programmierers war, dann zweifle ich das "gut" doch stark an. 



> An *interface* is a description of the behaviour an implementing class will have. The implementing class ensures, that it will have these methods that can be used on it. It is basically a contract or a promise the class has to make.
> An *abstract class* is a basis for different subclasses that share behaviour which does not need to be repeatedly be created. Subclasses must complete the behaviour and have the option to override predefine behaviour (as long as it is not defined as final or private).


Siehe: http://stackoverflow.com/a/18778228/1803294

Auch, wenn in Java8 default-Implementierungen in Interfaces hinzugekommen sind, so bleibt dennoch der wesentliche Unterschied, dass abstrakte Klasse einen eigenen inneren Zustand besitzen, mit dem man arbeiten kann, Interfaces hingegen nicht.


----------



## Flown (23. Aug 2016)

Geschweige davon, dass man nur von einer abstrakten Klasse "erben" kann und von vielen Interfaces.


----------



## Xyz1 (23. Aug 2016)

Es gibt ganz viele Unterschiede, die ich nicht bereit bin, alle aufzuzählen, aber Ja, teilweise Logikimplementierung gehört in eine abstrakte Klasse, Interfaces sollten keine Implementierung enthalten, von ihnen darf "normalerweise" keine Instanz erstellt werden, und Mehrfachvererbung gibt es viel Pro und Contra.


----------



## stg (23. Aug 2016)

DerWissende hat gesagt.:


> Es gibt ganz viele Unterschiede, die ich nicht bereit bin, alle aufzuzählen, aber Ja, teilweise Logikimplementierung gehört in eine abstrakte Klasse, Interfaces sollten keine Implementierung enthalten, von ihnen darf "normalerweise" keine Instanz erstellt werden, und Mehrfachvererbung gibt es viel Pro und Contra.



Den selben Blödsinn hast du vorher schon geschrieben. Dadurch, dass du es wiederholst, wird es nicht besser.
Weder abstrakte Klasse noch Interfaces können instantiiert werden. Und nein, anonyme innere Klassen sind da kein "Gegenbeispiel", falls du das im Sinn haben solltest. Hier wird nämlich die anonyme innere Klasse instantiiert und nicht das Interface bzw abstrakte Klasse.
Mehrfachvererbung kann man kontrovers diskutieren, das ist richtig, aber diese Feststellung geht an der Frage vorbei. Und im Grunde ist es auch egal, da Mehrfachvererbung in Java nunmal nicht möglich ist. 
Den wesentlichen Unterschied zwischen Interface und abstrakte Klasse habe ich ja bereits in Beitrag #7 genannt. Das hat nichts mit Multi-Vererbung oder dem Umstand, wo Implementierungen zu finden sind, zu tun.


----------



## Xyz1 (23. Aug 2016)

Das ist kein Blödsinn, sondern nüchterne Tatsachenbeschreibung. Auf deinem Kindergartenniveau brauchen wir gar nicht weiterdiskutieren.


----------



## mrBrown (23. Aug 2016)

Unsinn reden und ausfallend werden, Diskussionskultur im Land der Dicher und Denker


----------



## VfL_Freak (23. Aug 2016)

DerWissende hat gesagt.:


> Das ist kein Blödsinn, sondern nüchterne Tatsachenbeschreibung. Auf deinem Kindergartenniveau brauchen wir gar nicht weiterdiskutieren


Wie wäre es, wenn Du Dich mal ein wenig mäßigen würdest ?? 
Oder ist das auch unter Deinem Niveau ?? 

Gruß Klaus


----------



## Xyz1 (23. Aug 2016)

Ja, ich hab etwas einsehen, aber es ist doch so, dass er ohne Gegenbeweis sagt, das wäre Blödsinn. Den kann ich nämlich in dem, was ich schrieb, NICHT erkennen. Aber gern wieder On-topic.


----------



## mrBrown (23. Aug 2016)

DerWissende hat gesagt.:


> Nicht richtig, abstrakte Methoden, wenn schon, keine Implementierungen, das auch der wesentliche Unterschied.



Stimmt nicht, mit Java 8 möglich, wie du ja dann auch selbst einsiehst...



DerWissende hat gesagt.:


> Ja, in Java 8 ist das möglich, das wurde etwas vermischt. (Fragt sich, wie lange noch) Ich sollte mal die Links lesen, die ich gib.



...allerdings machst du dann mit dem nächstem Unsinn weiter



DerWissende hat gesagt.:


> Aber es bleibt dabei, dass eine Teilweise Logikimplementierung in eine abstrakte Klasse zugehörig ist



Eben nicht, sagst du ja im Satz vorher selbst auch noch.



DerWissende hat gesagt.:


> - da von Interfaces normalerweise keine Instanz erstellt werden darf.


Von abstrakten Klassen aber genauso wenig. Aber Gemeinsamkeit und Unterschied verwechselt man ja schnell mal...



DerWissende hat gesagt.:


> Es gibt ganz viele Unterschiede, die ich nicht bereit bin, alle aufzuzählen,


Bisher hast du zumindest noch keinen einzigen genannt^^



DerWissende hat gesagt.:


> aber Ja, teilweise Logikimplementierung gehört in eine abstrakte Klasse, Interfaces sollten keine Implementierung enthalten,



Das "sollte" kann man immerhin als Meinung zu best practice auslegen. Ansonsten hattest du den Punkt oben schon mal, und er ist nicht richtiger geworden...  



DerWissende hat gesagt.:


> von ihnen darf "normalerweise" keine Instanz erstellt werden,


...und das hattest du auch schon mal, auch immer noch falsch.



DerWissende hat gesagt.:


> und Mehrfachvererbung gibt es viel Pro und Contra.


Pro und Contra = In Java nicht möglich, also am Thema vorbei.



Genug "Gegenbeweis"?


----------



## mrBrown (23. Aug 2016)

Die wesentlichen Unterschiede wurden ja schon genannt:



stg hat gesagt.:


> Auch, wenn in Java8 default-Implementierungen in Interfaces hinzugekommen sind, so bleibt dennoch der wesentliche Unterschied, dass abstrakte Klasse einen eigenen inneren Zustand besitzen, mit dem man arbeiten kann, Interfaces hingegen nicht.





Flown hat gesagt.:


> Geschweige davon, dass man nur von einer abstrakten Klasse "erben" kann und von vielen Interfaces.


----------



## Xyz1 (23. Aug 2016)

Eine Sache kann gleichzeitig Vor- und Nachteile haben. Wo bin ich hier gelandet? Ponnyhof?


----------



## mrBrown (23. Aug 2016)

DerWissende hat gesagt.:


> Eine Sache kann gleichzeitig Vor- und Nachteile haben.


In diesem Thread werden aber weder Vor- noch Nachteile von irgendwas erwähnt 



DerWissende hat gesagt.:


> Wo bin ich hier gelandet? Ponnyhof?


Nein, in Neuland.


----------



## Flown (23. Aug 2016)

Warum müssen manche Threads in einem Kindergarten enden und schlittern dann total am eigentlichen Thema vorbei? Ich hab das schon mal gesagt, wenn man Aussagen trifft dann bitte auch fundieren!

B2Topic:
Grundsätzlich sind es zwei komplett verschiedene Konzepte.

Interfaces: 
- Sind Baupläne die eine gewisse Schnittstelle garantieren, denn alle deklarierten Methoden sind public und müssen implementiert werden.
- Das Interface besitzt keinen internen State. 
- Oder es können auch "Marker"-Interfaces existieren (siehe Cloneable).
- Grundsätzlich darf eine Klasse, in Java, mehrere Interfaces implementieren. 

Bei den "Neuerungen" - mittlerweile schon 2 Jahre her - in Java 8 wurden extension methods für Interfaces hinzugefügt. Nicht damit man gewissen Code in Interfaces auslagert, sondern damit Interface Evolution und Backward compatibility gesteigert wird.
Static Felder/Methoden können seit Java 8 auch in Interfaces existieren, damit man companion classes - Utility Klassen im Allgemeinen, wie z.B. die Klasse Collections - verhindert und Factory Pattern fördert. D.h. in Java 9 wird es sowas wie eine Factory Methode "Set.newSet()" geben. Warum ist das Sinnvoll? Weil ein 08/15 Programmierer sich nicht mit Implementierungen eines Sets beschäftigen müssen, sondern die Common Case Implementierung erhalten (falls man sich spezialisieren muss, dann muss man auch danach suchen und sich damit beschäftigen).

Abstrakte Klasse: 
- Ist eine nicht instanzierbare Klasse, die abstrakte Methoden enthalten kann.
- Abstrakte Klassen können, aber müssen keinen internen State besitzen - tun sie aber in der Regel - und werden dazu verwendet gleiches Verhalten zu zentralisieren.
- Abstrakte Klassen garantieren kein Schnittstelle, da abstrakte Methoden auch protected sein können und somit auch nicht sichtbar außerhalb des Packages und der Klasse sind.
- Im Gegensatz zu Interfaces kann man nur eine abstrakte Klasse implementieren (keine Mehrfachvererbung in Java), da es eine Klasse ist.

Also kann man hier keine Vor- und Nachteile der Konzepte darlegen, weil es grundlegende Programmierkonzepte sind. Man kann nur für Use-Cases Vor- und Nachteile identifizieren und die richtigen Stilmittel (Interfaces oder abstrakte Klassen) verwenden.


----------



## 4a61766120617274697374 (24. Aug 2016)

stg hat gesagt.:


> Wenn das wirklich die Aussage dieses C++-Programmierers war, dann zweifle ich das "gut" doch stark an.


Das was ich oben beschrieben habe, ist nur ein Grund von vielen, wann was verwendet wird. Bei Schnittstellen kennst du die implementierung ja noch nicht. Du kennst das WAS, aber das WIE kennst du nocht nicht. Dazu kommen noch sicherlich andere Gründe dazu wie "Inversion of Control" etc. Bei einer abstrakten Klasse kennst du teilweise das WIE (auf die Klasse bezogen). Die anderen Regeln, wie, dass eine abstrakte Klasse nicht instanziiert werden kann und das man mehrere interfaces implemenieren kann ist doch klar. Das steht in jedem Buch.


----------



## stg (25. Aug 2016)

Dann möchte ich meine Aussage von oben gerne noch ein wenig ausführen.
Die genannten Punkte sollten keine Beweggründe für die Wahl eines Interfaces und/oder einer abstrakten Klasse sein. Wenn jemand das so nennt, dann hat er für mich entweder die eigentlichen Konzepte, die dahinter stecken nicht verstanden, oder es geht ihm nur darum, möglichst schnell (irgendwie) lauffähigen Code zu schreiben. Geht man so vor endet man sicherlich deutlich häufiger mit schlecht designtem, schlecht wartbaren und häufig fehleranfälligem Code. Der Einsatz von Interfaces und/oder Abstrakten Klassen ist stets eine Desing-Entscheidung, die wohl überlegt sein will und nicht "aus der Not heraus" entstehen sollte. Aber genau so kam deine Ausführung in Beitrag #6 für mich herüber.
Speziell auf deinen Beitrag #20 bezogen:


4a61766120617274697374 hat gesagt.:


> Bei Schnittstellen kennst du die implementierung ja noch nicht. Du kennst das WAS, aber das WIE kennst du nocht nicht.


Wenn du in dieser Aussage die beiden "noch" streichst, dann kommt man der Wahrheit näher. Der "Client", der den "Dienst" nutzt, muss und soll oft über das WIE gar nichts wissen. Das Interface stellt lediglich eine Art Vertrag nach außen über das WAS dar. Zweck ist ganz einfach das Erreichen einer möglichst geringen Kopplung. Eine solche Entscheidung sollte aber niemals davon getrieben sein, dass man die Implementierung des "Dienstes" noch nicht kennt.


----------



## AndiE (25. Aug 2016)

Ich würde das so festmachen: Wenn ich eine Anwendung schreibe, in der es um den Verleih von unterschiedlichen Dingen geht, dann kann ich all diese Dinge von einer Klasse "Item" ableiten. Alle Klassen, die die Ausleihgegenstände beschreiben enthalten eine Methode "getPrice()", die die Leihgebühr berechnet. Da sich diese jedoch für jeden Gegenstand anders berechnet, würde ich die als "abstrakte Methode" in Item ablegen, was Item per definitionem zur abstrakten Klasse macht. Den Ausleihvorgang selbst würde ich so gestalten, dass die aufrufende Klasse Renting über ein Interface IItem mit den Ausleihdingen verbunden ist. In Renting und auch in den von IItem abgeleiteten Klassen müssen dann die im Interface festgelegten Methoden implementiert werden. Ich finde, wenn ich diese Methoden in der abstrakten Klasse deklarieren würde, habe ich die Schwierigkeit, wie Renting da ran kommt. Ich müsste sie duplizieren, was fehleranfällig ist.

Liege ich mit meiner Meinung richtig?


----------



## mrBrown (25. Aug 2016)

AndiE hat gesagt.:


> Ich würde das so festmachen: Wenn ich eine Anwendung schreibe, in der es um den Verleih von unterschiedlichen Dingen geht, dann kann ich all diese Dinge von einer Klasse "Item" ableiten. Alle Klassen, die die Ausleihgegenstände beschreiben enthalten eine Methode "getPrice()", die die Leihgebühr berechnet. Da sich diese jedoch für jeden Gegenstand anders berechnet, würde ich die als "abstrakte Methode" in Item ablegen, was Item per definitionem zur abstrakten Klasse macht. Den Ausleihvorgang selbst würde ich so gestalten, dass die aufrufende Klasse Renting über ein Interface IItem mit den Ausleihdingen verbunden ist. In Renting und auch in den von IItem abgeleiteten Klassen müssen dann die im Interface festgelegten Methoden implementiert werden. Ich finde, wenn ich diese Methoden in der abstrakten Klasse deklarieren würde, habe ich die Schwierigkeit, wie Renting da ran kommt. Ich müsste sie duplizieren, was fehleranfällig ist.



Item soll (abstrakte) Klasse für auszuleihende Objekte sein, IItem Interface für dieselben und Renting worüber man ausleiht?


----------



## Xyz1 (25. Aug 2016)

In welchem Anwendungsfall wer was wie (und wann) implementieren soll, ist am Thema vorbei, zu umfangreich und Sache des Mittleren Managements, zu den ich auch zähle.

Sollen die falschen Annahmen des Fragestellers richtiggestellt werden und die Unterschiede abstrakte Klasse vs. Interface deutlich werden - oder geht es jetzt schon um Design Pattern in Analyse, Entwurf und Realisierung eines mittleren Softwareprojekts?

Wenn ich jetzt schon ewas von GRASP und hohe Kohäsion, niedrige Kopplung lese, bin ich mir nicht sicher, ob danach gefragt wurde.


----------



## AndiE (25. Aug 2016)

@mrBrown: genauso habe ich mir das gedacht.

@DerWissende: Auch wenn mein Beispiel daneben sein mag, helfen doch konkrete Beispiele eher abstrakte Erläuterungen zu veranschaulichen.


----------



## mrBrown (25. Aug 2016)

AndiE hat gesagt.:


> @mrBrown: genauso habe ich mir das gedacht.


Die abstrakte Klasse kann man sich dann erstmal sparen, man braucht nur das Interface Item, welches dann alle öffentlichen Methoden enthält.
Die abstrakte Klasse kann man dann später hinzufügen, wenn nötig, sollte aber immer auch ohne funktionieren.
(Bei der Benennung würde ich immer den Abstrakten Klassen Präfixe geben, nicht dem Interface, finde ich deutlich klarer und wird auch in den Standardlibs so gemacht)


----------



## Harry Kane (25. Aug 2016)

AndiE hat gesagt.:


> Auch wenn mein Beispiel daneben sein mag, helfen doch konkrete Beispiele eher abstrakte Erläuterungen zu veranschaulichen.


Sehe ich nicht so. Aus meiner Sicht ist der abstraken Erläuterung von flown nichts hinzuzufügen:
Abstrakte Klassen können einen instanzspezifischen state beinhalten (also Instanzvariablen), und Methoden, sowohl abstrakte als auch nicht abstrakte, können protected sein. Beides ist bei interfaces nicht möglich.


----------



## Xyz1 (25. Aug 2016)

AndiE hat gesagt.:


> @DerWissende: Auch wenn mein Beispiel daneben sein mag, helfen doch konkrete Beispiele eher abstrakte Erläuterungen zu veranschaulichen.



verdeutlichen, veranschaulichen, sichtbar machen, skizzieren, umreißen... ich meinte damit, die Frage ist: "Ist eine abstrakte Klasse das selbe wie ein Interface ?", und da geht's dann zunäcst um die Unterschiede zwischen .. und .. .


----------



## Meniskusschaden (25. Aug 2016)

Hm, seltsame Diskussion, die hier entstanden ist. Kann doch nicht so schlimm sein, wenn jemand ein Beispiel liefert, obwohl es bereits eine abstrakte Erklärung gibt.

Bin allerdings nicht sicher, ob ich richtig verstanden habe, warum auch die Klasse Renting die Schnittstelle IItem implementieren soll. Ist es so gedacht, dass man ein Renting-Objekt benutzt, um ein Item auszuleihen und das Renting-Objekt den Preis an den Aufrufer durchreicht?


----------



## Xyz1 (25. Aug 2016)

tl;dr Aber ist Item jetzt abstrakt, Interface oder Klasse (Enum wohl nicht  )? UML(2)-Diagramm würd hier helfen. Da die Berechnung des Preis wohl atomar ist, würd ich eher zu Interface tendieren. Ich setze das einfach mal um...


----------



## Meniskusschaden (25. Aug 2016)

Ich habe es so verstanden: IItem ist ein Interface, in dem die Methode getPrice() definiert ist. Item ist eine abstrakte Klasse, die IItem implementiert. Renting ist eine Klasse, die ebenfalls IItem implementiert, aber nicht von Item abgeleitet ist.


----------



## Xyz1 (25. Aug 2016)

Hab es jetzt so aufgefasst:

```
interface IItem {

    float getPrice();
}

abstract class AItem implements IItem {

    public float getMws() {
        return getPrice() * 1.19f;
    }
}

interface BuchItem {

    String getTitle();

    String getAuthor();
}

class Buch extends AItem implements BuchItem {

    String title, author;
    float price;

    public Buch(String title, String author, float price) {
        this.title = title;
        this.author = author;
        this.price = price;
    }

    @Override
    public float getPrice() {
        return price;
    }

    @Override
    public String getTitle() {
        return title;
    }

    @Override
    public String getAuthor() {
        return author;
    }
}

class Renting {
}
```

Wobei das wohl noch keinen Sinn macht, ich muss ja irgendwo noch speichern, ob und an wen ein Buch verliehen ist!


----------



## AndiE (25. Aug 2016)

Ich habe das Beispiel gegeben, um zu zeigen, wie unterschiedlich Interfaces und abstrakte Klassen angewendet werden. So richtig und wichtig die Erklärungen sind, sind beides doch Werkzeuge in der Praxis. Nach meiner Erfahrung werden beide Konstrukte in Büchern eher mit der spitzen Zange angefaßt. Allerdings werden zumindest Interfaces bei der Programmierung von JSF und bei der Test Driven Developement sehr massiv benutzt. Nach meiner Erfahrung mit einem anderen Benutzer hier sind nicht alles Experten, sondern manche auch Anfänger. Und nicht nur denen hilft es, mit Beispielen zu lernen. Ich meine, dass, um auf den ersten Post zurückzukommen, bei beiden genannten Anwendungsfällen die Interfaces nicht durch abstrakte Klassen ersetzt werden können.
In meinem Beispiel ist der Name für das Interface schlecht gewählt, das sehe ich nun auch ein. Ich würde es jetzt eher als "Rentable" bezeichnen,. Es verinnerlicht in sich genau die Methoden, die notwendig sind, um bestimmte Dinge an einen Kunden über einen Zeitraum auszuleihen. Um bei dem Codebeispiel zu bleiben, würde man doch beim Ausleih von Büchern, CD's und DVD's diese Klassen von einer gemeinsamen Klasse ableiten. Diese würde ja Methoden zur Verwaltung von Name, Bezeichnung und Ort enthalten und ich würde auch eine abstrakte Methode hinzufügen, um den Preis zu berechnen. So wie ich oben schon geschrieben habe. Diese abstrakte Methode würde dann in den einzelnen Gegenstandsklassen speziell angepasst werden.


----------



## Xyz1 (25. Aug 2016)

Ist es schon so spät oder versteht ihr auch nur Bahnhof?

Sag doch einfach, so und so würdst das mit dem und dem Design Pattern machen, wir können dann ja sagen: Simmt oder nicht.


----------

