Re(10): Scheinbar sieht die Lösung echt so aus...
Geizhals » Forum » Programmierung » Java-Dau-Anfängerproblem... (63 Beiträge, 288 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
Java-Dau-Anfängerproblem...
11.07.2005, 13:50:53
Hi, Folks !

Habe mich in letzter Zeit wieder besseren Wissens in Java eingearbeitet...
Und hab' grad ein Micky-Maus-Prob:


public class Vater {

protected Vater() {}

public static boolean add ( int x ) {
return true;
}
}

public class Sohn extends Vater {

public static void main(String[] args) {
Sohn s = new Sohn();
Sohn.add(2);
}

public static int add ( int x ) {
return x;
}
}

---> Das ist nicht erlaubt - er motzt, weil die Methode add bei gleichen Parameter in Vater einen anderen Rückgabewert liefert als in Sohn...

Also in c++ wäre das erlaubt ;-).

Wozu braucht ma des ?

Also als Java-Laie dachte ich mir das wie folgt (und mußte daher schon viel umschreiben):
Es gibt eine Klasse Person - mit private-Gschichtln wie Zuname, Vorname, Gebdatum, ...
Person habe einen protected-Constructor - damit niemand selbst eine Person anlegen kann. Stattdessen gibt es eine Klassenmethode
> public static Person add(String Zuname, String Vorname, GregorianCal... GebDatum) - die zuerst mal nachsieht (in einem HashSet), ob es die Person schon gibt. wenn es sie gibt, liefert sie die bekannte Person zurück - wenn nicht, legt sie eine neue an und liefert die zurück. Grund: Auf diese Art will ich doppelte Personen vermeiden.

von Person gibt es eine abgeleitete Klasse Personal: sie hat dieselben Gschichtln wie Person - plus Job/Funktion, ...
Sie hat wieder einen protected Konstruktor - gleicher Grund wie bei Person.
Personal habe eine Reihe von Klassenmethoden "add"  -
so auch ein
> public static Personal add(String Zuname, String Vorname, GregorianCal... GebDatum)
---> Und genau da fetzt diese "$&%"!! Java-VM - eben wegen dem Rückgabewert von add().

Mir ist das ja komplett unklar...
Erstens sprech' ich hier von Klassenmethoden - also nix mit VMT. Irgendeine ominöse Forderung, warum das verboten sei in sauberen Design will noch nicht in meinen kleinen Schädel.
Zweitens ist mir der Workaround unklar...
Person::add() private machen nutzt auch nix - wieso net ???
Drittens scheint ein Object zurückliefern zwar als möglich aber bescheiden - denn jeder Aufrufende muß dann casten bzw. ein instanceOf scheint problematisch...
EDIT:
Viertens bin ich jetzt auf ein addPerson(), addPersonal(), ... ausgewichen - nur das ist ja auch besch*en... denn wozu sollte jede Klasse dann Trilliarden vererbter Methoden mitführen müssen ?

Ach ja, das bequeme Äquivalent in C++, das funktioniert:
class vater {
        public:
        static int add(int x);
};

int vater::add(int x)
{
        return 2;
}

class sohn: public vater
{
        public:
        static float add(int x);
};

float sohn::add(int x)
{
        return 2.3f;
}

int main() {
        sohn *s = new sohn();
        float f = s->add(2);
}



So oder so - ich denke wahrscheinlich zu C++-lastig...
wie macht man das sauber in Java ? Und /was/ ist der Hintergedanke von dieser IMHO stupiden, sinnlosen Limitierung ???

cu
ein frustrierter gepeinigter

11.07.2005, 14:10 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier
Antworten PM Alle Chronologisch
 
Melden nicht möglich
.  Re: Java-Dau-Anfängerproblem...  (Frankster am 11.07.2005, 14:07:47)
...  Re(3): Java-Dau-Anfängerproblem...  (Frankster am 11.07.2005, 14:19:36)
.....  Re(5): Java-Dau-Anfängerproblem...  (Frankster am 11.07.2005, 15:06:11)
.  Re: Java-Dau-Anfängerproblem...  (DeaconFrost am 11.07.2005, 17:13:42)
.............
Re(10): Scheinbar sieht die Lösung echt so aus...
12.07.2005, 17:34:34
Ging mir ja net um Java-Beschimpfung... Naja, eigentlich schon auch um Frustabladen ;-)

Das thread-modell halt ich hingegen für eine Riesen-Lüge... Genauso wie den Pointer-Verzicht.

Möglicherweise blick' ich noch zu eingeschränkt/vorbelastet auf die Themen, aber meine Hinweise waren:

Aus dem Javabuch:
"Dieses Beispiel wurde auf Linux-2.4 entwickelt, wo es in der VM keine preemptiven Threads gibt - daher ist ein dauernder Aufruf von yield() notwendig, damit der andere überhaupt drankommt"...
Sorry, aber das ist krank. Denn das bedeutet, daß ich portablen Code nur schreiben kann, indem ich dauernd manuell die Kontrolle an andere threads übergebe - nur dann brauch ich keine mehr...

Von der Idee her ist es ja super, wenn man eine portable Sprache schafft, die sogar die Typen portabel hat (anders als in C, wo ja zB int verschiedenste Wertebereiche annehmen kann) - nur ist die Literatur voll von "Unter Win95 klappte x.y.z nicht, da ist stattdessen a.b.c zu nehmen", "Unter Linux a.b.c wird die Thread-Priority nicht ausgewertet, unter a.b.d braucht man yield()", ...

Kurzum:
Es scheint so, als bin ihc in ähnlichen Problemen wie bei der HTML-Webseitenerstellung: Ich brauche [zumindest alle verbreiteten] Plattformen zur Verfügung, um zu testen. Gerade bei massiv parallelen Anwendungen mit extremer Userlast wird es vermutlich tausende Situationen geben, die kaum auszutesten sind - und man wird mit unterschiedlichsten nicht nachstellbaren Problemen konfrontiert sein [alles nur meine Gedanken dazu -- muß net so sein].

Pointer-Verzicht:
Sorry, entweder ich bin zu dämlich, oder in Wirklichkeit wurden Pointer in Referenzen umbenannt, die Arithmetik entfernt und voila waren die viel besseren Referenzen da.

Typsicherheit:
Sorry, aber Array-Überlauf, ... Da gibt's genug seeehr gute Bibliotheken dafür, die Dir das abnehmen. Nur via Bibliothek hab ich die Variante, in der Entwicklung alle Checks aufzudrehen und beim Ausliefern zu entfernen - um Früh Fehler zu finden und später performanter zu sein... Es scheint also wieder wie ein Verzicht.

Ich vermute echt, daß Java voll von tollen Ideen steckt, die sich mir natürlich noch nicht erschließen - allerdings die Umsetzung teilweise extrem schlampig ist (siehe obiges mit yield(), wobei das IMHO inzwischen deprecated ist und ich deswegen in einigem Source schon sleep(1) als quasi-Äquivalent gefunden habe [was IMHO auch seeehr zum kranken neigt].

Kann aber durchaus sein, daß ich bisher [fast] nur bescheidene Codebeispiele von bescheidenen Autoren gesehen habe... Nur weil ein paar Bücher schreibt, muß er sich damit ja nicht auskennen ;-)

Antworten PM Alle Chronologisch Zum Vorgänger
 
Melden nicht möglich
...  Re(3): Java-Dau-Anfängerproblem...  (DeaconFrost am 12.07.2005, 12:09:04)
.....  Re(5): Java-Dau-Anfängerproblem...  (DeaconFrost am 12.07.2005, 13:29:44)
.......  Re(7): Java-Dau-Anfängerproblem...  (DeaconFrost am 12.07.2005, 14:28:09)
.........  Re(9): Java-Dau-Anfängerproblem...  (DeaconFrost am 12.07.2005, 15:11:21)
.  Re: Java-Dau-Anfängerproblem...  (adhoc am 13.07.2005, 12:03:34)
...  Re(3): Java-Dau-Anfängerproblem...  (adhoc am 13.07.2005, 13:31:54)
...  Re(3): Java-Dau-Anfängerproblem...  (adhoc am 13.07.2005, 13:40:48)
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung