Sorry, dass ich das so sagen muss, aber: ALLES! Objektiv betrachtet ist daran SO extrem viel SO extrem SCHLECHT, dass ich kaum weiß, was genau ich dazu sagen soll.
Die Klasse arbeitet komplett auf einem Zustand, der public (!) in einer anderen Klasse liegt, nämlich in “Socius”. Der Zustandsraum, der damit aufgespannt wird, ist unmöglich handhabbar. Es existieren hunderte von Konstanten. Praktisch alle dieser if/else-Fälle sind strukturell gleich. Ich bin überzeugt, dass man diese knapp 1000 Zeilen (!) bei geeigneter Modellierung vielleicht in 100 Zeilen unterbringen könnte, und das viel besser, allgemeingültiger, übersichtlicher, verständlicher, leichter anpassbar und leichter erweiterbar.
Ob diese Klasse grundsätzlich etwas anderes macht, als das, was ich in http://forum.byte-welt.net/showthread.php?p=19462#post19462 mit der Methode “doStep” (auch nur) schnell hingeschrieben habe, weiß ich nicht. Aber überleg’ vielleicht mal, ob du etwas hinbekommen kannst, wo
Es ist sehr lang und unübersichtlich, aber das ist nicht so wichtig, weil ich die vielen methoden nicht in der hauptklasse haben wollte, ich werde aber mein bestes tun die ganze sache zu verkürzen
Das ist kein Argument Ich gehe davon aus, dass es nicht so viele (und nicht so lange) Methoden sein müßten, egal, wo sie sehen. Aber ich vermute auch, dass die Aufteilung in Klassen insgesamt etwas zu kurz gekommen ist, wenn man sich die Liste der Fields in der Hauptklasse ansieht. Machen die Methoden denn etwas anderes, als von einem Punkt zum anderen zu laufen?
Inzwischen hab ich weiter gemacht, und jetzt überlagern sich die Items, wenn man jetzt aber in einen anderen Raum geht liegen sie nebeneinander, sehr komisch.Und je mehr man zwischen den Räumen hin und her läuft, desto weiter rückt das Item nach Links vom einen Slot in den Nächsten.
[QUOTE=Marco13]
Die Klasse arbeitet komplett auf einem Zustand, der public (!) in einer anderen Klasse liegt, nämlich in „Socius“. Der Zustandsraum, der damit aufgespannt wird, ist unmöglich handhabbar. [/QUOTE]
Wenn du dich gefragt hast, was ich mit dem „Zustandsraum“ gemeint habe, hast du jetzt die Antwort: Genau SOWAS Irgendwo wird irgendwann irgendeine Variable, die mit der Zeichenposition zu tun hat, immer kleiner. Es wird vermutlich (d.h. fast prinzipbedingt) irgendeine Variable aus der „Socius“-Klasse sein. Objektorientierte Programmierung dient eigentlich dem Zweck, Komplexität handhabbar zu machen, aber das wurde hier wohl noch nicht erreicht. Wenn du mal den akuellen Code (oder das Projekt als ZIP) irgendwo hochlädst, schaut es sich vielleicht jemand an, aber den verwirrten Code von anderen nach Fehlern zu durchsuchen macht i.a. NOCH weniger Spaß, als das bei eigenem Code zu tun…
Wenn es nicht zuuu groß ist, hier im Forum als Anhang. Aber wie gesagt: Wie viel Zeit jemand bereit ist, für die Fehlersuche in fremdem Code zu investieren, ist schwer zu sagen.
Der Link sollte andeuten, dass wenn man fremden Code liest, man sich durch irgendwelche Konstrukte pflügt, von denen man nich weiß, was sie machen sollen.
Mit “Zustandsraum” ist gemeint, dass es eine Menge von Variablen gibt, die den “Zustand” des Spiels beschreiben. Und diese Variablen werde von irgendwo irgendwie geändert. Und im Zweifelsfall weiß man eben nicht, wann sie von wo aus auf welchen Wert geändert werden. Man weiß also nie, in welchem Zustand sich das Spiel gerade befindet.
Bezogen auf dein Problem: Irgendwo muss es ja irgendeine Variable geben, die bewirkt, dass ein Item “nach Links vom einen Slot in den Nächsten” rückt. Und irgendwo muss diese Variable verändert werden, wenn man “zwischen den Räumen hin und her läuft”. Diesen Zusammenhang zu erkennen und etwas zu machen, damit das nicht mehr passiert, ist etwas, was langfristig gesehen nur du selbst machen kannst. (Der erste Schritt dazu ist eben, solche undurchschaubaren Zusammenhänge zu minimieren, aber dazu ist es ja jetzt schon zu spät).
Da es eigentlich nie zu spät sein sollte, um etwas besser zu machen, könnte er, wie ich bereits vorschlug, erst mal ein KSKB erstellen, das die Funktionsweise des Inventars kurz darstellt. So ein KSKB zu erstellen ist zwar nicht leicht, aber nützlich. Er könnte es dann schrittweise erweitern und eventuell Teile der bisherigen Arbeit wiederverwenden, wobei er ständig auf gutes, sinnvolles Design achtet.
Es ist sehr knifflig, es geht um die variable slotsfull[] und die tatsache, dass die berechnungen die ganze zeit durchgeführt werden.Ich versuche das Problem zu lösen, was sich als äusest schwierig darstellt(NullPointerException ohne Grund etc.)
Ohne Grund sicher nicht. Da, wo sie herkommt, ist eine Referenz eben ‘null’. DIE Fehler sind doch eigentlich gutmütig: Draufklicken, und man weiß, wo er herkommt. Besser als unerklärliche falsche Werte oder Race Conditions oder so…
Ich gehe davon aus, dass es nicht so viele (und nicht so lange) Methoden sein müßten, egal, wo sie sehen. Aber ich vermute auch, dass die Aufteilung in Klassen insgesamt etwas zu kurz gekommen ist, wenn man sich die Liste der Fields in der Hauptklasse ansieht. Machen die Methoden denn etwas anderes, als von einem Punkt zum anderen zu laufen? 
