Ist die abstract class das selbe wie ein interface ?

[Azazel]

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]

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]

Alles Klar^^

 

[thecain]

Java 8 sagt hallo

 

[Xyz1]

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]

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]

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]

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

 

[Xyz1]

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]

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]

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

 

[mrBrown]

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

 

[VfL_Freak]

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]

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]

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...

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

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.

- da von Interfaces normalerweise keine Instanz erstellt werden darf.

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

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

Bisher hast du zumindest noch keinen einzigen genannt^^

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...

von ihnen darf "normalerweise" keine Instanz erstellt werden,

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

und Mehrfachvererbung gibt es viel Pro und Contra.

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



Genug "Gegenbeweis"?

 

[mrBrown]

Die wesentlichen Unterschiede wurden ja schon genannt:

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.

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

 

[Xyz1]

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

 

[mrBrown]

Eine Sache kann gleichzeitig Vor- und Nachteile haben.

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

Wo bin ich hier gelandet? Ponnyhof?

Nein, in Neuland.

 

[Flown]

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]

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]

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:

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]

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]

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]

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]

@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]

@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]

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]

@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]

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]

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]

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]

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]

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]

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.