Typecasting Problem

Hallöchen,
bin (seit Jahren) mal wieder in Java unterwegs.

Folgendes Problem: Ich benötige ein Typecast und stelle mich gerade irgendwie dumm an.

Szenario (Beispiel):

Ich habe eine Klasse „Haus“, von der abgeleitet weitere Klassen.

Code sieht derzeit etwa so aus:

public class Haus { 
Vector Zusatzattribute = new Vector(); 
public void zeigeAlleAttribute()
 { for (int i=0;i

Der Code ist nur schematisch. Mir geht es um die Logik.

Initialisieren möchte ich eigentlich immer Objekte des Typs "Haus", jedoch verwenden möchte ich Objekte aller Typen.

Wie biege ich das Typecasting hin, dass ich zwischen den Objekten hin- und herwechseln kann ohne sie klonen zu müssen, also etwas der Art:



    
     Haus X = new Haus();
     Villa V = (Villa) X;
     X.Erweitern("Kunterbunt");
     Luxusvilla L = (Luxusvilla) L;
     L.Erweitern("Ortsrand");
     Haus H = (Haus) L;
     H.zeigeAlleAttribute();
    
     Haus Y = new Haus();
     Bruchbude B = (Bruchbude) Y;





Danke,
Michael

hallo

Wie biege ich das Typecasting hin, dass ich zwischen den
Objekten hin- und herwechseln kann ohne sie klonen zu müssen,
also etwas der Art:

Haus X = new Haus();
Villa V = (Villa) X;
X.Erweitern(„Kunterbunt“);
Luxusvilla L = (Luxusvilla) L;
L.Erweitern(„Ortsrand“);
Haus H = (Haus) L;
H.zeigeAlleAttribute();

Haus Y = new Haus();
Bruchbude B = (Bruchbude) Y;

also, so geht das keinesfalls. du kannst nicht ein objekt der klasse „Haus“ auf einen typ casten, der von Haus abgeleitet ist. das geht nur umgekeht - also z.b.

Haus haus = new Villa();

dabei kannst du dann aber auch nur jene Methoden nutzen, die dir Haus anbietet. willst du methoden von Villa nutzen, musst du auf diesem datentyp bleiben.

hin und wieder hilft man sich dadurch, dass man bereits in der superklasse (also in Haus) alle methoden definiert, die man brauchen kann, allerdings entweder als abstrakt (muss also von der subklasse implementiert werden) oder so, dass man nur eine UnsupportedOperationException wirft. auf diese weise kennt bereits die superklasse alle methoden und man sich brav auf das interface konzentrieren und nicht gegen eine tatsächliche implementierung programmieren (einer der hauptgrundsätze der objektorientierten programmierung).

du kannst allerdings auch den weg über reflection gehen - da kannst du jede beliebige methode auf jedes beliebige objekt aufrufen (teilweise auch private methoden!). dann kann dich aber der compiler nicht mehr vor dummheiten schützen :wink:

lg
erwin

Methodenverwaltung dumm gemacht?

also, so geht das keinesfalls. du kannst nicht ein objekt der klasse „Haus“ auf einen typ casten, der von Haus abgeleitet ist. das geht nur umgekeht - also z.b.

Okay, soweit so gut.
Dann muss ich wohl Interfaces nutzen.

Jetzt aber folgende Schwierigkeit:
Eigentlich brauche ich sowohl Objekte der Basisklasse als auch der abgeleiteten Klassen.
Prinzipiell haben alle Klassen genau die gleichen Methoden, nur halt überschrieben.
Würde ich die jetzt alle in „Haus“ packen, dann würde mein Code etwa so aussehen:

public String toString()
switch (this.getClass)
{
 case "Haus": {return "Das ist ein ganz normales Haus.";}
 case "Villa": {return "Du wohnst in der Villa "+this.getName()}
 case "Bruchbude"...
}

Da die Codesegmente, von denen wir reden, jetzt allerdings nicht eine, sondern ein paar Hundert Zeilen groß sind und es richtig viele Möglichkeiten gibt, ist das für die Übersichtlichkeit und Wartbarkeit des Codes doch fatal.
In Interfaces kann ich jedoch keinen Code definieren und Objekte aus abstrakten Klassen kann ich nicht erzeugen.

Wie verwalte ich also meine überschriebenen Objekte am Besten, so dass ich eine Basis habe und die gleichen physikalischen Daten auf x verschiedene Weisen bearbeiten kann?

Danke,
Michael

du kannst allerdings auch den weg über reflection gehen

Davon habe ich leider keine Ahnung, wie geeignet ist sowas für Web Services? O.o

Gruß,
Michael

Interface-Namen?
Wenn ich mit Interfaces arbeite, dann funktioniert mein „this.getClass()“ leider nicht mehr, um die derzeitige Arbeitsperspektive zu differenzieren.
Gibt es eine Möglichkeit, dass ein Objekt selbsttätig herausfindet, aus welchem Interface es gerade bearbeitet wird?

Danke,
Michael

Ich denke du hast prinzipiell nicht verstanden, wie Objektorientierte Programmierung und das Klassenkonzept funktioniert.

Du kannst nicht

Haus haus = new Haus();
Villa villa = haus;

machen.
Das geht prinzipiell nicht, auch nicht mit Interfaces.

Ein Haus ist ja schließlich keine Villa, ein Villa ist aber ein Haus. Nur so rum klappt das. Mit Interface oder nicht hat das nichts zu tun.

Villa villa = new Villa(),
Haus haus = villa;

So rum wird ein Schuh draus.

Nochmal abstrakt…

Ich denke du hast prinzipiell nicht verstanden, wie
Objektorientierte Programmierung und das Klassenkonzept
funktioniert.

Naja…
Eigentlich ist eher das Problem, dass mir mehr die richtigen Worte für das fehlen, was ich modellieren will, ohne dabei alles das erklären zu müssen, was ich eigentlich damit vorhabe.

Aber Du mußt Dich nicht an Villen und Häusern aufhängen, wenn das für Dich das Problem ist.

Du kannst nicht
Haus haus = new Haus();
Villa villa = haus;
machen.
Das geht prinzipiell nicht, auch nicht mit Interfaces.
Ein Haus ist ja schließlich keine Villa, ein Villa ist aber ein Haus. Nur so rum klappt das. Mit Interface oder nicht hat das nichts zu tun.
Villa villa = new Villa(),
Haus haus = villa;
So rum wird ein Schuh draus.

ALso, ich kann ganz allgemein nicht
X X= new X();
Y Y= X;
machen, nur
Y Y = new Y();
X X = Y;
Habe ich jetzt die Objektorientierung richtig verstanden?
Haus, Villa, das sind doch alles nur Beispiele. Wenn mir jetzt kein gutes Beispiel einfällt für das was ich eigentlich will, heißt das noch lange nichts über mein Verständnis des OOD.

Abstrakt ist es einfach so, dass es ein Objekt X gibt, was einen eigenen Namen hat und einen Vektor mit verschiedenen Werten.
In diesem Vektor werden je nach Perspektive des Betrachters verschiedene Einträge gemacht.
Als anderes Beispiel:

  • Wenn der Betrachter ein Grundschüler ist, dann schreibt er mit Kreide auf das Ding „Mein Lerä ist dohf!“
  • Wenn der Betrachter ein Sozialwissenschaftler ist, dann schreibt er mit Kuli auf das Ding „Ich habe mein Abi geschafft!“
  • Wenn der Betrachter ein Informatiker ist, schaltet er es ein und tippt über die Tastatur etwas ein.
    Trotzdem ist es physikalisch ein Laptop und egal was der „wahre Sinn“ ist, so kann man sowohl mit Kreide als auch Kuli als auch Tastatur darauf schreiben und egal womit man schreibt, es steht trotzdem da.
    Aber nur weil der Betrachter ein Grundschüler ist, wird aus dem Laptop noch lange keine Tafel.

Meine Güte… Tafel, Laptop, Villa, Haus… ich will doch einfach nur verschiedene Sicht- und Handlungsweisen mit ein und demselben instantiierten Objekt vornehmen, wobei es für mich eigentlich keinen Sinn macht, dem „Basisobjekt“ (und ich rede bewusst NICHT von der Basis_klasse_!) alle perspektivenspezifischen Methoden mitzugeben und dann über tausend If-Bedingungen auszusortieren welcher View jetzt gerade unter welchen Bedingungen welche Methoden wie nutzt.
Ebensowenig macht es für mich Sinn, tausend Objekte anzulegen, die zig Megabyte an Daten rumschleppen und bis auf ein Zeichen in einer bestimmten Methode alle Klone voneinander sind.
Eine Krücke wäre natürlich über call-by-reference verschiedene Accessor-Objekte zu nutzen, die alle das Basisobjekt referenzieren. Aber das kann’s doch nicht sein!

Und nein.
Ich bin kein Experte in objektorientierter Datenmodellierung, darum frage ich ja, wie ich sowas am besten angehen kann.
Und ob Rockefeller und Mahatma Ghandi jetzt beide die Ansicht teilen, dass die Münchener Hofgasse 17 als Villa verwaltet werden soll, ist doch bei der Java-Entwicklung eigentlich egal - oder?

Gruß,
Michael

Hallo,

je mehr Beispiele Du verwendest, umso komplizierter wird es :wink:

Du willst also ein Objekt aus verschiedenen Sichtweisen betrachten? Dann arbeite mit Interfaces:

interface Beschreibbar {
public void beschreiben(String aufschrift);
}

interface Bewegungsfaehig {
public void bewegen(Koordinaten ziel);
}

class Tafel implements Beschreibbar, Bewegungsfaehig {
public void beschreiben (String aufschrift) {
kreide.schreibe(aufschrift);
}

public void bewegen(Koordinaten ziel) {
schiene.hochRunter(ziel);
}
}

class Laptop implements Beschreibbar, Bewegungsfaehig {
public void beschreiben (String aufschrift) {
wordVIOderWerAuchImmer.schreibe(aufschrift);
}

public void bewegen(Koordinaten ziel) {
user.bewegMich(ziel);
}
}

Vielleicht ist das ja, was Du suchst? Falls nicht, empfehle ich konkreter zu werden statt mit Beispielen zu verkomplizieren.

Gruß
Newlukai

Ja genau - oder?

je mehr Beispiele Du verwendest, umso komplizierter wird es :wink:

Das habe ich befürchtet… O.o

Du willst also ein Objekt aus verschiedenen Sichtweisen
betrachten? Dann arbeite mit Interfaces:

Jajajajajaaaa genau darum habe ich das ja auch gesagt und gefragt ob es eine schlaue Möglichkeit gibt, rauszufinden aus welchem Interface das Objekt gerade bearbeitet (betrachtet) wird.
Und zusätzlich interessiert mich halt, ob es eine schlaue Möglichkeit gibt, mit einer interfacebedingten Überschreibung zu arbeiten ohne dass man eine einzige riesige Klasse mit sowas fabriziert:

public String toString()
{ switch (jetzigesInterfacee.equals(A)) 
 case "A": {toString\_A();}
 ...
 case "X": {toString\_X();}}}
private String toString\_A()
{ return "Das ist gerade Interface A"; }
private String toString\_B()
{ return "Wichtig ist für B "+$meineString; }

Aber dafür habe ich mittlerweile auch eine Lösung, und die wäre dass ich für jedes Interface hinter die Basisklasse noch eine abstrakte Klasse schalte, welche die Methoden des jeweiligen Interfaces enthält, dann brauche ich außer den tollen Case-Statements eigentlich keine „Unübersichtlichmachung“ der Basisklasse.

Wobei mich halt gewundert hat, dass Serviceprogrammierung in Java so kompliziert ist, in Shell ist das viel einfacher O.o

Vielleicht ist das ja, was Du suchst? Falls nicht, empfehle ich konkreter zu werden statt mit Beispielen zu verkomplizieren.

Konkret ist das, was ich in Shell machen würde:

##---SchuelerSicht
function bemalen{ echo $@ \>Laptop/Aussentext }
function nachlesen { echo "Da steht dran: `cat Kulitext`" }

##---InformatikerSicht
function programmStarten{ $1 }
function dateiSchreiben { echo $@ \>\> Laptop/infos.txt }
function nachlesen { cat Laptop/infos.txt }

##---Laptop
useFile="Datei";
groesse="15.4 Zoll";
function etwasSchreiben { cat \> Laptop/$useFile }
function nachlesen { cat $1 }

##---Objektnutzung
. Laptop.sh
function nutzeAls{
 Sichtweise=$1;
 $Sichtweise;
 shift;
 $@}
function nutze { $@ }

while ( read Zeile ) { $@ }
  • Das Objekt selbst hat also gewisse Attribute, welche in jeder Sicht erhalten bleiben und Funktionen, welche für alle Sichten verfügbar sind (aber je nach Sicht eine andere Bedeutung haben können).

  • Durch bestimmte Sichten (Nutzungsweisen) können neue Attribute des Objekts hinzu kommen.

  • Die Anzahl der möglichen Sichten und Attribute ist hier vom Objekt selbst nicht eingeschränkt. Eigentlich ist das Objekt sogar so „dumm“ dass es gar nicht wissen kann, was man mit ihm alles anstellen können will und trotzdem ist es möglich (auf der Wand steht ja auch nicht drauf, dass man da Nägel einklopfen kann)

  • Je nach Bedarf können hier spontan Sichten gewechselt, hinzugefügt oder entzogen werden, was mögliche Handlungen, nicht jedoch die Attribute, welche sie modifiziert haben, beeinfusst.

  • Das, was die einzelnen Sichten mit dem Objekt selbst anstellen ist nicht eingeschränkt durch das, was in der „Klassendefinition“ selbst als Code festgelegt ist.

  • Alles, was die Sichten tun, beeinflusst tatsächliche Attribute des Objekts.

Und sowas, wenn ich es jetzt richtig verstanden habe, geht in Java gar nicht und habe deswegen jetzt den Ansatz, nur über Interfaces plus abstrakte Klassen zu basteln, welche im Basisobjekt alle schon erweitert sein müssen, also:

So sieht mein Ansatz jetzt KONKRET aus:

abstract class Core 
{ 
 protected Vector Attribute;
 public void deleteAttribute() { ... }
 public void addAttribute(String, Object) { ... }
 public Object readAttribute(String) { ... }
 public void modifyAttribute(String, Object) { ... }
}

abstract class SchuelerArbeit extends Core
{
 void bekritzeln(String X)
 { this.addAttribute("Aussentext",X); }
 protected toString\_Schueler() { ... }
}

class Laptop extends SchuelerArbeit, AbiArbeit, StudiArbeit implements SchuelerSicht, AbiSicht, StudentenSicht
{
 public toString()
 { switch (this.Interface) {
 case "Schueler": { return toString\_Schueler(); }
 case "Abiturient": { return toString\_Abiturient(); }
 case "Student": { return toString\_Student(); } }
 } 
}

interface SchuelerSicht { 
 public toString;
 public bekritzeln; }

interface AbiSicht { 
 public toString;
 public schreiben; }

interface StudentenSicht { 
 public toString;
 public schreiben; }

Gruß,
Michael

ALso, ich kann ganz allgemein nicht
X X= new X();
Y Y= X;
machen, nur
Y Y = new Y();
X X = Y;

Habe ich jetzt die Objektorientierung richtig verstanden?

Nein.

Du kannst ganz allgemein nicht ein Objekt zu einem Objekt-Typ casten, den es nicht unterstützt.

X X= new X();
Y Y= X;

Das geht, wenn „X extends Y“ oder „X implements Y“ gilt.
Dass du das X einem Y zuweisen kannst, muss ja das X alle Methoden und Eigenschaften besitzen, die ein Y auch hat.

Y Y = new Y();
X X = Y;

Das geht, wenn „Y extends X“ oder „Y implements X“ gilt.

Es kann aber nur eines von beiden gelten. „X extends Y“ und „Y extends X“ macht ja gleichzeitig keinen Sinn.

Beispiel:

  • Ein Mensch hat einen Namen und kann atmen, d.h. er habe die Eigenschaft „Name“ und die Methode „atmen()“.

  • Eine Frau sei abgeleitet von Mensch, sie kann aber auch ein Kind bekommen, sie habe also zusätzlich die Methode „gebaeren()“.

Damit ergeben sich folgende Klassen:

Klasse Mensch:

  • Eigenschaft: Name

  • Methode: atmen()

Klasse Frau:

  • Eigenschaft: Name (geerbt von Mensch)

  • Methode: atmen() (geerbt von Mensch)

  • Methode: gebaeren()

Nun kannst du machen:

Mensch hans = new Mensch();
hans.Name = "Hans";
hans.atmen();

Frau astrid = new Frau();
astrid.Name = "Astrid";
astrid.atmen();
astrid.gebaeren();


Mensch astrid2 = astrid;
astrid2.atmen();

Aber du kannst doch jetzt nicht machen:

Frau hans2 = hans;
hans2.gebaeren();

Würde das gehen, müsste Hans ja jetzt auch die Methode „gebaeren()“ besitzen.
Die hat er aber nicht, weil Hans eine Instanz von Mensch ist und nicht eine Instanz von Frau.

Jajajajajaaaa genau darum habe ich das ja auch gesagt und
gefragt ob es eine schlaue Möglichkeit gibt, rauszufinden aus
welchem Interface das Objekt gerade bearbeitet (betrachtet)
wird.

Ob ein Objekt ein bestimmtes Interface unterstützt findest du in Java mit „instanceof“ raus.

Beispiel:
Ein Interface und zwei Klassen, die das Interface implementieren.

Interface Beschreibbar:
Methode: beschreiben()

Klasse Laptop implements Beschreibbar
Methode: beschreiben() (geerbt von Beschreibbar)
Methode: einschalten();
Methode: ausschalten();

Klasse Zettel implements Beschreibbar
Methode: zusammenknuellen();
Methode: wegwerfen;

Klasse Mensch:
Eigenschaft: Beruf;
Methode:
schreibeAuf(Beschreibbar b) { b.beschreiben(); }

Dann kannst du machen:

Beschreibbar laptop = new Laptop();
Beschreibbar zettel = new Zettel();

Mensch schueler = new Mensch();
schueler.Beruf = "Schüler";

Mensch informatiker = new Mensch();
informatiker.Name = "Informatiker";


**schueler.schreibeAuf(zettel);  
informatiker.schreibeAuf(laptop);**  

Und zusätzlich interessiert mich halt, ob es eine schlaue
Möglichkeit gibt, mit einer interfacebedingten Überschreibung
zu arbeiten ohne dass man eine einzige riesige Klasse mit
sowas fabriziert:

public String toString()
{ switch (jetzigesInterfacee.equals(A))
case „A“: {toString_A();}

case „X“: {toString_X();}}}
private String toString_A()
{ return „Das ist gerade Interface A“; }
private String toString_B()
{ return "Wichtig ist für B "+$meineString; }

Nein nein nein…
Du machst doch da kein switch() oder ne if-Abfrage. Damit man das nicht machen muss, DAFÜR macht man doch Objektorientierte Programmierung. Das Schlüsselwort heißt hier „dynamische Bindung“. Es wird automatisch die richtige Methode aufgerufen.

public interface HatBeschreibung {
 public String getBeschreibung(); 
}

public class A extends HatBeschreibung {
 public String getBeschreibung() {
 return "Hier ist Klasse A";
 }
}


public class B extends HatBeschreibung {
 public String getBeschreibung() {
 return "Hier ist Klasse B";
 }
}


Jetzt kannst du machen:

HatBeschreibung x = new B();
HatBeschreibung y = new A();


String beschreibungX = x.getBeschreibung(); 
String beschreibungY = y.getBeschreibung();

Ergebnis:
beschreibungX ist dann: "Hier ist Klasse B"
beschreibungY ist dann: "Hier ist Klasse A"

Nochmal von vorn…

Prinzipiell haben alle Klassen genau die gleichen Methoden,
nur halt überschrieben.
Würde ich die jetzt alle in „Haus“ packen, dann würde mein
Code etwa so aussehen:

public String toString()
switch (this.getClass)
{
case „Haus“: {return „Das ist ein ganz normales Haus.“;}
case „Villa“: {return "Du wohnst in der Villa "+this.getName()}
case „Bruchbude“…
}

Du packst aber nicht alle in Haus.
Du überschreibst die Methode toString() in den einzelnen Klassen Haus, Villa und Bruchbude. Es wird dann automatisch die richtige Methode gewählt (Dynamische Bindung).

Also, du wuerdest z.B. folgende Klassenstruktur erstellen:

public class Haus {
 public String toString() { return "Das ist ein ganz normales Haus."; }
}

public class Villa **extends Haus** {
 private String name = "...";
 public String getName() { return name; }
 public String toString() { return "Du wohnst in der Villa "+this.getName(); }
}

public class Bruchbude **extends Haus** {
 public String toString() { return "Das ist eine Bruchbude"; }
}

Dann kannst du machen:

Haus haus1 = new Haus();
Haus haus2 = new Villa();
Haus haus3 = new Bruchbude();

haus1.toString(); // Ergibt "Das ist ein ganz normales Haus";
haus2.toString(); // Ergibt "Du wohnst in der Villa..."
haus3.toString(); // Ergibt "Du wohnst in einer Bruchbude"

Du brauchst also keine Fallunterscheidung. Die nimmt dir die dynamische Bindung ab. haus2 ist eine Instanz von Villa. Deshalb wird bei haus2.toString() automatisch die richtige toString() Methode aus Villa benutzt.

Genau DESHALB macht man ja Objektorientierung, um eben keine Unterscheidung mittels if-Abfragen durchfuehren zu muessen, sondern verschiedene Objekte auf einen gemeinsamen Obertyp abbilden zu koennen und dann transparent mit dem Obertyp arbeiten zu konnen, ohne dass man sich gedanken machen muss, von welchem Typ das Objekt wirklich ist.

Erst musst du dir darüber klar geworden sein, wie das funktioniert. Erst dann brauchen wir weiter machen. Ist dir obiges jetzt klar?

hallo nochmal

man kann mit java wunderbar prozedurale programme schreiben, ohne jemals auch nur ansatzweise die objektorientierte programmierung zu streifen. um java wirklich ausnutzen zu können, muss man komplett umdenken.

in deinem fall merkt man - mit verlaub - dass du wirklich keine ahnung von objektorientierung hast. du wirst zwar lauffähige programme mit java schreiben können, die vielleicht sogar ganz gut funktioneren - nur sind die eben prozedural und eher an C angelehnt.

ich empfehle zuerst einmal ein gutes buch, dass die objektorientierung an sich vermittelt. ganz gut gefällt mir die serie von „head first“ - da gibt es ganz nette bücher, die unterhaltsam das nötige wissen beibringen.
z.b. http://www.amazon.de/Head-First-Java/dp/0596009208/r…
oder auch http://www.amazon.de/Head-First-Design-Patterns/dp/0…

lg
erwin

man kann mit java wunderbar prozedurale programme schreiben, ohne jemals auch nur ansatzweise die objektorientierte programmierung zu streifen. um java wirklich ausnutzen zu können, muss man komplett umdenken.

Das weiß ich schon.

du wirst zwar lauffähige programme mit java schreiben können, die vielleicht sogar ganz gut funktioneren - nur sind die eben prozedural und eher an C angelehnt.

Was durchaus daran liegen kann, dass ich in den letzten 4-5 Jahren fast nur in Shell und SQL*plus unterwegs war. :stuck_out_tongue_winking_eye:

Naja. Wenigstens eins habe ich gelernt: Ich habe schneller eigene Antworten, als sie hier zu bekommen - Irgendwas mache ich wirklich grundlegend falsch in der Art und Weise, wie ich meine Probleme beschreibe :frowning:

Gruß,
Michael

Langsam komme ich dahinter, was Du vorhast. Aber nur langsam. Und das was Du vorhast, ist auf dem Weg, den Du gehen willst, nicht machbar. Bzw. es ähnelt dem klassischen „Von-hinten-durch-die-Brust-ins-Auge“.

So wie ich das verstehe, hast Du eine Klasse Laptop, die von Schülern, Abiturienten und Studenten genutzt werden kann. Und um die Art und Weise festzulegen, wie die jeweilige Person den Laptop benutzt machst Du eine Fallunterscheidung innerhalb der Methode des Laptops.
Das ist grundlegend verkehrt, denn von wem ein Laptop verwendet wird, ist für ihn/es völlig irrelevant. Ob ein Schüler oder ein Student draufrum hämmert macht keinen Unterschied.

Vielmehr müßtest Du eine Methode „benutzen(Laptop l)“ in den Klassen Schüler, Abiturient und Student zur Verfügung stellen. Von außen wird dann der zu beschreibende Laptop übergeben und die jeweilige Klasse nutzt dann den Laptop auf die jeweilige Art und Weise.

Gruß
Newlukai

hallo

Naja. Wenigstens eins habe ich gelernt: Ich habe schneller
eigene Antworten, als sie hier zu bekommen - Irgendwas mache
ich wirklich grundlegend falsch in der Art und Weise, wie ich
meine Probleme beschreibe :frowning:

eine frage so zu stellen, dass jeder sofort weiss, worum es geht, ist manchmal eine rechte kunst. wenn ich mir manche postings hier anschaue, wundert es mich, wenn die leute überhaupt eine antwort bekommen…

techniker sind üblicherweise lesefaul. wenn du also dein problem mit seitenlangen codebeispielen ausstaffierst, werde 50% der potentiellen helfer schon auf den nächsten thread gewechselt sein. die kunst ist hier, sowenig beispiele, dafür so prägnant wie möglich zu liefern. bei beispielklassen, die das typecasting betreffen interessiert NIEMANDEN die toString-Methode noch die vielen Hilfsmethoden. nur auf das wesentliche beschränken - das spart tipparbeit, lesezeit und erhöht die chance auf eine brauchbare antwort.

das weitere problem: in einem forum erwartet man sich eher kurze gezielte fragen. das vermitteln von grundlagenwissen sprengt allerdings den rahmen - da bist du besser beraten, wenn du dir entsprechende literatur besorgst.

in deinem speziellen fall hast du sicher recht - durch eigenes ausprobieren bzw. analysieren anderer programme wirst du eher für dich brauchbare antworten bekommen. liegt daran, dass jemand, der schon gut mit der oop umgehen kann, deine frage nicht mehr nachvollziehen kann - und jemand, der sich nicht so gut auskennt, es auch nicht erklären kann.

aber kopf hoch - da mussten wir alle durch.

lg erwin

1 Like