# Erstes OOP



## dudu3k (2. Jan 2008)

Hallo die Runde!

Ich habe ein javaprogram struckturiert angefangen und danach das oop hineingeschrieben. wollte mal hören was die werte runde zum ergebnis meint! und es kann sein, dass sich sogar ein fehler im oop befindet. ausserdem stimmt das static noch nicht ganz. Der Code ist auf www.nixphoe.com wenn man auf ShockCfg klickt.

Wünsche allen ein frohes Neues Jahr 2008!!!


----------



## HLX (2. Jan 2008)

dudu3k hat gesagt.:
			
		

> Ich habe ein javaprogram struckturiert angefangen und danach das oop hineingeschrieben.



Bei diesem Satz läuft es mir kalt den Rücken runter.  :autsch:

Gibt es Diagramme dazu?


----------



## Beni (2. Jan 2008)

Okeeee.... *Hände reib, sadistisches Gesicht mach*... dann werf ich mal meine 2 Cents in die Runde:

Allgemein:

Das ist alles ziemlich benutzerunfreundlich. Java 7 runterladen, das Programm selbst kompilieren, im Quelltext die Sprache einstellen... das willst du einem Benutzer zumuten? Selbst ein Java-Programmierer benötigt dafür 30 Minuten.
Hat man die Schritte oben durch, passiert nichts. Sorry, ohne ShockCFG kann dein Programm nicht mal starten? Da ist aber keine saubere Trennung zwischen Daten und Programm drin :wink:

Zum Code:

Mach Packages, damit das Programm übersichtlicher ist.
Verwende JavaDoc, damit das Programm besser verständlich ist.
Das "static" dem OOP-Gedanken widerspricht, hast du selbst geschrieben. 
Solche Dinge:

```
public static JLabel b1,b2,b3,b4,c,b5,b6,b7,b8,b9;
```
... sind nicht gut. Weil es public ist (Information Hiding), weil es static ist, und weil die Namen dieser Labels nichtssagend sind. Werden die überhaupt irgendwo benutzt (ausserhalb der Klasse Citadell)?
Stringvergleiche immer mit equals, auch wenns ohne funktioniert. Besser auf der sicheren Seite.
Aus "Cours":

```
Citadell.c.getText()==ShockCfg.txt.getString("CoursTextOhne")
```

Du gehst allgemein ziemlich liberal mit Informationen um: die Hälfte aller Variablen ist public, GUI-Elemente werden im ganzen Programm verteilt und aufgerufen. Es ist oftmals besser, wenn das Programm unterteilt ist, und die einzelnen Teile ausschliesslich in ihrem Bereich arbeiten. All die "Write" und "Read"-Klassen könnte man abkapseln.
Zu den Write-Read-Klassen: die haben eigentlich so keine Existenzberechtigung. Denn praktisch sind sie lediglich einzelne Methoden. Eine Variante: ReadX und WriteX zu einer Klasse X zusammenfassen, die dann eine Methode "write" und "read" besitzt, und auch gleich all die Einstellungen der X.cfg verwaltet und prüft.
Zu der graphischen Oberfläche kann ich nichts sagen, konnte sie nicht ausprobieren

Weiteres:

Du kennst den Syntax der Sprache, es fehlt lediglich noch der "Feinschliff"
Es ist gut, dass du viele Klassen erstellst, und auch keine Angst hast mal eine "kleine Klasse" (mit wenig Zeilen Code) zu machen. Zuviele Leute versuchen krampfhaft soviel wie möglich in sowenig Dateien wie möglich zu zwängen.
Vielleicht lohnt es sich, wenn du mit den Erfahrungen die du beim Schreiben des Programmes gemacht hast, das Programm nochmal überarbeitest. Mit einer IDE wie Eclipse kann man sehr schnell und einfach Dinge umbenennen und verschieben. Das sog. Refactoring ist eine gute Sache um ein Programm zu verbessern.


----------



## dudu3k (3. Jan 2008)

HLX hat gesagt.:
			
		

> Gibt es Diagramme dazu?



nein gibt es nicht, das kommt als letztes!



			
				Beni hat gesagt.:
			
		

> Allgemein:
> 
> Das ist alles ziemlich benutzerunfreundlich. Java 7 runterladen, das Programm selbst kompilieren, im Quelltext die Sprache einstellen... das willst du einem Benutzer zumuten? Selbst ein Java-Programmierer benötigt dafür 30 Minuten.
> Hat man die Schritte oben durch, passiert nichts. Sorry, ohne ShockCFG kann dein Programm nicht mal starten? Da ist aber keine saubere Trennung zwischen Daten und Programm drin :wink:



Das Program ist ja Opensource, da ist das so.
man muss im Quelltext die sprache nicht einstellen. wenn du die leztzte version benutzt hast, dann wurde die sprache automatisch richtig geladen. ein problem gibt es aber beim laden der cfg dateien wenn man sie nicht besitzt. dieser bug lässt sich aber beheben, wenn man in der RadInstallCfg.java im catch-block die zeile: 
	
	
	
	





```
language ="de";
```
 einfügt!
Was meinst du mit ohne kann man mein Program nicht starten? ShockCfg.java ist die main datei, die braucht man. hab ich da was verpasst?



			
				Beni hat gesagt.:
			
		

> Zum Code:
> 
> Mach Packages, damit das Programm übersichtlicher ist.





ich glaub ich hab schon genug klassen! aber wie würdest du sie einteilen?



> [*]Verwende JavaDoc, damit das Programm besser verständlich ist.



naja die dokumentation steht noch aus!



> [*]Das "static" dem OOP-Gedanken widerspricht, hast du selbst geschrieben.
> Solche Dinge:
> 
> ```
> ...



Du meinst hier die Konsolenoberfläche. bis jetzt ist das nur der geglückte versuch einen courser zum blinken zu bringen, mehr nicht.



> [*]Stringvergleiche immer mit equals, auch wenns ohne funktioniert. Besser auf der sicheren Seite.
> Aus "Cours":
> 
> ```
> ...



ja wie gesagt, die Klasse Citadell verdient noch nicht so viel beachtung, aber danke für den hinweis!



> [*]Du gehst allgemein ziemlich liberal mit Informationen um: die Hälfte aller Variablen ist public, GUI-Elemente werden im ganzen Programm verteilt und aufgerufen. Es ist oftmals besser, wenn das Programm unterteilt ist, und die einzelnen Teile ausschliesslich in ihrem Bereich arbeiten. All die "Write" und "Read"-Klassen könnte man abkapseln.



wie könnte man sie denn abkapseln? und welche bereiche würdest du einteilen? ich denk hier nicht nur an die Reads und Writes, sondern vor allem an die Xerxes!?



> [*]Zu den Write-Read-Klassen: die haben eigentlich so keine Existenzberechtigung. Denn praktisch sind sie lediglich einzelne Methoden. Eine Variante: ReadX und WriteX zu einer Klasse X zusammenfassen, die dann eine Methode "write" und "read" besitzt, und auch gleich all die Einstellungen der X.cfg verwaltet und prüft.



naja, das würde dann aber sehr unübersichtlich werden, vor allem weil der code noch nicht fertig ist und diese dateien noch wachsen werden. also insofern haben sie sehr wohl eine existenzberechtigung denke ich.



> [*]Zu der graphischen Oberfläche kann ich nichts sagen, konnte sie nicht ausprobieren




bearbeite einfach die ReadInstallCfg.java wie beschrieben. du musst ausserdem nicht mal das java 7 runterladen, bis jetzt hat mein program mit allen javaversionen funktioniert. ist halt dann nich opensource...



> Weiteres:
> 
> Du kennst den Syntax der Sprache, es fehlt lediglich noch der "Feinschliff"
> Es ist gut, dass du viele Klassen erstellst, und auch keine Angst hast mal eine "kleine Klasse" (mit wenig Zeilen Code) zu machen. Zuviele Leute versuchen krampfhaft soviel wie möglich in sowenig Dateien wie möglich zu zwängen.
> Vielleicht lohnt es sich, wenn du mit den Erfahrungen die du beim Schreiben des Programmes gemacht hast, das Programm nochmal überarbeitest. Mit einer IDE wie Eclipse kann man sehr schnell und einfach Dinge umbenennen und verschieben. Das sog. Refactoring ist eine gute Sache um ein Programm zu verbessern.



ja, überarbeiten werde ich es bestimmt, mir ist nur noch nicht die einteilung in den Xerxesklassen klar. eclipse verwende ich nicht, mir ist es nicht geglückt mein program zu importieren![/code]


----------



## Beni (3. Jan 2008)

dudu3k hat gesagt.:
			
		

> HLX hat gesagt.:
> 
> 
> 
> ...


Diagramme? Hab ich noch nie gemacht :bae:



> Das Program ist ja Opensource, da ist das so.


Nenene, Opensource bedeutet nur, dass man den Quellcode haben kann; nicht dass man Programmierer sein muss um das Programm zu starten :wink:



> Was meinst du mit ohne kann man mein Program nicht starten? ShockCfg.java ist die main datei, die braucht man. hab ich da was verpasst?


Ich hatte einfach ein paar NullPointerExceptions und das Programm schloss sich wieder.
Mit deinen Tipps habe ich es jetzt zum laufen gebracht. Sieht hübsch aus.



> ich glaub ich hab schon genug klassen! aber wie würdest du sie einteilen?


Hm, Daten (Read-Write) und dann je eines für die Oberflächen?



> naja die dokumentation steht noch aus!


Zu deutsch: sie wird nie geschrieben :bae:
Ernsthaft: ich fand es immer praktisch die Dokumentation noch vor dem Code zu schreiben. Dann überlegt man sich etwas *bevor* man es implementiert, und findet so einige Denkfehler frühzeitig.




> wie könnte man sie denn abkapseln? und welche bereiche würdest du einteilen? ich denk hier nicht nur an die Reads und Writes, sondern vor allem an die Xerxes!?


Z.B. eine Klasse die all die write/read-Operationen, bzw. die Dateien, sammelt. Jetzt scheinen die ja noch überall im Programm aufgerufen und gespeichert zu werden.



> naja, das würde dann aber sehr unübersichtlich werden, vor allem weil der code noch nicht fertig ist und diese dateien noch wachsen werden. also insofern haben sie sehr wohl eine existenzberechtigung denke ich.


Was du zukünftig noch machen willst, weiss ich natürlich nicht. :wink:
Es gibt einige Klassen die 1000e Zeilen Code haben, und nicht unübersichtlich sind. Meistens gilt, solange eine Klasse nur einem Zweck dient, ist sie nicht unübersichtlich.


----------



## Guest (6. Jan 2008)

>Diagramme? Hab ich noch nie gemacht 

gibt es ein program oder ein ebook? noch besser wäre eine webpage oder ein applet!?

>Nenene, Opensource bedeutet nur, dass man den Quellcode haben kann; nicht dass man Programmierer sein muss um das Programm zu starten

ok, ich mach das aus sicherheitsgründen so! ist mir schon unangemehm dass ich noch keinen delphi 4 compiler gesucht hab und der alte bytecode auf meiner hompage steht! kann ja ein rootkit drin sein, meine alte homepage wurde ja auch von der chinesenmafia gehackt!

>>Zitat:
>ich glaub ich hab schon genug klassen! aber wie würdest du sie einteilen?

>Hm, Daten (Read-Write) und dann je eines für die Oberflächen? 

wieso so wenig? mir egal, man kann alles kopieren!

>Zitat:
naja die dokumentation steht noch aus!

ich schreib sie nicht, programmieren ist nur noch mein hobby!  :meld: 

>>Zitat:
wie könnte man sie denn abkapseln? und welche bereiche würdest du einteilen? ich denk hier nicht nur an die Reads und Writes, sondern vor allem an die Xerxes!?

>Z.B. eine Klasse die all die write/read-Operationen, bzw. die Dateien, sammelt. Jetzt scheinen die ja noch überall im Programm aufgerufen und gespeichert zu werden. 

nein nur an zwei stellen! es gibt für jede cfg datei die mit io bearbeitet wird eine eigene klasse, das ist am übersichtlichsten, denn ich weiss noch nicht, wieviele cfgs es gibt, aber es sollen einige sein. die bearbeitung steht noch nicht fest, daher gehe ich davon aus dass sie unterschiedlich sein wird.

>>Zitat:
naja, das würde dann aber sehr unübersichtlich werden, vor allem weil der code noch nicht fertig ist und diese dateien noch wachsen werden. also insofern haben sie sehr wohl eine existenzberechtigung denke ich.

>Was du zukünftig noch machen willst, weiss ich natürlich nicht. icon_wink.gif
Es gibt einige Klassen die 1000e Zeilen Code haben, und nicht unübersichtlich sind. Meistens gilt, solange eine Klasse nur einem Zweck dient, ist sie nicht unübersichtlich.

wenn man eine ide und einen debugger hat, dann ist das sicher so im gegebenen fall. wie wenn ich wüsste das program in eclipse zu importieren, wer weiss!?


----------



## dudu3k (6. Jan 2008)

ups und wieder ich


----------



## Beni (6. Jan 2008)

In Eclipse importieren? Menü "File", dann "New" > "New Java Project" wählen. Weiter mit "Create Project from existing Source", der Rest sollte selbsterklärend sein.


----------



## dudu3k (15. Mrz 2008)

das program gibt es jetzt auf http://www.shockcfg.org

also, für jede cfg-datei des spiels gibt es je eine Read und eine Write! ich könnte noch die jeweiligen reads und writes zusammenfassen, aber das passt schon so, einzelne reads und wries werden doch um einiges grösser! Bioshock wird auch für jede cfg-datei eine read und write haben  aber noch mal zu der idee mit packages, wenn ich für system shock 1 eine konsole schreibe, und für bioshock eine 2d-oberfläche, wie sieht es dann aus?
eclipse brauche ich höchstens zum debuggen, aber ich glaub das bekomm ich auf der konsole auch noch irgendwann hin! ich brauch ja nur den debug befehl und muss wissen wie  man die haltepunkte setzt. das wird dann schon was ausgeben  :autsch: also bin zufrieden mit kwrite!


----------



## dudu3k (22. Mrz 2008)

hm Beni du hast gar nichts zu den Xerxes dateien gesagt, die die oberfläche estellen! sie sind eben struckturiert programmiert. könnte ich sie nicht noch zu einem modell umschreiben, oder abstakt gestallten?


----------

