Re(12): Scheinbar sieht die Lösung echt so aus...
Geizhals » Forum » Programmierung » Java-Dau-Anfängerproblem... (63 Beiträge, 291 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(12): Scheinbar sieht die Lösung echt so aus...
12.07.2005, 18:47:20
Plattformunabhängigkeit...
Da hat Java am offensichtlichsten Merkmal (dem UI) doch Beispiele gesetzt:
AWT: Kleinster gemeinsamer Nenner...
Swing: Wir versuchen mehr - allerdings viel Code in Java und unportabel.
Denn gerade hier wurde der Ansatz halbherzig verfolgt:
Einerseits manche Sachen umständlich gelöst bzw. bewußter Verzicht (um unabhängig zu sein), andererseits unterschiedliche setLookAndFeel-Möglichkeiten je nach Plattform..
In Swing haben sie es trotzdem recht gut geschafft, brauchbar unabhängige Apps zu bauen... Allerdings zu einem hohen Performance-preis. Denn ich /befürchte/, daß viel von den routinen zum Nachbilden in Java geschrieben ist - und das einfach schlechtestens performt. Rein Subjektiv verhält sich Swing oder gar SWT auf meinem PentiumIV mit 3GHz und 512MB Ram definitiv träger als Delphi3 auf meinem Pentium-133MHz mit 64MB -
Also ich bezweifel, daß die Java-Apps flotter oder nur gleich schnell sind ;-)
C++ profitiert davon, daß es sich für den Compiler-Optimizerlauf /viel/ Zeit nehmen darf... Net umsonst dauert das voll optimierte Compilieren von zB einer aktuellen KDE durchaus mal > 12h.... einem JIT-Compiler gesteht man derart umfangreiche Optimierungen halt naturgemäß kaum zu ;-)

Ad "Ist garantiert"... Das impliziert mindestens einen Check - nämlich im besten Fall nur das Abfragen eines "Ist_garantiert"-Boolean ;-). Das macht per se wenig aus - summiert sich aber...

Array-Überlauf:
Das meinte ich mit Bibliotheken...
Es gibt genug Array-Bibliotheken für C und C++, die genauso wie in Java arbeiten... Ich bilde mir dunkel ein, daß ich beim Qt-Designen darüber stolperte - wo das echt auch so gelöst ist..
Nur wie gesagt - sobald's in einer Bibliothek ist (die's ja genauso für sichere Strings, ...) gibt - gibt's oft einen Schalter "verhindere Checks" bzw. andere Zugriffsvarianten....

Performance abschließend:
Ich vermute, daß mal alle Programmierer (mich eingeschlossen) faule Schweine sind. Dementsprechend überlegt sich keiner, wie O() seiner Funktionen aussieht - und muß nachher tunen... Wenn man postuliert, daß die zur Verfügung gestellten Klassen in Java sauber optimiert sind - was ich tue - so ist es durchaus möglich, daß C++-Programme ungefähr gleich performen wie in Java... eben wenn man annimmt, daß alles vom Programmierer geschriebene gleich schlecht ist.
ABER... Es gibt weitaus mehr vorgefertigtes in C/C++ - was sich auch in den Programmen äußert... Ich schreib seit 10 Jahren kommerziell in C - und lerne noch immer jedes Monat über Bibliotheken, ... dazu. Man sieht's auch am Source.. Er wird immer effizienter, sauberer... und kürzer, weil man mehr und mehr stöpselt ;-). Wenn man annimmt, daß das in Java ähnlich ist... Gewinnt die Sprache mit mehr fertigen Bibliotheken.. Also C ;-)

Illegale Casts... Nun ja, ich mag das Vertraue-dem-Programmierer-Prinzip. Wobei die Cast-Fehler IMHO nur Anfängerfehler sind...
Und Tools wie splint/lclint weit mehr Sicherheit garantieren [zB "illegales" modifizieren referenzierter Werte], als in Java derzeit umgesetzt ist... man muß sie nur verwenden ;-)

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