Programmaufbau

[bernd]

Hallo...

Mich würde mal interessieren wie ihr bei der Programmierung von Programmen so vorgeht?

Was macht ihr als erstes? Erst die benötigten Klassen erstellen oder erst die GUI oder wie?
Was ist eurer Meinung nach der beste Weg?
???:L

 

[Sky]

1. Analyse (= was soll überhaupt gemacht werden)
2. Klassenmodell erstellen (= welche Klassen werden benötigt und wofür)
3. Klassen erstellen

P.S.: Die GUI sind bei mir auch Klassen Die Erstellung der GUI-Klassen erfolgt bei mir vor der Erstellung der Listener/Controller-Klassen

 

[bygones]

wenn was schnell geproggt werden muss und es auf aufbau nicht ankommt - dann fang ich einfach ala "quick & dirty" ansatz an zu schreiben (also einfach drauf los)....

ansonsten ist skys ansatz völlig richtig.
1. Analyse = was ist das Problem, was will ich und was soll rauskommen

2. Modelle erstellen - UML, TestCases, Szenarios und Struktur
(bis hierhin braucht man noch keinen Code zu schreiben...)

3. Programmieren....

Bei einer GUI halte ich den Weg: Model - View- Controller am besten, da Model Klassen meist einfach und schnell zu schreiben sind. Die View Ebene ist je nach Anspruch schnell gemacht und dann das Komplexeste - dier COntroller....

 

[Bleiglanz]

ich selber krieg den Koller wenn ich ein UML Diagramm zeichnen muss oder einen Use Case beschreiben soll, wenns irgendwie geht

0. Ein leeres GUI entwickeln, mit Schaltflächen die nichts bewirken usw. -> dem Kunden vorlegen und nochmal über die Funktionalität reden (da kommt dann oft mehr dabei raus, als bei einer schriftlichen Spec).

1. Wild drauf los Programmieren, damit man ein Gefühl für die Probleme bekommt und ein paar Methodenrümpfe schon fertig hat

2. Analyse / Modellierung

3. TestCases für die Teile aus 1) die brauchbar erscheinen

4. Von vorne Anfangen, dabei Implementierung und TestCases gleichzeitig erstellen

 

[abollm]

Vom theoretischen Standpunkt aus ist die Vorgehensweise von deathbyaclown/sky80 ein richtiger Ansatz. In der Praxis ist es häufig günstiger so vorzugehen, wie Bleiglanz skizziert hat. User Requirements, UML-Diagramme, ausführliche schriftliche Spezifikationen etc. lesen in der überwiegenden Mehrzahl ohnehin nur Fachleute und keine Endnutzer.

Daneben sollte man nicht zu spät an die Dokumentation des Programms denken, also Programmhilfe, Handbuch und natürlich Dokumentation des Codes (Javadoc etc.).

 

[Beni]

Ich arbeite nicht halb so professionell wie die dbac und sky80... bei meinem aktuellen Projekt (derzeit 250 Klassen & Interfaces, und funktionierend :wink: ) arbeite ich nach folgendem Schema:

* Solange es ungelöste Probleme gibt
|  Überschlafe das erste Problem einmal
|  Schreib mal eine graphische Oberfläche die zu dem Problem passt
|  Zeichne ein paar Icons zur Oberfläche
|
|  Den Quellcode zu all den Algorithmen und Datenstrukturen schreiben, welche benötigt werden.
|  Das Programm starten
|  * solange es Exceptions gibt
|  |   Die Exception auf die eine oder andere Variante eliminieren
|  -
-

Mit UML und etc. habe ich mich noch nie aufgehalten, was nicht in meinen Kopf passt, ist falsch designed.

Dafür schreib ich praktisch immer gleich die Doku, die Erfahrung zeigt, dass das wirklich keine verschwendete Zeit ist...

Ach ja, auch wenn dies die sogenannte "try & error"-Methode ist, sie funktioniert, solange man die Probleme in klar überschaubere Unterprobleme teilen kann.

 

[Illuvatar]

Ich arbeite nicht halb so professionell wie die dbac und sky80... bei meinem aktuellen Projekt (derzeit 250 Klassen & Interfaces, und funktionierend :wink: ) arbeite ich nach folgendem Schema:

* Solange es ungelöste Probleme gibt
|  Überschlafe das erste Problem einmal
|  Schreib mal eine graphische Oberfläche die zu dem Problem passt
|  Zeichne ein paar Icons zur Oberfläche
|
|  Den Quellcode zu all den Algorithmen und Datenstrukturen schreiben, welche benötigt werden.
|  Das Programm starten
|  * solange es Exceptions gibt
|  |   Die Exception auf die eine oder andere Variante eliminieren
|  -
-

Mit UML und etc. habe ich mich noch nie aufgehalten, was nicht in meinen Kopf passt, ist falsch designed.

Dafür schreib ich praktisch immer gleich die Doku, die Erfahrung zeigt, dass das wirklich keine verschwendete Zeit ist...

Ach ja, auch wenn dies die sogenannte "try & error"-Methode ist, sie funktioniert, solange man die Probleme in klar überschaubere Unterprobleme teilen kann.

So in der Art mach ichs auch

 

[Roar]

ack

 

[Bleiglanz]

kleine Bemerkung noch dazu:

Es ist auf jeden Fall empfehlenswert, sich frühzeitig mit den Refactoring Methoden der neueren GUIs vertraut zu machen (IDEA, Eclipse)!

Damit ist es relativ simpel, sein ganzes "Design" völlig umzukrempeln und neu zu strukturieren, ohne dass man gleich ganz von vorne anfangen muss. IMHO braucht man heutzutage nicht mehr tagelang über einen "OO Entwurf" zu grübeln, den man dann später eh nicht so umsetzen kann

Auch das Refactoring-Buch von Fowler ist für "fortgeschrittenere" Programmierer lesenswert (selten bei einem Computer-Buch)

 

[bygones]

scheinbar bin ich noch von der alten schule - aber ich will vorher wissen was ich implementiere !
Trotz der Refactormöglichkeiten der IDEs habe ich keine Lust draufloszuhämmen und nach zig Zeilen Code zu sehen dass es schwachsinnig und neu gemacht werden muss...

Auch wenn die UML Diagramme auch während der Entstehungszeit des Programms abgeändert werden will ich eine Übersicht von dem haben das ich mache !

 

[Bleiglanz]

scheinbar bin ich noch von der alten schule - aber ich will vorher wissen was ich implementiere !

will ich auch, oft wissen es aber die Auftraggeber selbst nicht genau

habe noch kein Pflichtenheft gesehen, aus dem man einen vernünftigen Softwareentwurf extrahieren könnte

 

[bygones]

scheinbar bin ich noch von der alten schule - aber ich will vorher wissen was ich implementiere !

will ich auch, oft wissen es aber die Auftraggeber selbst nicht genau

klar - für jemanden zu schreiben der es selbst noch nicht weiß erschwert die vorbildliche Arbeit imens :wink:
ich habe bis jetzt immer für mich bzw. für Leute programmiert die sagten: "Das soll rauskommen, mach es gut und wie ist dir überlassen".... aber z.b. werde ich gewiss nicht meine DP Arbeit schreiben ohne nicht ein UML diagramm zu zeichnen....

 

[L-ectron-X]

Ich habe das auch mal so ähnlich gelernt wie deathbyaclown. Allerdings tendiere ich heute dazu, wild drauflos zu programmieren und während des Programmierens alles oder teilweise einige Methodenimplementierungen über den Haufen zu werfen.
Spätestens dann nehme ich mir mal Zettel und Bleistift in die Hand und skizziere zumindest den Pseudocode.
Meistens ist die Vorgehensweise bei mir aber vom Umfang des Programmes abhängig.