extrends vs. import

[OliW]

Hallo und allen schöne Feiertage,

ich habe eine Frage zu im Betreff genannten Keywords. Die Funktionsweisen und grundsätzlichen Unterschiede sind mit klar.
Die Unterschiede allerdings noch nicht so sehr.
Kann ich die Funktionalität einer Kindklasse ebenso aufrecht erhalten, wenn ich die Vererbung zur Vaterklasse aufhebe und die Vaterklasse stattdessen per import (import klasse.Vaterklasse) zur Vergügung stelle.
Wo genau liegt der Unterschied?
Ich habe das zwar in Eclipse ausprobiert, allerdings verwirren mich die Fehlermeldungen doch ziemlich.
v.D.

Gruß Oli

 

[kneitzel]

Ich bin mir gerade nicht sicher, ob ich Dich richtig verstanden habe. Ein Import macht ja eigentlich nichts, es verändert an der Funktionalität nichts.

Extends verändert aber die Funktionalität der Klasse.

Und nein, man kann das extends nicht anders abbilden. Spätestens etwas wie
Parent instanz = new Child();
Ist unmöglich.

 

[Blender3D]

das heißt extends und nicht extrends.
extends ist für die Vererbung. Man kann damit bestehende Klassen erweitern.
Import hat mit Vererbung nichts zu tun. Damit kann man Pakete oder Klassen importieren (zuladen).

 

[OliW]

das heißt extends und nicht extrends.
extends ist für die Vererbung. Man kann damit bestehende Klassen erweitern.
Import hat mit Vererbung nichts zu tun. Damit kann man Pakete oder Klassen importieren (zuladen).

vielen Dank. Extrends war ein Tippfehler, .

 

[OliW]

Ich bin mir gerade nicht sicher, ob ich Dich richtig verstanden habe. Ein Import macht ja eigentlich nichts, es verändert an der Funktionalität nichts.

Extends verändert aber die Funktionalität der Klasse.

Und nein, man kann das extends nicht anders abbilden. Spätestens etwas wie
Parent instanz = new Child();
Ist unmöglich.

v.D. Stimmt << Parent instanz = new Child();>> ist ein gutes Argument. Mir leuchtet nur noch nicht ein wann man die Vererbung und wann den Import wählt. Denn ob ich nun << Parent instanz = new Child();>> oder gleich <<Child instance = new Child();>> verwende, spielt doch keine Rolle, oder? Wenn ich auf Methoden oder Variablen aus der Parentklasse zugreifen möchte würde ich einen Import machen und über << Parent.methodenname();>> oder <<Partent.variablenname; >> zugreifen.

Aber ich denke, ich habe hierfür einfach zu wenig Praxis. Das Grundprinzip habe ich verstanden und die tiefe Verständniss kommt wohl mit der Praxis.

 

[White_Fox]

Extends wurde ja schon erklärt.
Import macht nichts anderes als z.B. include in C: Damit verweist du auf Klassen/Interfaces, die z.B. in einer Bibliothek definiert wurden.
Ansonsten würde z.B. eine Zeile wie GodClass instance = new GodClass(); sofort zu einem Fehler führen, weil der Compiler nicht weiß was GodClass sein soll. Der Import-Befehl sagt dem Compiler, wo er die notwendigen Informationen findet.

 

[White_Fox]

Denn ob ich nun << Parent instanz = new Child();>> oder gleich <<Child instance = new Child();>> verwende, spielt doch keine Rolle, oder?

Doch...das kann, je nach Anwendungsfall, sogar eine sehr große Rolle spielen. Ein Child ist immer auch sein Parent, aber ein Parent niemals ein Child.
Beispiel: Du hast eine Klasse Panzer, eine Klasse PKW und eine Klasse Lastkraftwagen. Alle diese Klassen sind Kinder der Parentklasse Landfahrzeuge. Ein Panzer ist immer auch ein Landfahrzeug. Aber ein Landfahrzeug muß nicht unbedingt ein Panzer sein.

Aber mit Import hat das gar nichts zu tun.

 

[OliW]

Doch...das kann, je nach Anwendungsfall, sogar eine sehr große Rolle spielen. Ein Child ist immer auch sein Parent, aber ein Parent niemals ein Child.
Beispiel: Du hast eine Klasse Panzer, eine Klasse PKW und eine Klasse Lastkraftwagen. Alle diese Klassen sind Kinder der Parentklasse Landfahrzeuge. Ein Panzer ist immer auch ein Landfahrzeug. Aber ein Landfahrzeug muß nicht unbedingt ein Panzer sein.

Aber mit Import hat das gar nichts zu tun.

Das leuchtet auch völlig ein. Aber ich hänge gedanklich an folgendem Punkt. Was spricht dagegen, wenn ich einen Panzer möchte, eine Klasse hierfür mit den für den Panzer spezifischen Attributen und Methoden zu erstellen und mir die Attribute und Methoden für die Landfahrzeuge (wozu der Panzer ja gehört) über den Import der Klasse Landfahreuge zu holen. Damit hätte ich doch auch das Poblem mit dem Konstruktor umgangen, der ja nicht mitvererbt wird.
So richtige Sinn macht die Vererbung mit meinem bisherigen Wissen doch erst bei Vererbungsketten. Also z.b.
Landfahrzeuge >> Panzer >> Leopard. Obwohl ich bei Leopard doch auch Landfahrzeuge und Panzer importieren könnte.

 

[White_Fox]

Nein. Mit dem Import-Befehl machst du dem Compiler klar, wo er die Klasse Landfahrzeuge findet. Das ist nützlich, wenn du die Klasse Landfahrzeuge verwendest.

Der Compiler weiß damit aber nicht, daß du von der Klasse Landfahrzeuge erben willst. Genau das aber macht das extends. Übersetze dir die Befehle doch mal ins Deutsche. Beide haben völlig andere Bedeutungen.

 

[mrBrown]

Das leuchtet auch völlig ein. Aber ich hänge gedanklich an folgendem Punkt. Was spricht dagegen, wenn ich einen Panzer möchte, eine Klasse hierfür mit den für den Panzer spezifischen Attributen und Methoden zu erstellen und mir die Attribute und Methoden für die Landfahrzeuge (wozu der Panzer ja gehört) über den Import der Klasse Landfahreuge zu holen. Damit hätte ich doch auch das Poblem mit dem Konstruktor umgangen, der ja nicht mitvererbt wird.

Und jetzt baust du den TÜV ein, deine eine Hauptuntersuchung bei Landfahrzeugen durchführen kann hauptuntersuchung(Landfahrzeugen fahrzeug) {...}

Wenn dein Panzer Landfahrzeugen erweitert, kannst du der Methode auch Panzer übergeben. Wenn Panzer aber kein Landfahrzeug ist, sondern nur eins nutzt, kannst du keinen Panzer übergeben.

(Dies hier ist aber einen Blick für dich wert: https://de.wikipedia.org/wiki/Komposition_an_Stelle_von_Vererbung)

(Und btw: du solltest dicht nicht so sehr auf das Import-Statement konzentrieren, das gibt nur an, wo der Compiler nach benutzen Klassen sucht, wenn man keine fully qualified names angibt. Nach dem kompilieren ist von dem Import allerdings nichts mehr zu merken)

 

[kneitzel]

Es wurde schon einiges gesagt, aber ich frage mich gerade, ob es evtl. bei Dir etwas um die Thematik inheritance vs. composition geht.

Inheritance bedeutet, dass eine Klasse von einer anderen erbt. D.h. man bekommt eine speziellere Version vom Original. Beispiele kann man sich schnell überlegen. man hat Lebewesen. Davon leitet sich Säugetier ab. Davon dann evtl. Mensch.

Die ganze Idee dabei ist, dass man z. B. mit Lebewesen agieren kann, ohne die genaue Spezifizierung zu kennen.

Aber Composition bedeutet etwas anderes. Da gehört etwas zu einer Klasse.
Ein Beispiel ist hier auch schnell gefunden: ein Flugzeug hat z.B. einen Höhenmesser.

Umgangssprachlich kann man hier einige Formulierungen finden, die typisch sind.
Bei einer extends oder implements Beziehung wäre das in der Umgangssprache eine ‚Ist ein‘ Beziehung:
Mensch ist ein Säugetier.
Säugetier ist ein Lebewesen.

Bei der Composition wäre das eine ‚hat ein‘ Beziehung. Flugzeug hat ein Höhenmesser.

Wenn man selbst etwas baut, dann ist es aber oft nicht eindeutig. In Foren findet sich das z.B. bei Spring Oberflächen:
Implementiere ich ein Fenster, das ein JFrame ist?
Oder habe ich ein Teil der Applikation, das ein JFrame hat?
Hier muss man dann für sich Reglungen finden. Es gibt oft kein wirkliches Richtig oder Falsch.

Aber Fakt ist: Das Imports bedeutet aus Java Virtual Machine nichts. Das soll nur dem Entwickler helfen. Wozu immer Klassen mit vollem Paketnamen nennen? Entwickler sind faul und wollen übersichtlichen Code. Also will ein Entwickler nicht ständig my.cool.packages.MyClass schreiben. Also kommt da einmal oben am Anfang ein Import dafür und dann nutzt man nur noch MyClass. Also für den Code bedeutet das nichts, nur für die Schreibweise.

 

[mihe7]

Entwickler sind faul

Ts, ts, ts... man soll nicht von sich auf andere schließen

Spoiler

Ich geb Dir aber Recht

 

[Meniskusschaden]

Entwickler sind faul

Ts, ts, ts... man soll nicht von sich auf andere schließen

Gehört eben zu den Haupttugenden eines guten Programmierers.

 

[White_Fox]

Gut daß du das schreibst, ich wollte schon präzisieren: Gute Entwickler sind faul.

 

[OliW]

Die ganze Idee dabei ist, dass man z. B. mit Lebewesen agieren kann, ohne die genaue Spezifizierung zu kennen.

Aber Composition bedeutet etwas anderes. Da gehört etwas zu einer Klasse.
Ein Beispiel ist hier auch schnell gefunden: ein Flugzeug hat z.B. einen Höhenmesser.

Umgangssprachlich kann man hier einige Formulierungen finden, die typisch sind.
Bei einer extends oder implements Beziehung wäre das in der Umgangssprache eine ‚Ist ein‘ Beziehung:
Mensch ist ein Säugetier.
Säugetier ist ein Lebewesen.

Bei der Composition wäre das eine ‚hat ein‘ Beziehung. Flugzeug hat ein Höhenmesser.

Danke. Jetzt ist ein Groschen gefallen um die " Denkblockade" zu lösen. Das mit dem "Ist ein" und "hat ein" ist gut. Und auch Deine Aussage, daß es beim "selber Bauen" nicht immer so klar und eindeutig ist, bestätigt meine eigene Annahme.

Vielen Dank für eure Antworten.