OOP Generelle Frage zu Objekten in Arrays

[Alan47]

Hallo zusammen,

ich bin noch relativ neu im Bereich der objektorientierten Programmierung und ich habe grade ein Problem, bei dem ich wirklich anstehe. Es geht hier nicht um eine lange Implementierung, sondern nur um eine einzige Zeile.


Folgendes Problem: Nehmen wir an, wir würden eine Klasse "Einkaufskorb" schreiben. Wir haben weiters eine Klasse "Waren". "Waren" hat diverse von ihr abgeleitete Kinderklassen wie "Obst", "Elektronik" etc.

So weit, so gut. Ich möchte jetzt in meiner Klasse "Einkaufskorb" ein Feld namens "Inhalt" haben, das ein Array fixer Größe sein soll, und Referenzen auf "Waren"-Objekte enthalten soll. Es soll aber nicht nur "Waren"-Referenzen enthalten können, sondern auch Referenzen auf die Kindklassen von "Waren" aufnehmen können. So sollte beispielsweise Inhalt[0] eine Referenz auf ein Objekt der Klasse "Obst" sein können, Inhalt[1] eine Referenz auf ein Objekt der Klasse "Elektronik" etc.


Die große Frage ist: wie definiere ich so ein Array bzw. Feld in Java? Oder bin ich hier komplett am Holzweg und mein Ansatz ist so gar nicht durchführbar?


Gruß,


Alan



PS: Nein, das hier ist keine Hausaufgabe oder sonstiges (auch wenn mein Beispiel vielleicht so klingt 😉). Ich mache das aus persönlichem Interesse und weiß hier nicht weiter ^^'

 

[lollal]

Ein Arrray vom Typ Waren 😉

 

[Alan47]

Echt??? ô.o

So einfach? Aber wenn von der Klasse "Waren" etwas abgeleitet wird, dann ist ja die abgeleitete Klasse vom Platzbedarf im RAM her ja "größer", weil sie alles von der Mutterklasse erbt - plus das, was sie selber an Feldern und Methoden hat. Müsste dann auch nicht der Pointer auch entsprechend mehr Platz verbrauchen?

 

[lollal]

Das ist am Anfang etwas Tricky. Dein "Pointer" lässt dich nur auf Member zugreifen, die in Waren definiert sind. Wenn du in deinem Array also ein Elektronikartikel hast, welcher erstmal die Methode zeigeWatt() implementiert, kannst du darauf nicht zugreifen da deine Klasse Waren eben keine zeigeWatt()-Methode besitzt. Der Pointer bleibt der gleiche.

 

[Alan47]

Also die Pointer, die dann im Waren-Array drin stehen, können dann nur auf den Teil der Objekte zugreifen, der wirklich direkt in der "Waren"-Klasse definiert wurde, sehe ich das richtig?

Falls ja: gibt es trotzdem irgendeinen Weg, über diesen Pointer auch auf die Felder und Methoden (wie zum Beispiel die zeigeWatt()-Methode von dir) der Kindklassen zuzugreifen? Immerhin referenziert der Pointer das gesamte Objekt und nicht nur einen Teil davon - soweit ich weiß zumindest.


PS: Danke für die Hilfe bisher!!

 

[lollal]

Wie das technisch genau abläuft muss dir besser wer anders erklären, wäre sonst eher kontraproduktiv wenn du was lernen willst 🙂

Aber nein, aus deinem Waren-Array heraus kannst du nicht auf Subklassenspezifische Methoden zugreifen. Es sei denn, du castet es beim Aufrufen in den entsprechenden Typ.
Auch wenn dich das jetzt evt stört: wenn du genau nachdenkst, gibt es überhaupt keinen Grund auf subklassenspezifische Dinge über das Array zuzugreifen. In der Waren-Klasse oder per Interfaces kannst du ja Methoden festlegen, die aufrufbar sein müssen, zum Beispiel eine getInfo-Methode. Darin könntest du einen String o.ä. zurückliefern, welcher Objektspezifische Dinge wie die Wattzahl oder die Vitamine eines Obststücks zurückliefert.

Bedenke: deine Objekte im Array sind voll funktionstüchtig mit all ihren spezifischen Eigenheiten, du kannst nur nicht über das Array vom Typ Waren auf spezifische Dinge zugreifen.

 

[Alan47]

Auch wenn dich das jetzt evt stört: wenn du genau nachdenkst, gibt es überhaupt keinen Grund auf subklassenspezifische Dinge über das Array zuzugreifen.

Hm bei mir eben genau schon xD Wie du dir vielleicht gedacht hast, ist das Beispiel oben nur eine "Verallgemeinerung" dessen, was ich hier wirklich mache. Die Basis-Klasse (hier: "Waren") ist bei mir nicht sehr umfangreich, da sich die Gemeinsamkeiten der "Kinderklassen" auf ein Minimum beschränken.

Allerdings habe ich nur drei verschiedene "Kinderklassen" von "Waren" - wäre es vielleicht klüger, für jede dieser Kindklassen ein eigenes Objekt-Array vom Typ der jeweiligen Kindklasse anzulegen, um dann Vollzugriff auf all ihre Felder und Methoden zu haben? Es ist für mich nicht weiter von Bedeutung, ob alle Objekte in einem Array stecken oder in drei verschiedenen nach Typ sortiert. Der "Warenkorb" ist ja praktisch nur ein "Container". Aber wenn man es so macht, dass man - hier im Beispiel jetzt - drei Kindklassen hat und damit 3 Arrays vom Typ der jeweiligen Kindklasse aufstellt (ein Array für "Obst", eines für "Elektronik" und ein drittes für "Tiernahrung"), dann haben die Pointer, die in diesen Arrays enthalten sind, schon Zugriff auf die Felder und Methoden, die die Objekte von "Waren" geerbt haben, oder?

 

[Landei]

Es gibt einfach einen Unterschied zwischen dem statischen Typ einer Referenz (in Java spricht man nicht von "Pointern") und dem tatsächlichen Typ, auf dem die Referenz zeigt. Du kannst z.B. Sachen schreiben wie

CharSequence cs = "Bla";
Serializable s = "Foo";
Collection<Date> coll = new HashSet<Date>();

In der Regel versucht man so "allgemein" oder "aufgabenbezogen" zu bleiben wie möglich. Manchmal ist der genaue Typ unwichtig, sondern nur, ob du das Objekt serialisieren kannst. Manchmal reichen die Operationen von CharSequence aus, und du brauchst keinen String. Falls du doch an den "richtigen" Typ heranmusst, gibt es immer noch instanceof-Tests und Casts.

 

[Wortraum]

Echt??? ô.o

So einfach?

Ja, erschreckend, nech? 🙂 Elektronik, Obst, Bücher sind alles Waren (erben davon) und können somit alles, was eine Ware kann. Es ist daher immer erlaubt, sie einer Variable vom Typ Ware zuzuweisen.

Ware ware = new Elektronik();
/* Was Ware kann, kann Elektronik schon lange! */

Aber wenn von der Klasse "Waren" etwas abgeleitet wird, dann ist ja die abgeleitete Klasse vom Platzbedarf im RAM her ja "größer", weil sie alles von der Mutterklasse erbt - plus das, was sie selber an Feldern und Methoden hat. Müsste dann auch nicht der Pointer auch entsprechend mehr Platz verbrauchen?

Das braucht er sicherlich, aber die Speicherüberwaltung übernimmt Java, da muß man sich nicht drum kümmern.

Allerdings habe ich nur drei verschiedene "Kinderklassen" von "Waren" - wäre es vielleicht klüger, für jede dieser Kindklassen ein eigenes Objekt-Array vom Typ der jeweiligen Kindklasse anzulegen, um dann Vollzugriff auf all ihre Felder und Methoden zu haben?

Dir geht nie etwas verloren, wenn Du ein Objekt Elektronik in ein Feld für Waren-Objekte steckst. Wenn Du das Objekt allerdings wieder aus dem Feld mit Waren holst, ist es erst einmal nur als ein Waren-Objekt bekannt. Es ist ein bißchen wie mit einem großen Korb, wo jeder erst einmal was reinschmeißt; greift man dann rein, weiß man erst einmal nur, daß man eine Ware hat, und erst, wenn man sie sich genauer anschaut, sieht man, was es wirklich ist und was man damit spezielles machen kann.

List<Ware> korb = new ArrayList<Ware>();
… /* Korb füllen */
Ware eineWare = korb.get(0);
if (eineWare instanceof Elektronik) {
    /* aha, eineWare ist nicht nur Ware, sondern ganz speziell ein Objekt Elektronik */
    /* na gut, dann können wir es ja wie Elektronik behandeln und dazu umwandeln */
    Elektronik elektro = (Elektronik) eineWare;
    … /* mache irgend etwas mit elektro, was mit eineWare nicht geht */
}

Bleibt noch die Frage, ob man nun besser einen großen Warenkorb macht, in den man erst einmal alles reinschmeißt, oder ob man für jede Kategorie einen eigenen Korb macht. Das hängt wohl davon ab, was man so spezielles machen will und muß. Einerseits will man nicht überall prüfen, was für eine Ware man gerade hat, andererseits hätte man auch gerne einen einzigen Warenkorb und nicht viele kleine für unterschiedliche Waren.

Es könnte für jede Ware beispielsweise ein Info-Objekt geben mit Haltbarkeitsdatum, Garantiezeit oder Wattzahl, und nur die benötigten Angaben sind ausgefüllt. Dann könnte jede Ware eine Methode getInfo() haben, und man müßte nicht mehr auf Elektronik oder Obst prüfen.

Mir persönlich gefällt es nicht, einen Warenkorb noch einmal zu unterteilen und später aus den Teilen dann einen Gesamtpreis zu errechnen oder was auch immer, also kurz: irgendwann die Teile wieder als ganzes zu behandeln. Wenn es sich also vermeiden läßt oder nicht anderes dagegen spricht, würde ich einen Warenkorb für alle Waren machen.

 

[Alan47]

Ware ware = new Elektronik();
/* Was Ware kann, kann Elektronik schon lange! */

Das braucht er sicherlich, aber die Speicherüberwaltung übernimmt Java, da muß man sich nicht drum kümmern.

Na die Einstellung gefällt mir 😉

Dir geht nie etwas verloren, wenn Du ein Objekt Elektronik in ein Feld für Waren-Objekte steckst. Wenn Du das Objekt allerdings wieder aus dem Feld mit Waren holst, ist es erst einmal nur als ein Waren-Objekt bekannt. Es ist ein bißchen wie mit einem großen Korb, wo jeder erst einmal was reinschmeißt; greift man dann rein, weiß man erst einmal nur, daß man eine Ware hat, und erst, wenn man sie sich genauer anschaut, sieht man, was es wirklich ist und was man damit spezielles machen kann.

List<Ware> korb = new ArrayList<Ware>();
… /* Korb füllen */
Ware eineWare = korb.get(0);
if (eineWare instanceof Elektronik) {
    /* aha, eineWare ist nicht nur Ware, sondern ganz speziell ein Objekt Elektronik */
    /* na gut, dann können wir es ja wie Elektronik behandeln und dazu umwandeln */
    Elektronik elektro = (Elektronik) eineWare;
    … /* mache irgend etwas mit elektro, was mit eineWare nicht geht */
}

Ach SO, jetzt habe ich es begriffen! Ich kann bei diesen Referenzen dann praktisch nachprüfen, zu welcher Kindklasse von Waren sie tatsächlich gehören und dann quasi einen Typecast mit der Referenz auf die tatsächliche Kindklasse machen - ja das macht Sinn!

Einerseits will man nicht überall prüfen, was für eine Ware man gerade hat, andererseits hätte man auch gerne einen einzigen Warenkorb und nicht viele kleine für unterschiedliche Waren.

Genau diese Frage hat sich mir auch aufgedrängt - ich glaube ich werde jetzt doch nur ein Array machen und bei bedarf deine Lösung von oben mit dem Typecast anwenden.



Jungs, vielen vielen Dank für eure Hilfe, mir ist jetzt einiges klarer als vorher!!


Besten Dank,



Alan

 

[bygones]

wobei solche instanceof tests und dann folgende casts sehr zu bedenken sind... gibt meist immer eine elegantere und schoenere loesung !

also lieber finger weg von instanceof abfragen

 

[Wortraum]

wobei solche instanceof tests und dann folgende casts sehr zu bedenken sind... gibt meist immer eine elegantere und schoenere loesung !

Und verrätst Du uns welche?

 

[bygones]

Und verrätst Du uns welche?

kommt auf die Situation an...

es kann von falschem Design, falscher Nutzung bis hin zu Polymorphie alles sein.

Es gibt leider keine "Alles-Loesung".

 

[Wortraum]

Aber es gibt Ansätze, Ideen und Möglichkeiten. Die konkrete Lösung muß man meistens dem eigenen Wissenstand entsprechend selbst ertüfteln, und meistens fehlt nur der Ansatz.

Richtig ist wohl, daß es fast immer eine schönere und elegantere Lösung gibt, sofern man nicht schon Experte ist. 🙂

 

[Alan47]

Richtig ist wohl, daß es fast immer eine schönere und elegantere Lösung gibt, sofern man nicht schon Experte ist. 🙂

... und der bin ich in Java noch lange nicht 😉 Bin ersmtal froh, wenn ich vernünftig damit arbeiten kann und mein Programm halbwegs so funktioniert, wie ich mir das vorstelle - nachher denke ich mir dann eh meistens "Das wäre noch besser gegangen wenn..." aber nur so lernt man wirklich dazu glaube ich 😉


Gruß,



Alan