Abstrakte Klasse und Interfaces

Bitte aktiviere JavaScript!
Moin.

Wenn ich allgemeine Methoden aufstellen will z.b. macheMusik(); und diese dann spezialisieren will, sodass ich die allgemeine Methode so wie ich sie brauche etwas abändere, sodass am Ende aus macheMusik(); etwas wie

geigeSpielen();
flöteSpielen();
gitarreSpielen();

wird. Wo schreibt man die allgemeine Methode hin und wo spezialisiert man dann die Methode?

Ist es richtig in der abstrakten Klasse eine ,,allgemeine Methode" aufzustellen und diese dann wenn sie benutzt werden soll in einer Subklasse spezialisiert werden kann? Oder ist das nicht möglich und dafür eignen sich interfaces besser?

Ein vogel kann fliegen(); ein Flugzeug kann fliegen();, d.h. es wäre ratsam fliegen in einem interface zu schreiben richtig? Kann ich dieses fliegen(); dann wiederum in Subklassen etwas umändern, sodass zb. langsamesFliegen bzw schnellesFliegen draus wird ?

Eine Frau und ein Mann sind Menschen, wobei Mensch als abstrakte Klasse=Superklasse von Frau und Mann gesehen werden kann, da es sinnlos ist einen Menschen anzulegen.

Also mir geht es darum interfaces und abstrakte Klassen etwas besser zu verstehen.
 
Du kannst eine Methode in einem Interface oder einer abstrakten Klasse deklarieren und diese Methode dann in einer abgeleiteten Klasse überschreiben. Dabei müssen aber der Methodenname und die Parametertypen identisch bleiben. Ansonsten weiß die JVM ja nicht, dass es sich bei der Methode in der Subklasse um eine Überschreibung der in dem Interface oder der Oberklasse deklarierten Methode handelt. Du kannst also das Verhalten der Methode überschreiben, nicht aber ihren Namen.
 
Vielen dank, dass mit den gleichen Namen war mir bewusst, hatte es nur zur ,,veranschaulichung" geschrieben. Hätte es erwähnen sollen. Mit überschreiben meinst du dass es möglich ist die allgemeine Methode aus einem Interface bzw einer abstrakten Klasse, dann ,,detailierter" in den betrachteten Subklassen zu implementieren/programmieren richtig?

Also nur damit ich es ganz genau verstanden habe.
 
Interface Vs. Abstract Class
Parameters Interface Abstract class
Speed Slow Fast
Multiple Inheritances Implement several Interfaces Only one abstract class
Structure Abstract methods Abstract & concrete methods
When to use Future enhancement To avoid independence
Inheritance/ Implementation A Class can implement multiple interfaces The class can inherit only one Abstract Class
Default Implementation While adding new stuff to the interface, it is a nightmare to find all the implementors and implement newly defined stuff. In case of Abstract Class, you can take advantage of the default implementation.
Access Modifiers The interface does not have access modifiers. Everything defined inside the interface is assumed public modifier. Abstract Class can have an access modifier.
When to use It is better to use interface when various implementations share only method signature. Polymorphic hierarchy of value types. It should be used when various implementations of the same kind share a common behavior.
Data fields the interface cannot contain data fields. the class can have data fields.
Multiple Inheritance Default A class may implement numerous interfaces. A class inherits only one abstract class.
Implementation An interface is abstract so that it can't provide any code. An abstract class can give complete, default code which should be overridden.
Use of Access modifiers You cannot use access modifiers for the method, properties, etc. You can use an abstract class which contains access modifiers.
Usage Interfaces help to define the peripheral abilities of a class. An abstract class defines the identity of a class.
Defined fields No fields can be defined An abstract class allows you to define both fields and constants
Inheritance An interface can inherit multiple interfaces but cannot inherit a class. An abstract class can inherit a class and multiple interfaces.
Constructor or destructors An interface cannot declare constructors or destructors. An abstract class can declare constructors and destructors.
Limit of Extensions It can extend any number of interfaces. It can extend only one class or one abstract class at a time.
Abstract keyword In an abstract interface keyword, is optional for declaring a method as an abstract. In an abstract class, the abstract keyword is compulsory for declaring a method as an abstract.
Class type An interface can have only public abstract methods. An abstract class has protected and public abstract methods.
 
Mit überschreiben meinst du dass es möglich ist die allgemeine Methode aus einem Interface bzw einer abstrakten Klasse, dann ,,detailierter" in den betrachteten Subklassen zu implementieren/programmieren richtig?
Was du dann genau in der überschreibenden Methode machst, ist völlig dir überlassen. Ich würde da Worte wie "detaillierter" nicht verwenden.
Du kannst die Methode halt komplett anders implementieren, oder einfach nur `super.dieMethode();` aufrufen, falls du die Methode in einer eventuellen Basisklasse bereits implementiert hast, oder auch einfach nichts tun (also den Methodenbody leer lassen, falls die Methode void zurückliefert).
 
Na gut, vielleicht ist dies auch die beste existierende, schlecht ist sie trotzdem :p


Ein Versuch (der keineswegs Anspruch auf Vollständigkeit stellt und gerne ergänzt werden darf):

Interfaceabstrakte KlasseKlasse
kann ... implementieren/erweiternInterfacesInterfaces und KlassenInterfaces und Klassen
Subtypen können ...mehrere Interfaces implementierennur eine (abstrakte) Klasse erweiternnur eine (abstrakte) Klasse erweitern
Felder sind ...nicht erlaubtprivate, package-private, protected, publicprivate, package-private, protected, public
statische Felder sind ...publicprivate, package-private, protected, publicprivate, package-private, protected, public
Methoden sind ...private, public (default)private, package-private, protected, publicprivate, package-private, protected, public
statische Methoden sind ...private, publicprivate, package-private, protected, publicprivate, package-private, protected, public
abstrakte Methoden sind ...publicpackage-private, protected, publicnicht erlaubt
enthält KonstruktorenNeinJaJa
Nutzen als ...öffentliche SchnittstelleDefault-Implementation, wenn sich diese nicht durch Interfaces abbilden lässtKonkrete Implementation
 
Danke, aber wo sind die konkreten Probleme mit der andern Tabelle?
When to use Future enhancement To avoid independence
Keine Ahnung was "Future enhancement" und "To avoid independence" dabei bedeuten soll, vielleicht versteh ich das auch falsch.
Das Interfaces, wenn sie einmal öffentlich waren, nicht mehr erweitert werden konnten, ohne abhängigen Code zu brechen, war bis Java 8 das Problem von Interfaces. Und Unabhängig will man in den meisten Fällen ja nicht vermeiden.

Structure Abstract methods Abstract & concrete methods
Implementation An interface is abstract so that it can't provide any code. An abstract class can give complete, default code which should be overridden.
Konkrete Methoden sind auch in Interfaces möglich, "should be overridden" klingt etwas merkwürdig.

Default Implementation While adding new stuff to the interface, it is a nightmare to find all the implementors and implement newly defined stuff. In case of Abstract Class, you can take advantage of the default implementation.
Beide Punkte gelten für beides. Neue abstrakte Methoden einzuführen ist immer ein Problem, deshalb unterstützen Interfaces ja jetzt default-Methoden.

Access Modifiers The interface does not have access modifiers. Everything defined inside the interface is assumed public modifier. Abstract Class can have an access modifier.
Use of Access modifiers You cannot use access modifiers for the method, properties, etc. You can use an abstract class which contains access modifiers.
Private ist auch in Interfaces möglich.

When to use It is better to use interface when various implementations share only method signature. Polymorphic hierarchy of value types. It should be used when various implementations of the same kind share a common behavior.
Mit default-Methoden ist dies für die meisten abstrakten Klassen kein Grund mehr, und in den andere Fällen sollte es kein "entweder oder" sondern ein "und" sein.

Defined fields No fields can be defined An abstract class allows you to define both fields and constants
Konstanten (public static final) sind auch in Interfaces möglich.

Constructor or destructors An interface cannot declare constructors or destructors. An abstract class can declare constructors and destructors.
Gibt keine "destructors" in Java. (Außer man sieht das (deprecated) finalize als solches).

Class type An interface can have only public abstract methods. An abstract class has protected and public abstract methods.
Abstrakte Klasse können auch package-private abstrakte Methoden haben. (Und was soll "Class type" in dem Zusammenhang?)
 
Also mir geht es darum interfaces und abstrakte Klassen etwas besser zu verstehen.
Ich handhabe das so, daß ich erstmal möglichst viel über die Bedeutung von etwas sinniere.
Dein Beispiel mit den Klassen Mann und Frau (und Kind, und Jugendlicher) von der abstrakten Klasse Mensch abzuleiten wäre meiner Meinung nach richtig, das würde ich auch so machen.

Bei deinem Beispiel Vogel und Flugzeug ist es etwas komplizierter und kommt sehr auf den Anwendungsfall drauf an.
Du könntest Vogel von der abstrakten Klasse Lebewesen, und Flugzeug von der abstrakten Klasse Maschine ableiten, und bei beiden das Interface 'Flugfähig' implementieren. Die Konvention, das Interfaces 'Xable' benamst werden, kommt nicht von ungefähr.

Genauso könntest du Vogel und Flugzeug auch von der abstrakten Klasse Flugobjekt ableiten. Wie gesagt, das kommt sehr auf deinen Anwendungsfall an und ist so ein Ding, wo Softwareentwicklung etwas ins Philosophische entgleitet.


Manchmal gibt dir die Sprache auch einfach vor, was du nehmen solltest. Ich wollte vor einier Zeit eine Baumstruktur realisieren. Am liebsten hätte ich das über ein Interface gemacht und wäre theoretisch möglich gewesen.
Das Problem ist: Man kann in Interfaces zwar Methoden vorimplementieren, aber keine Instanzvariablen halten. Und wie soll ein TreeItem ohne Instanzvariablen seine Kinder vorhalten?
Und da ich das ohne Instanzvariablen schlicht nicht implementieren konnte, mußte das zwangsläufig in eine Klasse. Hätte ich das dann trotzdem als Interface gebaut, hätte ich exakt den gleichen Code in jeder Klasse implementieren und testen müssen, die ich in den Baum schmeißen will. Und das ist häßlich.

Also: Betrachtungsweise ändern. Es gibt dann eben eine abstrakte Klasse TreeItem, von der alle anderen Klassen in der Baumstruktur abgeleitet werden. Dann sitzen im Baum keine "Itemisierbaren", sondern halt "TreeItems". Das bringt zwar wieder andere Nachteile mit sich...aber zumindest in meinem Anwendungsfall werden die Nachteile vorraussichtlich nicht so sehr ins Gewicht fallen.
 
Dein Beispiel mit den Klassen Mann und Frau (und Kind, und Jugendlicher) von der abstrakten Klasse Mensch abzuleiten wäre meiner Meinung nach richtig, das würde ich auch so machen.
Ich würde eine zeitlich variante Eigenschaft wie das Alter bzw. den Altersbereich einer Person nicht als statische Vererbung modellieren. Heute ist Klausi noch ein Kind, und wurde so in der Software modelliert/angelegt. Aber morgen ist sein Geburtstag und er wird Jugendlicher; oder ist heute ein Jugendlicher und morgen ein Mann. Ähnliches kann man heutzutage sogar für das Geschlecht einer Person annehmen.
Es ist immer wichtig, sich zu fragen, wann und aus welchen Gründen Änderungen an den fachlichen Anforderungen oder den zu modellierenden Daten und Funktionalität entstehen und wie flexibel das Design hierauf reagieren kann.
Software Engineering ist nichts weiter als, mit Veränderung umgehen zu können. Wenn sich nichts ändert, ist es völlig egal, wie man eine Software modelliert.
 
Ich würde eine zeitlich variante Eigenschaft wie das Alter bzw. den Altersbereich einer Person nicht als statische Vererbung modellieren.
Ha...siehste, an solch einen Anwendungsfall hab ich auch nicht gedacht. Tja, wenn man das braucht...

Wenn sich nichts ändert, ist es völlig egal, wie man eine Software modelliert.
Dem widerspreche ich jedoch entschieden. Eine gute Softwaremodelierung ist meiner Meinung nach schon bei der ersten Implementierung wichtig. Wenn ich dran denke wieviel ich bei meinem Bauteilgenerator schon gelöscht und wieder von vorne programmiert habe weil einfach die Modellierung von Anfang an sch...rott war und ich mich in meinem eigenen Code verheddert habe...Codelesbarkeit vor Performance.
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben