OOP Problem - Wie Einarbeiten?

[herrpink]

Hi.
Mein Problem ist, dass ich schon länger in Python, C oder C++ programmiert habe, aber mir kaum Gedanken über den Stil gemacht habe. Weil Java zwangsläufig ja OOP-orientiert ist, fange ich allerdings jetzt damit an.
Die Grundlegenden Konzepte verstehe ich, aber hapert es dann bei der Umsetzung.
zB wenn ich ein Schach-Spiel, Chat-Programm o.ä. entwerfen will, fallen mir nicht immer "gute" Klassen usw. ein, die das Programmieren strukturiert machen.
Also meine Frage, sollte ich es einfach weiter versuchen und so gewöhnt man sich dann diesen "Stil" an? andere Vorschläge?

mfg
pink

 

[ARadauer]

fallen mir nicht immer "gute" Klassen usw. ein,

eine gute Übung ist, das Programm einfach mal als Text beschreiben und die Nomen unterstreichen... das sind mal gute Kandidaten für Klassen, die verben wären gute Kandidaten für Methoden...
Natürlich heitß "guter Kandidat" nicht, dass es genau die sind, aber es ist schon mal eine Richtung.

 

[0x7F800000]

eine gute Übung ist, das Programm einfach mal als Text beschreiben und die Nomen unterstreichen...

Und was mach ich wenn ich analphabet bin?! :bahnhof:

 

[Noctarius]

Und was mach ich wenn ich analphabet bin?! :bahnhof:

loooooooooool ^^

 

[tfa]

Der Tipp von ARadauer ist gut. Trotzdem wirst du das nur durch Übung lernen.
Das 100%ig passende Klassenmodel kann man sowie nicht auf dem Reißbrett entwerfen. Es wird sich im Laufe des Projekts eh noch verändern und anpassen. Das ist auch nicht weiter schlimm.

Und was mach ich wenn ich analphabet bin?! :bahnhof:

Dann gehst du hier hin.

 

[Noctarius]

Joar man erwischt niemals alle Anforderungen im Vorfeld (leider)

 

[maki]

Joar man erwischt niemals alle Anforderungen im Vorfeld (leider)

Lemmingmodelle wie das Wasserfallmodell oder dessen Nachfolger, das V-Modell sind leider noch nicht auf den Trichter gekommen..

Da sind Agile Vorgehen schon ganz anders aufgestellt: "Embrace Change!"

Aus XP zB. kommt TDD -Test Driven Development, da heisst es zuerst den den Test, danach die Implementierung.
So wird Testen zur Designaktivität.

 

[hdi]

Ich bring da immer dieses Bsp:
Programmieren ist wie Schach spielen. Jeder kennt die Regeln nach 10 Minuten,
aber keiner gewinnt in den ersten Jahren gegen einen einigermassen guten Spieler.

Auf deutsch: Dein Problem ist kein Anfängerproblem, und auch kein Fortgeschrittenen-Problem.
Eigentlich hat sogar jeder Experte damit ein Problem, im Sinne davon dass dies nun mal
die wahre Schwierigkeit am Programmieren ist.

Jeder kriegt wohl fast alles irgendwie hin. Es gut zu machen, ist halt was anderes.

Ich empfehle dir 2 Dinge:

1) Programmier soviel du kannst.
Mach deinen Chat-Programm doch mal, einfach nur dass es funktioniert.
Am Ende sieht du den fertigen Code, und dann kannste es neu machen.
Weil der Code vor dir liegt kannst du sehen wo du Probleme kriegen könntest mit
einem gewissen Design, bzw. was du schöner coden könntest.

2) Google oder such dir Bücher über "Design Pattern".

Beides funktioniert übrigens nur im Zusammenhang mit dem jeweils anderem.

 

[Mostly_Harmless]

Dann gehst du hier hin.

:lol:
Die Seite ist ja richtig fies, fast so, als würde man einem Tauben diesen Link schicken.

 

[hdi]

Das ist aber echt mal ne Verarsche

"Partizipieren Sie am Interdisziplinären Workshop".

Das ist ja selbst für Alphabetisten (?) harter Tobak

 

[0x7F800000]

Naja, die seite ist ja wohl auch eher für "Freunde und Verwandte" gedacht, wenn man in der Klapsmühle abgeliefert wird, muss man sich ja auch nicht um papierkram kümmern, genauso ist das wohl bei Analphabeten und dieser Seite...

Hey Leute, sorry für Offtopic, lassen wir das, okay?

 

[herrpink]

vielen dank für die ganzen Antworten!
mfg

 

[0x7F800000]

damn it, jetzt bin ich hier dafür verantwortlich, dass der ganze thread mit offtopic-müll gefüllt wurde^^ tschuldigung

 

[maki]

vielen dank für die ganzen Antworten!
mfg

Naja, wenn dir die schon reichen (mal von dem ganzen offtopic abgesehen)

Wie wäre es mit 2 Dingen:
- Refactoring, damit kannst du das Design des Codes ändern, ohne die funktionalität zu ändern
- Unittests, damit Refactoring nicht zu einem Spiel mit dem Feuer wird