Klassen trennen zur verbesserung der Übersicht?

[Guest]

Hallo,

ist es eine gute oder schlechte Idee aus Sicht der OOP sein Programm in unnötig viele Klassen zu zerstückeln um den Code schlanker und übersichtlicher zu gestalten oder birgt das ein zu hohes Risiko darauf, dass man sich den Weg zu evtl zukünftigen Modulen verbaut?

Ich habe selbst noch ein paar Probleme damit die Objektorientieren Gedanken immer nachvollziehen zu können, da ich noch JAVA-Neuling bin.

Folgendes Beispiel:

Ich habe ein Programm das einen simplen JFrame enthält und andere simple Dinge die den Code aber leicht sehr lang wirken lassen. Ist es gut für den JFrame eine eigene Klassen-Datei zu erstellen und ihn somit von der der Main-Methode zu trennen?

Weitere Elemente. Als andere Elemente kann ich mir zb Koordinaten, Configs, Dialoge, Zeichnungs-Methoden, Timer... vorstellen. Darf/kann ich in Java zukünftig bedenkenlos alles zerstückeln?

Gruß

 

[Wildcard]

Objektorientierung soll das echte Leben abbilden. Ein Auto ist ein Objekt. Ein Auto setzt sich aber wiederum aus weiteren Objekten zusammen. Lenkrad, Räder, Motor,...
Wie granular man aufteilt hängt von der Problemstellung ab, aber so als Faustregel haben Klassen selten mehr als 1000 Zeilen und eine Methode sollte auf einen Bildschirm passen.
Die main Methode ist übrigens in der Regel mit 1-5 Zeilen erledigt, der Rest läuft objektorientiert ab.

 

[Guest]

Naja die Frage ist jetzt ob ich das Lenkrad nochmal unterteile in Form, Hupe, Schraube, Airbag :?:

Das die Main nur aus 1-5 Zeilen besteht hat mich um ehrlich zu sein schon geschockt xD Meine erste Java-Anwendung hatte min 30 :lol:

Danke für deine Tipps

 

[Wildcard]

Pauschalaussagen sind schlecht möglich (mit Ausnahme von: Neue Klasse, dort wo es Sinn macht).
Etwas Erfahrung gehört dazu, dann geht's automatisch. Ein Buch über Designpatterns schadet allerdings keinesfalls.

 

[maki]

st es eine gute oder schlechte Idee aus Sicht der OOP sein Programm in unnötig viele Klassen zu zerstückeln

"Unnötig" viele Klassen sind sicher keine gute Idee.

Naja die Frage ist jetzt ob ich das Lenkrad nochmal unterteile in Form, Hupe, Schraube, Airbag icon_question.gif

Brauchst du denn eine Form, eine Hupe, Schraube, etc. pp.?
Wenn nicht, sind sie unnötig.

ZB: Eine Anwendung zum Verwalten von Parkplätzen in einem Parkhaus braucht so etwas bestimmt nicht

 

[Gast]

Angenommen ich 'programmiere' tatsächlich ein Auto, dann unterteile ich das Auto in seine Hauptbestandteile. Gas, Bremse, Lenkrad, Motor, Tank.

Jetzt ist das problem das ich wieder in mein struckturiertes denken hineinfalle. Erst muss ich tanken denn ohne tank geht der motor nicht wenn der motor erstmal läuft kann ich auch gas geben. Bremsen macht keinen Sinn wenn ich nicht vorher gas gegeben habe.

Wie ist das beim OOP? Die Objekte bestehen als co-existenzen doch können bestimmte objekte doch nciht ohne andere existieren. Also habe ich wieder diese Schrittfolge: erst das dann das dann das dann das.. wenn ich das erste nicht gemacht habe geht das zweite nicht. Wie in einem Flussdiagramm

 

[Wildcard]

Flussdiagram böse :wink:

 

[Gast]

Hallo ,

Beginn der Predigt ....

Wenn man Java kann, kann man noch lange nicht OO oder anders ausgedrueckt OO ist nicht gleich Java.

Sprich in Java kannst du genauso imperativ programmieren, wie in anderen Sprachen ebenso kann man in Imperativen Sprachen die OO nachbilden.

Also wenn du die OO verstehen moechtest dann solltest du nicht NICHT damit anfangen Hello World in Java zu programmieren, sondern vielleicht ein paar gute OO Buecher lesen.

Beispiel:

Analyse und Design mit UML2 von B. Oestereich (Dort bekommst du einen ersten Einblick in UML und OO)

Desweiteren sind die schon erwaehnten DesignPattern absolut notwendig fuer anspruchsvolle Softwareentwicklung. Aber auch dort gilt die Pattern sind unabhaengig von Java.

Ende der Predigt ...

Zusammenfassung es ist immer wichtig und entscheidend die Konzepte zu verstehen und nicht zu erst das Werkzeug mit denen die Konzepte umsetzen kann.

 

[Beni]

Hallo

ist es eine gute oder schlechte Idee aus Sicht der OOP sein Programm in unnötig viele Klassen zu zerstückeln um den Code schlanker und übersichtlicher zu gestalten

Wenn der Code schlanker und übersichtlicher wird, dann sind das keine unnötigen Klassen :wink:
Wenn der Code komplizierter und unübersichtlich wird... naja, hoffentlich gewinnst du noch irgendetwas wie z.B. "Flexibilität", sonst machst du was falsch.

oder birgt das ein zu hohes Risiko darauf, dass man sich den Weg zu evtl zukünftigen Modulen verbaut?

Normalerweise sind wenige grosse Klassen ein grösseres Hindernis für Module. Aber solange du keine Library schreibst, solltest du dir nicht allzuviel (!= keine) Gedanken über wiederverwendbare Module machen. Erfahrungsgemäss werden echte Programme so gut wie nie wiederverwertet.

 

[fehlerfinder]

Jetzt ist das problem das ich wieder in mein struckturiertes denken hineinfalle. Erst muss ich tanken denn ohne tank geht der motor nicht wenn der motor erstmal läuft kann ich auch gas geben. Bremsen macht keinen Sinn wenn ich nicht vorher gas gegeben habe.

All dies kannst du prima in Attribute packen und mit entsprechenden Methoden darauf zugreifen. So muss z.B. eine Methode "motorStarten()" prüfen, ob Benzin im Tank ist

Auto meinAuto = new Auto();
Tank meinTank = meinAuto.getTank(); // um die Referenz auf den zu meinAuto gehörenden Tank zu bekommen
if (meinTank.istBenzinImTank())
{
    meinAuto.motorStarten();  // du könntest hier evtl. besser auf ein zusätzliches Motor-Objekt zugreifen
}
else
{
    System.out.println("Geh mit einem Benzinkanister zur Zapfsäule");
}