Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Ich bin nun dabei ein Hintergrundwissen aufzubauen. Im Rahmen der Polymorphie wird von Abstracten Methoden gesprochen, die keinen Code in der SuperClass haben, da sie dann in den darunter liegenden Classen definiert wird.
Kann mich jemand 'aufklären' was der Vorteil einer Superklasse ist, die keinen Code in der Methode hat. Dann kann ich doch einfach direkt in jeder meiner untergeordneten Class eine Methode mit Code erzeugen.
Danke für die Erklärung.
Natürlich kann man auch einfach per Konvention in den abgeleiteten Klassen solche Methoden deklarieren. Bei abstrakten Klassen (oder auch bei Interfaces) erzwingt der Compiler aber diese Konvention.
Für den Verwender ist es dann egal, mit welcher abgeleiteten Klasse er es zu tun hat; wenn er nichts von irgendwelchen Spezifika der abgeleiteten Klasse wissen muss, dann kann er einfach nur mit dem (hier abstrakten) Basistyp umgehen.
Das hilft (insbesondere in größeren Projekten), die Kopplung zwischen verschiedenen Programmteilen zu verringern und erleichtert so spätere Änderungen/Erweiterungen.
von Murrays Antwort:
Könnte man dann den grössten Vorteil so formulieren, das durch abstract method sichergestellt wird, dass in allen untergeordneten Klassen die gleiche Nomenklatur verwendet wird?
von SlaterB Antwort:
Mit Interfaces kann ich dann also ein Konzept realisieren, wo eine Class 'in gewisser Art', zwei Superclassen haben kann (ich weiss, dass geht nicht direkt). Aber dann verstehe ich noch nicht was der Vorteil einer abstract method ohne Code ist.
wie gesagt: bevor du dich nicht zu Interface allgemein klar äußerst, brauch man über abstrakte Klassen nicht reden,
kennst du Interface wie List für ArrayList/LinkedList oder Comparable für nahezu alle Klassen, die dann mit nur einem Code sortiert werden können?
Interface ist die EINE Grundlage überhaupt für Polymorphie und quasi alles in Objektorientierung
Grundsätzlich ist es immer gut gegen das "kleinste gemeinsame" zu programmieren - also gegen Interfaces und abstrakte Klassen. (Hast Du Dich bereits mit Interfaces auseinander gesetzt? Falls nein, würde ich damit anfangen)
Dadurch hat man letztendlich einer höhere Flexibiliät oder kann unterschiedliche Ausprägungen basierend auf einem gemeinsamen Interface oder abstrakten Klasse gemeinsam verwalten.
(Bsp. Wenn Du eine Waschstrasse betreibst, interessiert Dich i.d.R. nur das Auto ansich (z.B. die Abmaße) und nicht, ob es sich um einen BMW, einen Audi oder VW handelt)
Allgemein gibt es verschiedene "Arten" von abstrakten Klassen (ohne Anspruch auf Vollständigkeit):
Adapter (z.B. MouseAdapter), sie implementieren ein oder mehrere Interfaces - ohne allerdings den Inhalt der Methoden zu definieren. Bei Verwendung solcher Adapter reicht es aus nur die Methoden zu überschreiben, die einen tatsächlich interessieren. Eine Implementierung der übrigen Methoden des Interfaces ist nicht notwendig.
abstrakte "Modelle" (z.B. AbstractTableModel), sie implementieren meist auch ein oder mehrere Interfaces. Hier werden einzelne Methoden bereits implementiert, andere für die spezifische Ausprägung der konkreten Klassen relevanten Methoden werden nur abstrakt oder garnicht definiert.
Eine abstrakte Klasse mit nur abstrakten Methoden sollte dann eher ein Interface sein.