Re(19): Scheinbar sieht die Lösung echt so aus...
Geizhals » Forum » Programmierung » Java-Dau-Anfängerproblem... (63 Beiträge, 296 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(19): Scheinbar sieht die Lösung echt so aus...
13.07.2005, 12:42:02
Umso besser, wenn du schon Bescheid weisst! Ich versuche nur gründlich zu sein, damit Du nicht nur die halbe Wahrheit hörst...

Wie teuer Exception Handling ist, kann ich dir nicht sagen. Das hängt aber auch (wie alle Performance-Überlegungen) von zu vielen Faktoren ab: Plattform, Implementierung der VM, Fähigkeit des Compilers, der JIT, usw.
Ich denke, das ist aber in jedem Fall hochoptimiert, da schon seit Urzeiten in der Sprache inkludiert.
Exception Handling ist eine wichtige Komponente für modernes Design. Es ist in den meisten Fällen besser als "komische" Rückgabewerte oder dergleichen, weil der Aufrufer einer Methode auf Fehlerfälle derselben besser reagieren kann bzw. diese auch noch oben durchgereicht werden können (zentrale Behandlung von Ausnahmen).
Exception Handling ist aber nicht angebracht, wenn den Aufrufer die Fehlerfälle ohnehin nicht interessieren (close ist schiefgegangen. so what?) oder er nichts dagegen unternehmen kann (internal error? na toll!).
In jedem Fall ist es wichtig Exceptions gut zu dokumentieren. Insbesondere RuntimeExceptions, die bewusst ausgelöst werden (z.B.: Diese Methode wirft eine NullPointerException, wenn du eine null-Referenz übergibst).
Performance-Überlegungen sollten nur eine sehr untergeordnete Rolle spielen. Nur insofern, als man sich schon überlegen sollte, ob man eine Exception jetzt wirklich braucht oder nicht. Weder übertriebener Einsatz (auch für fast alle Normalfälle schon Exceptions) noch zu sparsamer Umgang (Das tritt eh nie auf) sind anzuraten.
Ach ja: Für private bzw. protected Methoden verwendet man meist assert zur Einhaltung von pre- bzw. postconditions. Wenn diese falsch angesteuert werden, sind das ja eher Programmierfehler (sind ja "meine eigenen" Methoden).
Für public Methoden wird mit if-Statements abgefragt und ggfs. eine Exception geworfen. Hier gilt das Prinzip der Vorsicht. Man bietet ja eine Schnittstelle nach aussen an.

Im Fall deines Freundes würde ich aber Exceptions in jedem Fall vorziehen. Warum? Egal, ob er jetzt vorher prüft oder nachher die Exception fängt, in jedem Fall muss der Ausnahmefall irgendwie behandelt werden, wenn er eintritt. Die Codeersparnis in diesem Fall ist also gleich Null.
Außerdem ist die interne Prüfung der VM auf eine Division durch Null ganz sicher nicht langsamer (weil schon fest verdrahtet in der VM), als eine manuelle Prüfung mittels Java-Code. Wenn die Instruktionen selten ausgeführt werden sogar sicher langsamer, weil dann wird interpretiert (wegen einem Durchlauf springt der JIT erst gar nicht an). Also kann man hier nur schlechter liegen.

Die Klasse SoftReference ist, glaube ich, was du suchst. Es gibt auch noch die Klasse WeakReference. Wirf einfach mal selbst einen Blick in die API-Beschreibung (siehe http://java.sun.com/reference/api/index.html ).
Um entsprechend zu parametrisieren genügt es ja die entsprechenden Anzahl von Objekten auch mittels harter Referenzen zu referenzieren (geht, glaub ich, mittels Zuweisung). Die dürfen ja dann nicht mehr freigegeben werden. Damit kannst du genau steuern, wieviele und welche Objekte in jedem Fall im Speicher bleiben (auch "hart" referenziert) und welche bei Bedarf freigegeben werden können (nur weiche Referenz).
Wenn du also 100.000 Objekte nur weich referenzierst und zusätzlich 10 davon auch mit harten Referenzen referenziert, hast du genau das was du willst. Die 10 bleiben dann immer im Speicher. Die kannst du dann bei Bedarf ersetzen (durch eine Zuweisung zu einem anderen/neuen Objekt) und hast so immer den erforderlichen Speicherplatz.

Soweit ich weiss gibt's entsprechende Tags. Da bin ich mir aber extrem unsicher. Vielleicht steht auch was in der API bei der Klasse Applet?

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