Verständnisfrage: Objekt erzeugen u. zuweisen

[MikeTheBike]

Hallo,
ich bin Java-Anfänger und kapiere eine Sache nicht, die auch nirgends richtig erklärt wird. Also, die typische Deklaration und Erzeugung eines Objekts:

Pferd fury = new Pferd();

Was mir nicht in den Kopf will, ist, dass man zweimal den Namen der Klasse angeben muss. Das kommt mir wie doppelte, redundante Information vor, und das kann doch nicht sein. Gut, ich weiss, dass das eigentlich zwei Schritte auf einmal sind, erstens Deklaration der Variablen fury:

Pferd fury;

und zweitens die Erzeugung des Objekts und Zuweisung zur Variablen fury:

fury = new Pferd();

Aber wenn die Variable sowieso nur einen Verweis auf den Speicherplatz des Objektes enthält (also nichts als eine Speicheradresse) und nie das Objekt (bzw. dessen Daten und Methoden) selber, wozu muss der Compiler/Interpreter dann wissen, von welchem Typ die Variable sein muss, also von welcher Klasse ihr später ein Objekt zugewiesen werden wird? Wozu muss ich das bei Deklaration der Variablen angeben? Es würde doch reichen, wenn es einen Universaltyp gäbe, der für alle Variablen gelten würde, die ein Objekt zugewiesen bekommen. Beispielsweise ein Typ "Object" oder "Instance" oder wie auch immer. Dieser Typ Variablen müsste doch nur imstande sein, eine Speicheradresse für die jeweiligen Objekte aufzunehmen. Ich meine, warum haben die Erfinder von Java das nicht so gemacht?


Irgendjemand wird jetzt sagen, Pferd() ist ja nicht die Klasse, sondern der Konstruktor, also ich muss einmal die Klasse angeben und einmal den Konstruktor, nicht zweimal dieselbe Information. Aber das ist spitzfindig, weil der Konstruktor sowieso immer so heisst wie die Klasse. Man hätte Java ja auch so konstruieren können, dass man die zwei Klammern weglassen kann. Letztlich muss ich zweimal den Klassennamen angeben.




Und dann gleich noch eine Frage in diesem Zusammenhang:
Jemand hat mir erzählt, es wäre auch folgendes möglich:

AbstractTier fury = new Pferd();

wobei ich nur Zugriff auf die Methoden der abstrakten Klasse AbstractTier hätte, nicht auf die von Pferd. Ist das richtig, und wenn ja, was soll so was? Ich dachte, man definiert Klassen gerade dann als abstrakt, wenn ich keine Objekte davon zulassen will!?

Gibt es einen speziellen Namen für so eine Anweisung?

Danke für die kommenden hilfreichen Antworten.

 

[Gast2]

Alsoooo

Aber wenn die Variable sowieso nur einen Verweis auf den Speicherplatz des Objektes enthält (also nichts als eine Speicheradresse) und nie das Objekt (bzw. dessen Daten und Methoden) selber, wozu muss der Compiler/Interpreter dann wissen, von welchem Typ die Variable sein muss, also von welcher Klasse ihr später ein Objekt zugewiesen werden wird? Wozu muss ich das bei Deklaration der Variablen angeben?

Es gibt eine Unterschied zwischen
- dem Typ der Variablen
- und dem Typ des Objektes
Der Typ der Variablen gibt an welche "Sicht" du auf das Objekt hast, der Typ des Objekts gibt an welche Instanz sich letztendlich dahinter befindet.

würde doch reichen, wenn es einen Universaltyp gäbe, der für alle Variablen gelten würde, die ein Objekt zugewiesen bekommen. Beispielsweise ein Typ "Object" oder "Instance" oder wie auch immer. Dieser Typ Variablen müsste doch nur imstande sein, eine Speicheradresse für die jeweiligen Objekte aufzunehmen. Ich meine, warum haben die Erfinder von Java das nicht so gemacht?

Es gibt tatsächlich eine Klasse Object (die Mutter aller Klassen). Von der Klasse erben (direkt oder indirekt) alle anderen Klassen.
Es reicht aber nicht aus wenn jede Variable einfach den Typ Object hätte, da du nur die Methoden von Object aufrufen könntest, das bringt dir in der Regel nichts.

Irgendjemand wird jetzt sagen, Pferd() ist ja nicht die Klasse, sondern der Konstruktor, also ich muss einmal die Klasse angeben und einmal den Konstruktor, nicht zweimal dieselbe Information. Aber das ist spitzfindig, weil der Konstruktor sowieso immer so heisst wie die Klasse. Man hätte Java ja auch so konstruieren können, dass man die zwei Klammern weglassen kann. Letztlich muss ich zweimal den Klassennamen angeben.

Siehe die Erklärungen oben, bzw. Beispiel unten, du musst nicht immer zweimal den Klassennamen angeben, sonst wäre es tatsächlich redundant

AbstractTier fury = new Pferd();

Das bedeutet dass du eine Variable vom Typ AbstractTier anlegst, der ein Objekt vom Typ Pferd zugewiesen wird. Du kannst auf fury dann alle Methoden der Klasse AbstractTier aufrufen.

Das ganze wird vllt etwas klarer im folgenden Beispiel:

public void sayNumberOfLegs(AbstractTier tier) {
    System.out.println("Ich habe " + tier.getNumberOfLegs() + " Beine");
}

Der Methode kannst du eine beliebige Instanz übergeben die entweder ein AbstractTier ist oder von AbtractTier erbt.
Hast du Beispielweise eine Klasse Pferd, würde die Methode eine 4 zurückgeben. Dann hast du vllt noch eine Klasse Vogel, die gibt dann 2 zurück.
Hm... vllt nicht das schönste Beispiel aber naja...

Achso, das ganze ist auch in einem Javabuch deiner Wahl nachzulesen :rtfm:

 

[TheDarkRose]

Stichwort Typisierung: Galileo Computing :: Java ist auch eine Insel – 2.3 Datentypen, Typisierung, Variablen und Zuweisungen
Stichwort Vererbung: Galileo Computing :: Java ist auch eine Insel – 5.8 Vererbung
Stichwort Dynamische Bindung: Galileo Computing :: Java ist auch eine Insel – 5.11 Dynamisches Binden

 

[Marco13]

Ganz allgemein: Es gibt verschiedene Typisierungen ( siehe Typisierung (Informatik) ? Wikipedia - nur zur Info, vielleicht nicht direkt hilfreich), und Java ist eben eine typisierte Sprache, bei der es diesen "Universaltyp" nicht gibt. Konkrete Gründe kann ich dafür nicht nennen, aber zu allgemeinen Vor- und Nachteilen findet man sicher einiges....

rgendjemand wird jetzt sagen, Pferd() ist ja nicht die Klasse, sondern der Konstruktor, also ich muss einmal die Klasse angeben und einmal den Konstruktor, nicht zweimal dieselbe Information. Aber das ist spitzfindig, weil der Konstruktor sowieso immer so heisst wie die Klasse.

Das ist nicht spitzfindig. Oder vielleicht doch. Aber wenn, dann ist es eben so: Manchmal MUSS man spitzfindig sein, und das ist so gesehen nur ein Artefakt des Bemühens um eine präzise Ausdrucksweise. Das andere Extrem wäre "schwammiges wischi-waschi-Gelaber", und das will ja auch keiner Ganz konkret bezieht sich das, was du hier als spitzfindig bezeichnest, ja auch das letzte Beispiel - was ich spontan auch als Einwand zu deiner anfänglichen Kritik gebracht hätte:

AbstractTier fury = new Pferd();

Dort ist ja so, dass eben NICHT zweimal das gleiche dasteht. Der Fall, DASS zweimal das gleiche dasteht, wie bei [c]Pfert pferd=new Pferd();[/c] ist so gesehen nur ein "Spezialfall".

Üblicherweise versucht man, den Typen der Deklaration so allgemein wie möglich zu halten. Es stimmt schon: Dort, wo man das Objekt erstellt (also den Konstruktor mit 'new' aufruft) ist es fast egal, weil man dort den konkreten Typ (hier 'Pferd') ja sowieso kennt. Aber spätestens, wenn die Deklaration und die Erstellung an unterschiedlichen Stellen stehen, werden die Vorteile deutlich. Der wichtigste ist die Weiderverwendbarkeit. Darüber hinaus beschreibt der Typ in der Deklaration, was das, womit man es dort zu tun hat, in seiner allgemeinsten Form wirklich IST. Etwas plakativ an dein Beispiel angepasst:

class Tierpfleger
{
    private AbstractTier tier;
    public void pflege(AbstractTier tier)
    {
        this.tier = tier;
        füttereTier();
    }
    private void füttereTier()
    {
        tier.friß(new Futter());
    }
}

So eine Klasse könnte man verwenden, um beliebige Tiere pflegen zu lassen. Die Objekte, die dort verwendet werden, brauchen nur die methode "friß(futter)", die wohl in AbstractTier stehen könnte. Wenn dort statt "AbstractTier" überall "Pferd" stehen würde, dann könnte man damit nur Pferde pflegen. So hat man aber die Möglichkeit, auch andere Tiere dort zu übergeben:

AbstractTier tier = null;
//tier = new Pferd(); // Kann man 
//tier = new Hund(); // sich 
tier = new Katze(); // aussuchen...
tierpfleger.pflege(tier);

(Üblicherweise verwendet man in solchen Fällen keine Abstrakte Klasse, sondern nur ein Interface - aber das könnte man un-spitzfindig vereinfacht als vollkommen abstrakte Klasse ansehen )

 

[faetzminator]

...oder auf die Java SE API angewandt:
Man sollte bei Collections immer die Interfaces verwenden, also:

Map<String, Integer> map = new HashMap<String, Integer>();
List<Gaul> list = new ArrayList<Gaul>();

 

[Michael...]

Aber wenn die Variable sowieso nur einen Verweis auf den Speicherplatz des Objektes enthält (also nichts als eine Speicheradresse) und nie das Objekt (bzw. dessen Daten und Methoden) selber, wozu muss der Compiler/Interpreter dann wissen, von welchem Typ die Variable sein muss, also von welcher Klasse ihr später ein Objekt zugewiesen werden wird? Wozu muss ich das bei Deklaration der Variablen angeben?

Sicherlich gibt es verschiedene Meinung zur Typisierung von Variablen. Aber für mich ein sehr gewichtiger Punkt ist ein stark reduziertes Risiko des Auftretens von Laufzeitfehlern.
Ein ganz charmanter Nebeneffekt ist die Autovervollständigung moderner IDEs und die Fehlererkennung und Korrekturvorschläge noch bevor kompiliert wurde.

Abgesehen ist, im Vergleich zu anderen Sprachen die Deklaration in Java doch recht schlicht und kaum mit Mehraufwand verbunden:

int test;

vs

Dim test As Integer

 

[xehpuk]

Ergänzend zu den bisherigen Antworten:

Bei der Zuweisung muss nicht direkt ein Konstruktor aufgerufen werden. Es kann etwa auch eine Methode sein, die den passenden Typ zurückgibt.

public class AnsweringService {
	public static void main(String[] args) {
		Number answer = giveAnswer();
		int rawAnswer = answer.intValue();
		System.out.println(rawAnswer);
	}

	public static Number giveAnswer() {
		return Integer.valueOf(42);
	}
}

 

[MikeTheBike]

Es gibt eine Unterschied zwischen
- dem Typ der Variablen
- und dem Typ des Objektes
Der Typ der Variablen gibt an welche "Sicht" du auf das Objekt hast, der Typ des Objekts gibt an welche Instanz sich letztendlich dahinter befindet.

Ich denke, das ist die Antwort auf meine Frage. In der Variable ist nicht nur eine Speicheradresse gespeichert, sondern auch diese "Sicht" auf das Objekt, d.h. auf welche Methoden ich Zugriff habe. DAS gebe ich durch die Nennung des Klassennamens an. Ich hatte zwar gelesen, dass das bei einer Klasse als Datentyp im Prinzip genauso der Fall ist, wie bei einem primitiven Datentyp (wo z.B. bei int auch nur bestimmte Operationen erlaubt sind, z.B. Addition, Multiplikation), aber in diesem Zusammenhang nicht mehr daran gedacht.

Es gibt tatsächlich eine Klasse Object (die Mutter aller Klassen). Von der Klasse erben (direkt oder indirekt) alle anderen Klassen.

Ich hab da einen Fehler gemacht. Wenn es so wäre, wie ich gedacht hatte, dass nämlich die Variable nur die Referenz ist, sonst gar nix, dann hätte der Universaltyp dafür vielleicht "Reference" oder "Adress" heissen können, nicht "Object".

AbstractTier fury = new Pferd();

Das bedeutet dass du eine Variable vom Typ AbstractTier anlegst, der ein Objekt vom Typ Pferd zugewiesen wird. Du kannst auf fury dann alle Methoden der Klasse AbstractTier aufrufen.

Und nur die, nicht die von Pferd, richtig?

Das ganze wird vllt etwas klarer im folgenden Beispiel:

public void sayNumberOfLegs(AbstractTier tier) {
    System.out.println("Ich habe " + tier.getNumberOfLegs() + " Beine");
}

Der Methode kannst du eine beliebige Instanz übergeben die entweder ein AbstractTier ist oder von AbtractTier erbt.
Hast du Beispielweise eine Klasse Pferd, würde die Methode eine 4 zurückgeben. Dann hast du vllt noch eine Klasse Vogel, die gibt dann 2 zurück.
Hm... vllt nicht das schönste Beispiel aber naja...

Nicht unoriginell, das Beispiel.

Achso, das ganze ist auch in einem Javabuch deiner Wahl nachzulesen :rtfm:

Leider nicht, jedenfalls nicht im Anfangsteil, wo ich noch bin. So ein Beispiel wie meins gibt's da nicht.
Deklaration und Objekterzeugung sind da einzeln erklärt und auch noch, dass man das in einem Schritt machen kann, aber immer mit derselben Klasse und ohne Begründung, warum diese doppelte Information.
So richtig hab ich's auch noch nicht verstanden, warum man so was braucht wie im Beispiel mit Tier und Pferd. Ich meine, zuerst definiere ich die Klasse Tier als abstrakt, und dann lege ich ein Objekt Pferd an, dem ich dann aber doch wieder die Methoden von Tier gebe, und nicht die (zusätzlichen) von Pferd. Warum kann ich dann nicht gleich Tier konkret machen, also Objekte davon? Kommt mir wie eine Umgehungsmaßnahme vor. Aber vielleicht kommt das Verständnis noch mit der Zeit und Fortschritten in der Lektüre. Ganz schön kompliziert jedenfalls, finde ich.

Danke an alle für die Antworten.

 

[MikeTheBike]

Üblicherweise versucht man, den Typen der Deklaration so allgemein wie möglich zu halten.

Was heisst das?

... werden die Vorteile deutlich. Der wichtigste ist die Weiderverwendbarkeit.

Meinst du mit Wiederverwendbarkeit eben diese Möglichkeit, dass man nicht nur das Pferd, sondern auch Katzen, Hunde und Leguane damit bearbeiten kann?

Darüber hinaus beschreibt der Typ in der Deklaration, was das, womit man es dort zu tun hat, in seiner allgemeinsten Form wirklich IST. Etwas plakativ an dein Beispiel angepasst:

class Tierpfleger
{
    private AbstractTier tier;
    public void pflege(AbstractTier tier)
    {
        this.tier = tier;
        füttereTier();
    }
    private void füttereTier()
    {
        tier.friß(new Futter());
    }
}

So eine Klasse könnte man verwenden, um beliebige Tiere pflegen zu lassen. Die Objekte, die dort verwendet werden, brauchen nur die methode "friß(futter)", die wohl in AbstractTier stehen könnte. Wenn dort statt "AbstractTier" überall "Pferd" stehen würde, dann könnte man damit nur Pferde pflegen. So hat man aber die Möglichkeit, auch andere Tiere dort zu übergeben:

AbstractTier tier = null;
//tier = new Pferd(); // Kann man 
//tier = new Hund(); // sich 
tier = new Katze(); // aussuchen...
tierpfleger.pflege(tier);

)

Aber all die Hunde, Katzen und Pferde müssen doch sowieso Erben von Tier sein, sonst würde

AbstractTier fury = new Pferd();

gar nicht gehen, der Compiler würde meckern, oder? Also würden sie doch auch die Methoden von Tier erben.
Bei

AbstractTier fury = new Pferd();

kann fury weniger als bei

Pferd fury = new Pferd();

- oder?

 

[faetzminator]

Meinst du mit Wiederverwendbarkeit eben diese Möglichkeit, dass man nicht nur das Pferd, sondern auch Katzen, Hunde und Leguane damit bearbeiten kann?

Ja. Z.B. wird in deiner Bankingsoftware ein Kontoübertrag gleich prozessiert wie eine SWIFT-Buchung. Dahinter machen sie aber unterschiedliche sachen.

Aber all die Hunde, Katzen und Pferde müssen doch sowieso Erben von Tier sein, sonst würde

AbstractTier fury = new Pferd();

gar nicht gehen, der Compiler würde meckern, oder? Also würden sie doch auch die Methoden von Tier erben.

Korrekt^2.

Bei

AbstractTier fury = new Pferd();

kann fury weniger als bei

Pferd fury = new Pferd();

- oder?

Naja, es kennt halt nur die Methoden bis und mit [c]AbstractTier[/c]. Aber das ist irrelevant, da nun sowieso wieder allgemeiner Code (von [c]AbstractTier[/c]) aufgerufen werden sollte. Und [c]Pferd[/c] sollte im Normalfall auch keine weiteren öffentlichen Methoden deklarieren als von [c]AbstractTier[/c] vorgegeben.

 

[Marco13]

Was heisst das?
...
Meinst du mit Wiederverwendbarkeit eben diese Möglichkeit, dass man nicht nur das Pferd, sondern auch Katzen, Hunde und Leguane damit bearbeiten kann?

Genau. Dieser Grundgedanke, immer "das allgemeinste" zu verwenden, bezieht sich oft auf Interfaces, und wird auch als "Gegen das Interface programmieren" bezeichnet. Noch ein Beispiel: Man könnte sich eine Methode machen wie

// Gibt die Strings der ArrayList zeilenweise aus
void print(ArrayList<String> list) {
    for (String s : list) System.out.println(s);
}

Die könnte man dann wie zu erwarten verwenden:

ArrayList<String> list = new ArrayList<String>();
list.add("Hallo");
list.add("Welt");
print(list);

Aber wenn man z.B. keine ArrayList hat, sondern eine LinkedList, würde die Methode nicht funktionieren:

LinkedList<String> list = new LinkedList<String>();
list.add("Hallo");
list.add("Welt");
print(list); // Fehler: Die Methode erwartet eine ArrayList, und keine LinkedList

Man könnte die Methode aber allgemeiner schreiben, so dass sie für JEDE 'List' funktioniert:

// Gibt die Strings der List zeilenweise aus
void print(List<String> list) { // List statt ArrayList
    for (String s : list) System.out.println(s);
}

Damit kann man sie für ArrayList, LinkedList, Vector und jede andere List anwenden.

Aber sowas würde nicht gehen:

Set<String> set = new HashSet<String>();
set.add("Hallo");
set.add("Welt");
print(set); // Fehler: Die Methode erwartet eine List, und kein Set

Deswegen könnte man die Methode NOCH allgemeiner schreiben, indem man ein Interface verwendet, das in der Vererbungshierarchie noch weiter oben liegt - nämlich 'Collection':

// Gibt die Strings der Collection zeilenweise aus
void print(Collection<String> collection) { // Collection statt List
    for (String s : collection) System.out.println(s);
}

Damit kann man sie für ArrayList, LinkedList, Vector, HashSet, TreeSet und jede andere Collection anwenden.

Man könnte NOCH weiter gehen, und das ganze auf das Interface 'Iterable' zurückführen, und auch den Typparameter 'String' durch einen beliebigen Typ ersetzen:

// Gibt die Elemente zeilenweise aus
<T> void print(Iterable<T> iterable) { 
    for (T s : iterable) System.out.println(s);
}

und in anderen Sprachen wäre das nur sowas wie

iterable.each { println it }

oder so, aber ... wo soll man da aufhören

 

[MikeTheBike]

Und [c]Pferd[/c] sollte im Normalfall auch keine weiteren öffentlichen Methoden deklarieren als von [c]AbstractTier[/c] vorgegeben.

Diese Aussage verstehe ich nun überhaupt nicht. Ich dachte, es geht gerade darum, dass ich in Tier die Methoden deklariere, die alle Tiere "können" (fressen, fortbewegen usw.), und bei Pferd, Hund, Katze, Chamäleon die Methoden, die jeweils einzigartig sind (oder nur für einige Tierarten gelten). Also z.B. Nackenhaare aufstellen, die Hautfarbe wechseln oder sich häuten.

 

[faetzminator]

Natürlich können diese Tiere alle etwas anderes (zusätzlich). Aber all diese Dinge müssen intern geschehen. Beispiel:
- Chamäleon: Farbe wechseln -> d.h. für mich, dass die Tiere immer irgendwo sind. Also gibts irgendwo [c]setPlace(Point coord, Map map)[/c] o.ä. Das Chamäleon würde nun einfach schauen, ob an der angegebenen Koordinate Stein ist, und dann "grau werden". Der äusseren Logik ist das egal.
- Nackenhaare aufstellen: Klingt so, alswär das ein Verhalten, dass sich aktiviert, wenn Gegner in der Umgebung sind. Was das Tier macht, wenn "Gegner" in der Umgebung sind, kann ebenfalls nur es wissen. Einige hauen vielleicht ab, andere greifen an. Also müsste man da irgendwie ein Update der "Gegner" durchgeben, und die Tiere machen, was sie wollen.
- Sich häuten: das passiert nach und nach. Also kann intern (dort wo verwendet, also vor einer Ausgabe auf der Konsole, GUI, ...) einfach die Zeit zurückgerechnet und die aktuelle Häutungsstufe berechnet werden.

Ist halt alles etwas abstrakt formuliert, aber kannst du dem folgen?

 

[schalentier]

Und [c]Pferd[/c] sollte im Normalfall auch keine weiteren öffentlichen Methoden deklarieren als von [c]AbstractTier[/c] vorgegeben.

Nee, das is Quatsch. Natuerlich kann eine Unterklasse einer beliebigen anderen (auch abstrakten) zusaetzliche, oeffentliche Methoden deklarieren. Die kannst du nur nicht direkt benutzen, wenn du nur eine Instanz vom Typ der abstrakten Oberklasse in der Hand hast (im Beispiel: [c]AbstractTier[/c]).

 

[faetzminator]

Nee, das is Quatsch. Natuerlich kann eine Unterklasse einer beliebigen anderen (auch abstrakten) zusaetzliche, oeffentliche Methoden deklarieren.

Natürlich kann sie.

Die kannst du nur nicht direkt benutzen, wenn du nur eine Instanz vom Typ der abstrakten Oberklasse in der Hand hast (im Beispiel: [c]AbstractTier[/c]).

Eben, und darum ist das Quatsch.
Natürlich kann man [c]public[/c] Methoden erstellen, nur muss man nicht davon ausgehen, dass diese jemals aufgerufen werden, solange man mit [c]AbstractTier[/c] arbeitet. Da wär ein [c]instanceof[/c] und Cast notwendig. Was ich/wir davon denke(n), sollte klar sein

 

[TiJay]

Natürlich kann sie.
Eben, und darum ist das Quatsch.
Natürlich kann man [c]public[/c] Methoden erstellen, nur muss man nicht davon ausgehen, dass diese jemals aufgerufen werden, solange man mit [c]AbstractTier[/c] arbeitet. Da wär ein [c]instanceof[/c] und Cast notwendig. Was ich/wir davon denke(n), sollte klar sein

Nur, weil man einmal im Programm mit [c]AbstractTier[/c] arbeitet, heißt das ja nicht, dass man auch immer damit arbeitet. An einigen Stellen ist es durchaus sinnvoll, auch eine einzelne Tierart zu betrachten und genau an diesen Stellen werden möglicherweise auch [c]public[/c]-Methoden des Tiers benötigt, welche andere Tiere bzw. [c]AbstractTier[/c] nicht besitzen.

Gruß,
Timo

 

[Marco13]

Stimmt. Ein "klassischer" Anwendungsfall für sowas wäre

interface Point {
    float getX();
    float getY();
}

class DefaultPoint implements Point {
    public float getX() { }
    public float getY() { }

    public void setX(float x) { }
    public void setY(float y) { }
}


class Somewhere {
    private DefaultPoint p = new DefaultPoint();

    void init()  {  p.setX(123); } // Kann public methods von "DefaultPoint" verwenden

    Point getPoint() { return p; } // Gibt den Point nur als "Point" raus
}

Aber noch beliebig viele andere, auch kompliziertere. Interessant wird das, wenn noch Kovarianz dazukommt, aber das wäre jetzt wohl zu viel.