Abstrakte Klassen - Notation

[mrkennedie89]

Hallo,

ich frage mich gerade, ob es bei der Notation im folgenden Beispiel Unterschiede gibt.
Angenommen es gibt eine abstrakte Klasse Car, und die erbende Klasse Audi.

public abstract class Car {

    private int horsePower;

    public abstract void drive();
}

public class Audi extends Car{

    @Override
    public void drive() {
        System.out.println("Fährt schnell");
    }
}

Theoretisch kann ich ja jetzt ein neues Objekt der Klasse Audi auf zwei verschiedenen Wegen erzeugen:

public static void main(String[] args) {

        Car car = new Audi();
        car.drive();

        Audi audi = new Audi();
        audi.drive();
    }

Gibt es hier irgendwelche Regeln für die Notation? Eigentlich kann man ja von einer abstrakten Klasse keine Objekte erzeugen. Was ich nicht verstehe ist, warum das Programm dann zulässt, dass Car car = new Audi() in Ordnung ist? Stiftet das nicht eher Verwirrung?

Danke.

 

[Raed]

Hallo,
klar es geht Car car = new Audi(); das hat wie ich weiß mit Architektur einer Applikation zu tun durch Interface bzw Abstract soll die Kopplung zwischen den Klassen verringert werden daher.
Grüße

Raed

 

[Mathom]

Hallo,

ich frage mich gerade, ob es bei der Notation im folgenden Beispiel Unterschiede gibt.
Angenommen es gibt eine abstrakte Klasse Car, und die erbende Klasse Audi.

public abstract class Car {

    private int horsePower;

    public abstract void drive();
}

public class Audi extends Car{

    @Override
    public void drive() {
        System.out.println("Fährt schnell");
    }
}

Theoretisch kann ich ja jetzt ein neues Objekt der Klasse Audi auf zwei verschiedenen Wegen erzeugen:

public static void main(String[] args) {

        Car car = new Audi();
        car.drive();

        Audi audi = new Audi();
        audi.drive();
    }

Gibt es hier irgendwelche Regeln für die Notation? Eigentlich kann man ja von einer abstrakten Klasse keine Objekte erzeugen. Was ich nicht verstehe ist, warum das Programm dann zulässt, dass Car car = new Audi() in Ordnung ist? Stiftet das nicht eher Verwirrung?

Danke.

Das ist Polymorphismus und gehört zu den Grundprinzipien der OOP (objektorientierten Programmierung).

Car car = new Audi();

-> Du hast zwar eine Referenzvariable "car", aber es bleibt weiterhin ein Audi-Objekt

Dieses Beispiel zeigt die Vorteile etwas genauer:

public class Audi extends Car {
    @Override
    public void drive() {
        System.out.println("Audi fährt schnell");
    }
}

public class BMW extends Car {
    @Override
    public void drive() {
        System.out.println("BMW fährt geschmeidig");
    }
}

public class Main {
    public static void main(String[] args) {
        Car audi = new Audi();
        Car bmw = new BMW();

        makeItDrive(audi);  // Ausgabe: "Audi fährt schnell"
        makeItDrive(bmw);   // Ausgabe: "BMW fährt geschmeidig"
    }

    public static void makeItDrive(Car car) {
        car.drive();
    }
}

 

[Jw456]

Du hast ja ein objekt von Audi erstellt.
Und in einer Variablen vom Typ Car.

 

[mrkennedie89]

Alles klar. Vielen Dank. Das mit dem Polymorphismus ist interessant und war mir vollkommen neu.

 

[KonradN]

Theoretisch kann ich ja jetzt ein neues Objekt der Klasse Audi auf zwei verschiedenen Wegen erzeugen:

Da nur einmal zur Verdeutlichung: Du erzeugst ein neues Objekt der Klasse Audi jedes mal auf die genau gleiche Weise:
Du erzeugst eine neue Instanz über new Audi()

Es ist also ganz wichtig zu verstehen, was der Code im Detail macht. Und da hast Du halt einmal, dass Du eine lokale Variable car vom Typ Car erzeugst und dieser dann eben die Referenz der neu erstellten Instanz zuweist. Und beim anderen hast Du eine lokale Variable audi vom Typ Audi, der Du die Referenz zuweist.

Die reine Erzeugung der Instanz ist aber identisch. Da hast Du keine Abweichungen. Um das zu verdeutlichen: Du kannst das z.B. auch in eine Methode verlagern und dann dort einfach die Methode aufrufen oder so.

Das nur zur Vervollständigung, da ich das Gefühl hatte, dass Du da den Code nicht gut genug aufgeteilt hast. Umgangssprachlich ist es leider so, dass man oft ungenau redet. Dann sagt man nur: "Ich erstelle eine neue Instanz von Audi" und man impliziert einiges mehr. "Ich bin zum Geldautomat gegangen und habe Geld abgehoben" - wenn ich das zu meiner Frau sage, dann erwartet diese zu Recht, dass ich das Geld dann auch eingesteckt habe.

Bei der Software Entwicklung sollte man aber durchaus genauer sein. Der Code Car car = new Audi(); ist eben nicht nur die Erzeugung einer neuen Audi Instanz sondern auch die Zuweisung der Referenz in die neue lokale Variable car. Das ist für das Verständnis sehr wichtig. Das umfasst auch einiges mehr. So ist wichtig: Es wird eine Referenz gespeichert - nicht die Instanz. Sollte klar sein, aber auch in der Sprache sollte man darauf achten.

 

[Beowend]

Hallo,
ich habe da auch so meinen "Hänger".
Wieso überhaupt sollte ich eine Instanz über eine lokale Variable der Superklasse (oder abstrakte Klasse, oder des Interfaces) definieren?
Birgt doch nur eine Einschränkung, so das das erstellte Objekt nicht auf die Methoden der Subklasse zugreifen kann. Wenn ich das Objekt über die Subklasse referenziere, so steht mir alles frei zur Verfügung (sofern nicht private in der Superklasse).
Welchen Vorteil bringt mir die Referenzierung über die Superklasse oder das Interface?

 

[KonradN]

Welchen Vorteil bringt mir die Referenzierung über die Superklasse oder das Interface?

Der Vorteil ist, dass Dein Code dann deutlich universeller ist. Anpassungen sind deutlich einfacher.

Schauen wir uns einfach einmal ein paar Beispiele an.

a) konkrete Instanz überall nutzen statt einem Interface / einer Superklasse
Stell Dir vor, Du hast diverse Methoden, die etwas mit Listen machen. Da Du immer java.util.ArrayList verwendest, hast Du das auch in den Methoden verwendet - statt eben dem Interface java.util.List. Das funktioniert natürlich erst einmal super.

a1: Nun hast Du aber aus irgend einem Grund eine andere Implementation von List. Du (oder jemand anderes) hast an irgend einer Stelle java.util.LinkedList verwendet. Oder Du willst die Mehode java.util.Array.asList(E... ) verwenden - etwas, das zwar eine ArrayList zurück gibt, aber eben kein java.util.ArrayList sondern java.util.Arrays$ArrayList. Die Methoden von Dir sind nicht verwendbar, wenn diese als Parameter ein java.util.ArrayList erwarten. Du schränkst also die Nutzbarkeit Deiner Methoden massiv ein - und das ohne jeden Grund (so du nur die Methoden von dem Interface verwendest).

a2: Nun stellst Du fest: Die Klasse ArrayList erfüllt nicht die Anforderungen, die Du an diese hast. Daher willst Du zukünftig eine andere List verwenden. Es reicht aber nun nicht, dass Du die Stelle anpasst, an der Du die Instanz erzeugst. Jetzt musst Du auch alle Stellen anpassen, bei denen Du es genutzt hast. Hier merkst Du also, dass es auch massive Konsequenzen hat, wenn Du Deinen Code nicht anderweitig verwenden können willst sondern nur für Dein Projekt nutzen willst.

b) Die Fragestellung ist auch weiter zu sehen. Du hast eine Vererbungshierarchie auch bei Interfaces. Nehmen wir uns nur einmal java.util.List:
Iterable -> Collection -> List

Die Argumente oben bei a1 gelten hier auch. Wenn Du in einer Methode bei einem Parameter nur Dinge verwendest, die Iterable oder Collection auch haben, dann macht es Sinn, bei den Argumenten den Typ entsprechend anzupassen. Wenn Du statt List den Typ Collection verwendest, dann kannst Du nicht nur beliebige List Implementationen übergeben sondern auch z.B. Sets. Deine Methode ist also deutlich besser verwendbar.

c) Bezüglich Interfaces ist evtl. auch noch wichtig: Versuche, Interfaces möglichst klein zu halten (wenn Du welche erstellst). Du hast also nicht ein großes, komplexes Interface sondern lieber mehrere. Also statt einem Interface:
Hund, der fressen(), bellen(), laufen(), schlafen(), .... kann erstellst du lieber mehrere Interfaces:
KannFressen, KannBellen, KannLaufen, KannSchlafen, ....

Damit bist Du dann deutlich universeller. Das Interface KannBellen kann auch eine Alarmanlage haben, die halt ein Hundegebell imitiert. fressen können auch Katzen, Pferde, ... Und schlafen() kann auch meine CPU (Sleep Modus)

Das ist nicht mehr ganz Deine Fragestellung, aber ich denke es ist so nah dran, dass ich es noch Sinn macht, diesen Punkt auch zu erwähnen.





Und das kann man dann auch etwas einordnen: Wie wichtig ist das denn?
Es ist aus meiner Sicht existenziell, dass man sich an sowas hält. Das ist auch durch SOLID Prinzipien (Prinzipien objektorientierten Designs – Wikipedia) abgedeckt, was ich als notwendige Basis für Clean Code betrachten würde.



Wie sieht denn dann die Praxis aus?
In der Praxis macht es Sinn, bei Klassen, die man verwenden will, auch immer die Interfaces anzusehen und kennen zu lernen. Dann kann man überlegen, was man überhaupt braucht um dann explizit das Interface zu nutzen um eben möglichst offen für zukünftige Verwendungen zu sein. (a1 / a2 aus dem Post!)
Wichtig ist aber: Daraus folgt nicht, dass man selbst massiv Interfaces erstellen muss. Das macht nur dann Sinn, wenn absehbar ist, dass es weitere Implementationen geben könnte. Und bei Methoden macht dies nur Sinn, wenn man meint, dass die Methode auch für andere Klassen verwendbar sein könnte.

Wichtig ist dabei, dass Interfaces immer vom Verbraucher angefordert werden, nicht von dem, der diese bereit stellt. Wenn ich den Hund implementiere, dann weiss ich nicht, was Andere brauchen. Dass fressen() und saufen() als Interface Fuetterbar notwendig sind, merke ich erst, wenn ich die FutterStation implementiere. Und dann ist klar: Die FutterStation kann universell verwendet werden und nicht nur für Hunde. => Der Bedarf für Fuetterbar ist aufgekommen.

Und das zeigt auch: Vieles entsteht während der Entwicklung. Man schreibt erst einmal Code und stellt dann im Laufe der Entwicklung fest: Ich habe da etwas geschrieben, das nicht optimal ist. Und dann passt man es an. Dann kann man nachträglich Interfaces einfügen und so.

(Bei der Entwicklung von Libraries ist dies natürlich erschwert. Da muss man beim Design der Library über mögliche Verwendungen nachdenken und das macht sowas deutlich schwerer. Aber unter dem Strich läuft es da auch nicht anders.)

==> Der erste Schritt ist aber auf jeden Fall, die Klassen zu kennen, die man nutzt. Und dazu gehören auch die Interfaces der Klassen. Und dann kann man das Vorhandene direkt nutzen.
==> Der Zweite Schritt sind dann erst einmal Refactorings. Da muss man aber langsam rein kommen. Hier ist meine Empfehlung: www.clean-code-developer.de - da wird man Schrittweise über mehrere Grade in diese Themen eingeführt.

 

[Beowend]

Der Vorteil ist, dass Dein Code dann deutlich universeller ist. Anpassungen sind deutlich einfacher.

Schauen wir uns einfach einmal ein paar Beispiele an.

a) konkrete Instanz überall nutzen statt einem Interface / einer Superklasse
Stell Dir vor, Du hast diverse Methoden, die etwas mit Listen machen. Da Du immer java.util.ArrayList verwendest, hast Du das auch in den Methoden verwendet - statt eben dem Interface java.util.List. Das funktioniert natürlich erst einmal super.

a1: Nun hast Du aber aus irgend einem Grund eine andere Implementation von List. Du (oder jemand anderes) hast an irgend einer Stelle java.util.LinkedList verwendet. Oder Du willst die Mehode java.util.Array.asList(E... ) verwenden - etwas, das zwar eine ArrayList zurück gibt, aber eben kein java.util.ArrayList sondern java.util.Arrays$ArrayList. Die Methoden von Dir sind nicht verwendbar, wenn diese als Parameter ein java.util.ArrayList erwarten. Du schränkst also die Nutzbarkeit Deiner Methoden massiv ein - und das ohne jeden Grund (so du nur die Methoden von dem Interface verwendest).

a2: Nun stellst Du fest: Die Klasse ArrayList erfüllt nicht die Anforderungen, die Du an diese hast. Daher willst Du zukünftig eine andere List verwenden. Es reicht aber nun nicht, dass Du die Stelle anpasst, an der Du die Instanz erzeugst. Jetzt musst Du auch alle Stellen anpassen, bei denen Du es genutzt hast. Hier merkst Du also, dass es auch massive Konsequenzen hat, wenn Du Deinen Code nicht anderweitig verwenden können willst sondern nur für Dein Projekt nutzen willst.

b) Die Fragestellung ist auch weiter zu sehen. Du hast eine Vererbungshierarchie auch bei Interfaces. Nehmen wir uns nur einmal java.util.List:
Iterable -> Collection -> List

Die Argumente oben bei a1 gelten hier auch. Wenn Du in einer Methode bei einem Parameter nur Dinge verwendest, die Iterable oder Collection auch haben, dann macht es Sinn, bei den Argumenten den Typ entsprechend anzupassen. Wenn Du statt List den Typ Collection verwendest, dann kannst Du nicht nur beliebige List Implementationen übergeben sondern auch z.B. Sets. Deine Methode ist also deutlich besser verwendbar.

c) Bezüglich Interfaces ist evtl. auch noch wichtig: Versuche, Interfaces möglichst klein zu halten (wenn Du welche erstellst). Du hast also nicht ein großes, komplexes Interface sondern lieber mehrere. Also statt einem Interface:
Hund, der fressen(), bellen(), laufen(), schlafen(), .... kann erstellst du lieber mehrere Interfaces:
KannFressen, KannBellen, KannLaufen, KannSchlafen, ....

Damit bist Du dann deutlich universeller. Das Interface KannBellen kann auch eine Alarmanlage haben, die halt ein Hundegebell imitiert. fressen können auch Katzen, Pferde, ... Und schlafen() kann auch meine CPU (Sleep Modus)

Das ist nicht mehr ganz Deine Fragestellung, aber ich denke es ist so nah dran, dass ich es noch Sinn macht, diesen Punkt auch zu erwähnen.

Ich denke, mir ist schon klar, welchen Vorteil Interfaces bieten, auch welchen Vorteil es bietet generell Methoden aus anderen Quellen zu "erben".
(Zentrale Wartbarkeit würde ich es nennen). Mir ging es auch nicht darum selbst, sondern warum ich die Instanzvariable darüber typisiere.
Dann kann die Instanz nur diejenigen Attribute und Methoden des Interfaces nutzen, nicht aber die der Klasse an sich. Mag es vllt für den augenblicklichen Moment auch ausreichen, lässt es mir ohne weitere Zwischenschritte nicht die Option später doch auf die Attribute und Methoden der Klasse über die Instanz zuzugreifen.

Änderungen beim Interface muss ich in jedem Fall auch bei der implementierenden Klasse durchführen, egal ob die Instanz über das Interface oder die Klasse an sich typisiert wurde.

Vielleicht stelle ich aus meiner Anfängersicht auch zu "dumme" Fragen. - Oder ich denke zu kompliziert!
clean-code-developer.de war ein sehr guter Tipp, danke dafür
Auch möchte ich mich speziell bei dir für die große Mühe, alles detailliert zu erklären danken, wie ich auch allen anderen Helfern danken möchte.
Für mich ist der Schritt (in meinem Alter ^^) gewaltig, mich in eine so großartige Welt, wie Java einzuleben.
Bin kein "stupider" C&P -Typ, muss immer auch verstehen, was wirklich passiert, daher arbeite ich gerne mit dem Debugger von IntelliJ schrittweise.
So kann ich genau nachverfolgen, wie das Programm abarbeitet.

 

[KonradN]

Mir ging es auch nicht darum selbst, sondern warum ich die Instanzvariable darüber typisiere.

Die Regel, die hier gerne aufgestellt wird, ist ja: Man entwickelt gegen Interfaces. Der Vorteil ist, dass Deine Klasse unabhängig von einer konkreten Implementation ist. Das mag zwar schnell eingeschränkt sein, denn man findet dann ja doch oft etwas wie:
private List<Whatever> myList = new ArrayList<>();
Sprich: Man hat dann doch noch die generelle Abhängigkeit hin zur ArrayList. Aber man hat genau eine Stelle, die angepasst wird. Und bei Bedarf kann man da auch jederzeit eingreifen, indem man z.B. über den Konstruktor übergibt, dies auslagert in eine Methode einer anderen Klasse. Oder es wird ein Framework genutzt, das sowas "injected". Es gibt hier also deutlich weitere Möglichkeiten und man ist erst einmal einen Schritt gegangen.

Aber ja, bei den Instanzvariablen (sowie bei lokalen Variablen) ist es weniger kritisch. Das sind Dinge, die rein intern sind (Ich hoffe, Du wirst nie die Kapselung brechen und dann plötzlich Instanzvariablen öffentlich machen!) und da ist es so, dass die Art und Weise, wie Du Dinge speicherst, leicht ändern kannst. Hier ist es also aus meiner Sicht weniger wild (um es mal so auszudrücken).

So hatten wir schon bei lokalen Variablen Diskussionen im Forum bezüglich dem "var", das man nutzen kann. Da wird die Variable ja auch von dem bestimmten Typ sein. Da war auch immer klar: das war eine Diskussion rein um Prinzipien und in der Praxis dürfte es egal sein. Problematisch könnte es bei zu großen Methoden sein. Aber da wäre das Kernproblem die Methode selbst und nicht das "var" oder das der Typ einer Variable dann statt List ArrayList ist oder so.

Daher: Wirklich wichtig ist es nur bei Schnittstellen. Also Parametern und was zurück kommt. Du nimmst Dir viele Möglichkeiten wenn Du da zu konkret wirst. (Wobei der Rückgabetyp konkret genug sein sollte!)

Änderungen beim Interface

Schnittstellen zu ändern ist immer sehr problematisch! Man kann ggf. Schnittstellen ergänzen. Dann kommt eine Methode dazu oder so. Aber alles andere sind "breaking changes". Wenn Du Parameter-Typen oder Rückgabe Typen änderst, dann funktioniert vorhandener Code, der darauf aufsetzt, evtl. nicht mehr. Bei Anwendungen mag das ok sein, dann muss man halt vieles mehr umstellen. Aber auch da kann es schnell zu sehr viel Aufwand werden. Und bei öffentlichen Schnittstellen ist es ein No Go. Im Netz findet man daher oft mehrere Schnittstellen bei den APIs. Dann hat man ein /v1, /v2, .... und man unterstützt dann zur Not längere Zeit mehrere Versionen bis alle umgestellt haben.

Dann kann die Instanz nur diejenigen Attribute und Methoden des Interfaces nutzen, nicht aber die der Klasse an sich. Mag es vllt für den augenblicklichen Moment auch ausreichen, lässt es mir ohne weitere Zwischenschritte nicht die Option später doch auf die Attribute und Methoden der Klasse über die Instanz zuzugreifen.

Hier ist wichtig: Du hast eine Methode, die klein sein sollte, die genau eine Sache macht. Und dafür brauchst Du nur gewisse Dinge. Und natürlich bekommst du dann genau das, was Du brauchst. Wenn Du nur ein Collection<T> brauchst, dann reicht das. Die Methode wird ja nicht plötzlich etwas anderes machen müssen. So Anpassungen sind also eher seltener. (Heisst nicht, dass sowas nicht vorkommen kann, aber das ist eher unwahrscheinlich).

Vielleicht stelle ich aus meiner Anfängersicht auch zu "dumme" Fragen. - Oder ich denke zu kompliziert!

Die Fragen sind alles andere als dumm. Und Du bist mit den Fragen immer herzlich willkommen. Clean Code ist oft auch keine schwarz/weiss Sicht. Du kannst vieles machen. Dann heisst es ggf: "Ich hätte es anders gemacht", aber das bedeutet nicht, dass es bei einem Code Review abgelehnt würde. Und vor allem: Wer bin ich, dass mir Dein Code gefallen muss?

Aus meiner Sicht ist es wichtig, dass man sich damit etwas beschäftigt. Und an vielen Stellen braucht man da auch relativ wenig drüber nachdenken. In vielen Applikationen wirst Du am Anfang kaum eigene Interfaces haben. Das ist auch ok so! Evtl. hast Du ein paar Klassen, die voneinander ableiten, aber selbst das muss nicht zwingend sein. Und dann baust Du nach und nach Software und wirst immer wieder über diverse Dinge nachdenken. Und dann probierst Du Dinge einfach aus. Dann kannst Du selbst schauen, ob gewisse Dinge Sinn machen oder nicht.

Das Thema jetzt ist in meinen Augen weniger wichtig wie z.B. automatische Tests, gute Bezeichner, kurze Methoden, ....

Und was ist das Problem, wenn Du in einer Methode als Parameter ArrayList statt List hast? Dann läuft erst einmal alles. Und wenn Du dann irgendwann plötzlich mal keine ArrayList hast, dann geht es nicht. Dann kommt der Punkt, wo Du es von ArrayList zu List ändern wirst. (Mir fällt gerade nichts ein, was ArrayList groß an wichtigen Dingen hat, die List nicht hat, was relevant sein könnte.)

Das Problem, was hier eher mal auftreten kann: Du nutzt Collections für eine Verwaltung, die eigentlich eine eigenständige Klasse sein sollte. Sprich: Wenn Du einen Einkaufszettel hast, dann sollte das ggf. eine eigene Klasse sein und nicht nur eine List<EInkaufswunsch>. Klar kann es auch List<Einkaufswunsch> geben z.B. als Ergebnis der Methode: Gib mir alles, was ich bei ALDI kriege. Aber die eigene Klasse wird wichtig, wenn da Logik rein kommt. Spezielle Filterungen oder Sortierungen. Oder spezielle Aktionen: add(Klopapier) fügt das nur dazu, wenn es noch nicht auf der Liste ist (Ansonsten sieht jeder im Haushalt, dass das Klopapier alle ist und schon kauft man 10 Packungen. Evtl. wollten die Leute bei Covid nichts bunkern - die hatten nur eine fehlerhafte App )

Daher ist das Thema schlicht ein sehr theoretisches und Du musst schauen, wie Du es mit Leben füllen kannst. Da sind dann ggf. auch weitere Bücher sinnvoll. Entwurfsmuster von Kopf bis Fuß ist ein interessantes Buch, das etwas in diese Richtung geht und diverse Pattern als Handwerksmaterial an die Hand gibt, um Dir zu zeigen, wie etwas gehen könnte.