Fachrat Informatik - Forum

Wie wär's mit einer Übung zu Reflectios? (:

Naja.... viele Übungen werden es wohl kaum noch werden... Selbst bei 2 Übungen müssten wohl die letzten nach der Klausur vorstellen. Macht das wirklich sinn?

Quoted

Ich hatte damit zwar keine Probleme, als ich das ausprobiert habe, aber bitte, eine Version mehr kann ja nicht schaden. Im übrigen ein interessantes Beispiel dafür, was passiert, wenn man einen Modifier vergisst: durch das fehlende public ist der oben angesprochene Konstruktor implizit "package", also nur innerhalb des Packages sichtbar (was ja grundsätzlich kein Problem wäre, wenn man hier nicht versucht hätte, die main-Klasse aus dem Package zu rupfen - meiner Meinung nach übrigens nicht unbedingt nötig; denke, das ist Ansichtssache). Den Hinweis mit den Umlauten werde ich ab sofort berücksichtigen.

Ich denke schon, dass das Sinn macht. Welcher Anwender eines Programms will schon gerne die einzelnen Lib-Verzeichnisse durchsuchen, bis er seine Programmdatei zum Ausführen findet. Daher ist es eigentlich Standart, dass man seine main-Methode auch da ablegt, wo sie hingehört und nicht versteckt in irgendwelchen Packages. Zudem sind Packages, wie schon gesagt, dafür da um Quellcode möglichst gut wiederverwendbar zu machen und nicht um die Hauptklasse darin zu verstecken.
Aber wie dem auch sei, die Version, die ich gepostet habe, sollte weniger Probleme machen beim Compilieren machen. Wenn man die Originalversion compilieren will (Auf der Konsole) sollte man es am besten aus dem Verzeichnis tun, in das man die Dateien entpackt hat (javac simulation/implementions/SimulatorApplikation.java) oder man setzt den Classpath (javac -classpath ..\..\ SimulatorApplikation.java, bzw. Unix: javac -classpath ../../ SimulatorApplikation.java).

Oder man nimmt gleich seine Lösung zur letzten Aufgabe .

Quoted

Original von neweb
naja... eine Main gehört definitiv nicht in ein Package. So sind Packages nicht gedacht. Packages sind für die Wiederverwendung von Code eingeführt worden.

Packages sind zur Strukturierung des Programmes eingeführt worden. Dies kann Wiederverwendung fördern, aber auch alleine schon die Übersicht erleichtern/ermöglichen. Ich würde niemals(!!!) das default-Package benutzen und auch eine "Main-Klasse" in ein projektspezifisches Verzeichnis tun. Die Namenskonvention für Packages ist ja zuerst die umgedrehte Domain, also z.B.

de.uniHannover

dann nehme ich normalerweise den Projektnamen, also z.B.

de.uniHannover.meinProjekt

und darin liegt dann gleich die Main-Klasse, sofern es nur eine gibt, also

de.uniHannover.meinProjekt.Main

oder wenn man mehrere hat dann die auch getrennt in verschiedene Packages:

1. de.unihannover.meinProjekt.client.Main
   
2. de.unihannover.meinProjekt.server.Main
   [/list=a]
   
   Alle anderen Logikklassen liegen nicht in diesen "Hauptpackages"!
   
   

   Quoted

   Eine Main verwendet man normalerweise so nicht wieder. Ansonsten baut man eine Unterklasse, in der die Dinge liegen, die wiederverwendet werden sollen.

   
   
   Wovon soll das eine Unterklasse sein? Rest s.o.
   
   

   Quoted

   Zudem sollte ein Konstruktor immer public sein!
   
   

   Quoted

   
   SimulatorApplikation.java:17: Simulator() is not public in implementation.Simulator; cannot be accessed from outside package
   Simulator meineSimulation = new Simulator();
   ^
   1 error
   
   

   
   
   Konstruktoren sollen niemals einfach immer nur public sein! Sie sollen dann (und nur dann) public sein, wenn sie von ausserhalb des aktuellen Packages aufgerufen werden. Ansonsten reicht auch default- oder protected-Sichtbarkeit. Gerade im Verbund mit Factories u.ä. kann es manchmal viel mehr Sinn machen, dass eine Klasse nicht instanziierbar ist. Oder private-Konstruktoren für statische Hilfsklassen und Singletons. Leider verlangen viele Frameworks und APIs, dass es einen public Default-Konstruktor gibt. Dies macht leider den Code unsauberer. Dennoch sollte man sich überlegen, unter welchen Umständen es Sinn macht, dass Konstruktoren über Paketgrenzen hinweg aufgerufen werden, da damit zwei Pakete fest aneinander gebunden sind (schlechtes Coupling). Dies unterläuft dann auch Deine Wiederverwendbarkeitsgedanken :-)
   In dem angegebenen Ausschnitt muss der Konstruktor wohl public sein aus dem genannten Grund, aber d.h. auch, dass das SimulatorApplikation-Package (= das Package, wo SimulatorApplikation drin ist) nicht ohne das Simulator-Package auskommt und (wieder)verwendet werden kann.
   
   Grüße,
   Daniel

Quoted

Original von neweb
Oder man nimmt gleich seine Lösung zur letzten Aufgabe .

Hrmpf, das wollte ich gerade machen, aber wenn man Aufgabe 9 so verstanden hat, dass man nur _allgemein_ das Framework für eine Simulation (und ein beliebiges Testprogramm) schreiben soll, dann geht der Plan nicht auf. Ich hab weder ein IEreignis, noch Ankunfts- und Abgangsklassen, und einen BasicSimulator schon gar nicht. Da müsste ich die Aufgabe schon ganz schön frei interpretieren :/

Quoted

Original von neweb
Welcher Anwender eines Programms will schon gerne die einzelnen Lib-Verzeichnisse durchsuchen, bis er seine Programmdatei zum Ausführen findet.

Um dieses Problem zu umgehen, gibt es ja glücklicherweise JAR-Dateien.

Hi Leute,
ich hab da so ein Problem, und zwar kieg ich eine Exception, die ich mir nicht wirklich erklären kann. Diese tritt entweder am Anfang, Ende oder ziemlich genau in der Mitte der Simulation auf. Vielleicht weiß ja jemand rat:

Quoted

Simulationszeit: 30,63 Laenge der Warteschlange: 3
Simulationszeit: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at simulation.implementation.EreignisArray.naechstesEreignis(EreignisArray.java:106)
at simulation.implementation.Simulator.run(Simulator.java:76)
at simulation.implementation.SimulatorApplikation.main(SimulatorApplikation.java:19)
32,11 Laenge der Warteschlange: 2
Simulationszeit: 33,12 Laenge der Warteschlange: 3

Danach läuft die Simulation ohne Probleme weiter und der Abbruch funzt dann auch....

Gruss
Florian

Quoted

Konstruktoren sollen niemals einfach immer nur public sein! Sie sollen dann (und nur dann) public sein, wenn sie von ausserhalb des aktuellen Packages aufgerufen werden. Ansonsten reicht auch default- oder protected-Sichtbarkeit.

Okay... es ging mir auch eher darum, dass man nicht komplett auf Modifier verzichtet. Klar... alles, was man von außen nicht nutzt sollte gekapselt werden.

Der Eclipse-eigene Debugger findet an der Stelle nichts, was nicht rechtens sein soll. Außerdem benutze ich die Musterlösung, und an der entsprechenden Stelle findet nichts anderes statt, als dass der Array-Index um 1 heruntergesetzt wird. Nur findet dieser Fehler meist mitten in der Ausgabe statt, und dann geht es ohne Probleme weiter...als wenn da ein Loch im Array existiert.