Erste Schritte Aufbau

[19Beat99]

Hallo zusammen
Mich würde wundernehmen wie ich ein Projekt am besten aufbaue. Also ich weis bereits das man dafür am Besten ein UML erstellt. Ich weis auch wie man ein UML erstellt, also wie man Klassen definiert usw. Ich weis jedoch nicht wie ich mein Javaprojekt am besten aufbaue. Also wie viele Klassen soll ich erstellen, welche klasse soll von welcher erben usw. Hat mir da jemand Tipps wie ich das am besten mache oder wo ich gute Lektüre dafür finde?

 

[M.L.]

Auch hallo,

die beste Lösung hängt vom vielen Faktoren ab... Aber siehe den Beitrag von https://www.java-forum.org/thema/wi...vernuenftige-klassen-ein.185926/#post-1197005 . Weiters könnte ein Framework wie z.B. Spring Boot bereits eine Grundstruktur vordiktieren.

 

[TM69]

Hallo zusammen

• Mich würde wundernehmen wie ich ein Projekt am besten aufbaue. Also ich weis bereits das man dafür am Besten ein UML erstellt. Ich weis auch wie man ein UML erstellt, also wie man Klassen definiert usw. Ich weis jedoch nicht wie ich mein Javaprojekt am besten aufbaue. Also wie viele Klassen soll ich erstellen, welche klasse soll von welcher erben usw. Hat mir da jemand Tipps wie ich das am besten mache oder wo ich gute Lektüre dafür finde?

Die beste, wie ich finde, Vorgehensweise ist indem du dir erstmal klar darüber wirst, was dein Projekt genau machen soll. Notiere dieses am besten in Sätzen

- Für wen (soll die Funktion sein)
- Für was (soll die Funktion dienen)
- Welchen Nutzwert hast du davon

Dieses bildet in der IT ein User Story.
Dann sortiere diese am besten in der Reihenfolge (absteigend) welches dir am schnellsten du mit (z.B. Geld) generien kannst. In der IT spricht man dieses bezüglich auch von einem Product Backlog. (http://www.produktmanager-blog.de/backlog-user-story-und-co-die-halbe-miete-fuer-agile-sprints/)

 

[TM69]

Nachtrag:
UML kann richtig eingesetzt dir einen Überblick verschaffen. Allerdings bedenke, dass du durch erzeugen von Dokumenten, kein z.B. Geld generierst.
Aus diesem Grund ist einer der Leitsätze in der, heutig gängigen Vorgehensweise, aus dem agilen Manifest (https://agilemanifesto.org/iso/de/manifesto.html)

Funktionierende Software ist wichtiger als umfassende Dokumentation

und wenn du, nicht disziplinierst arbeitet, verhedderst du dich ganz, ganz schnell darin, dass du mehr Arbeit ins erstellen von UML steckst, als in der Erstellung von funktionierender Software.

 

[MoxxiManagarm]

Also wie viele Klassen soll ich erstellen, welche klasse soll von welcher erben usw.

Wenn es um die Objektorientierte Modellierung geht, dann versuch es möglichst domain-nah nachzubilden. Besonders wichtig sind dabei die Begriffe "hat ein" (Composition) und "ist ein" (Inheritence). Außerdem kannst du weitestgehend Verben in deiner Modellierung als Methoden abbilden. Dabei ist die Frage wer macht was und wen oder was benötigt er dafür.

 

[TM69]

Noch etwas zum Thema:

Ich weis jedoch nicht wie ich mein Javaprojekt am besten aufbaue. Also wie viele Klassen soll ich erstellen, welche klasse soll von welcher erben usw. Hat mir da jemand Tipps wie ich das am besten mache oder wo ich gute Lektüre dafür finde?

Wenn du mit UML arbeitst, denke daran, dass Klassen ein Substantiv beschreibt.
z.B.

class Auto {
    public void bremsen();
    public void anfahren();
    ....
}

Die Funktionen beschreiben hingegen Verben, die auf das Substantiv (ich nenne es mal) Verbindung stehen.
Zu den Funktionen noch ein Wort. Im Software Engineering benutzt man das, von Onkel Bob, veröffentlictte SOLID Prinzip. (https://martinfowler.com/articles/dipInTheWild.html). SOLID ("Single Responstiblity", "Open-Closed", "Liskovsche Substitution, Interface Segregation und Dependency inversion) dient der höhren Wartbarkeit, Testbarkeit und Anpassung bzgl. Hinblick auf spätere Veränderungen).
Kurz zusammengefasst:
- S = eine Funktion sollte nur eine Aufgabe erfüllen (nicht mehrere)
- O = entwickle deine Funktionen so, dass die Klasse, Methoden und Module einfach zu erweitern sind, ohne das ihr Aufgabe verändert wird
- L = eine geerbte Subklasse sollte immer die Aufgaben der Funktionen der Superklasse erfüllen
- I = lasse Interfaces nicht zu groß werden
- D = hierachie der Funktionen. D.h. Funktionen, die andere Funktionen, die wiederum andere Funktionen, .... aufrufen werden je spezifischer desto tiefer du in hinabsteigst.

So ich hoffe ich konnte dich mit dem Wissen erschlagen

 

[White_Fox]

Ich würde noch dazu raten, sich gewisse Kniffe anzueignen.

Befasse dich mal etwas mit Entwurfsmustern, das ist sehr erhellend und macht OOP sehr viel verständlicher.

 

[LimDul]

Ich kann meinen Vorrednern größtenteils zustimmen.

Ich halte es nicht für sinnvoll oder zielführend ein UML der Klassen als ersten Schritt zu malen. Das führt zu nichts außer so einer Tapete, die am Ende nix mehr mit dem dann umgesetzen Code zu tun hat.

Das wichtigste ist, eine klare Struktur im Programm zu haben auf allen Ebenen - dabei kann UML helfen diese Struktur zu visualisieren, aber dann bitte jeweils in einem angemessenen Detailgrad. Denn ein zu hoher Detailgrad ist keine hilfreich Visualisierung mehr sondern nur noch ein unlesbares Diagramm.

Struktur heißt z.B.
- Welche fachlichen Komponenten hat dein Programm, wie kann man die Trennen?
- Welche Ebenen gibt es im Programm (UI, Fachlogik, Schnittstellen, etc.)
- Wie hängen die alle zusammen, wer kennt wenn (Hier sollte man z.B. tunlichst zirkuläre Abhänigkeiten vermeiden)

und für da alles kann man UML zum visualisieren nutzen.

Die Klassen kommen dann als letzter Schritt am Ende relativ natürlich raus - dadurch, dass du dein Programm schon in kleine Teile zerhackt hast, weißt du was du in dem jeweiligen Teil umsetzen willst - und dann legst du entsprechend Klassen einfach an. Wenn es mal komplexere Dinge sind (kommt in der Regel auf der Ebene des Modells vor), dann kann man wieder ein UML malen wo man die Klassen abbildet - aber auch hier - im angemessenen Detailgrad.

Das Ziel sollte nicht sein, dass das UML am Ende nochmal genau deinen Code beschreibt. Sondern das UML soll so sein, dass man sich im Code hinter zurechfindet und die Konzepte, die dahinter stehen im Code, versteht.