Interaktion von Objekten verschiedener Klassen...

[fhs14647]

Werte Java Profis
Ich habe eine Sache, bei der ich in Java nicht ganz durchblicke. Konkret ist es die Interaktion von Objekten verschiedener Klassen. Konkret geht es, glaube ich, um Aggregationen, also das Einbauen von komplexen Objektvariablen in Klassen. Wenn ich mehrere Klassen habe und diese in der public static void main instanziiere, ist für mich alles logisch. Wann ich aber bei einem Klassenkonstruktor andere komplexe Datentypen als Parameter mitübergeben muss, wann ich im Konstruktor direkt ein Objekt instanziieren muss, das ist sehr verwirrend für mich..

Meine Fragen: wer kennt hier ein gutes, verständliches Tutorial, bei der genau diese Thematik erklärt wird.

Vielleicht ein Beispiel: es sollen die Klassen Lehrer, Unterrichtsfächer, Schüler und Schulklassen angelegt werden. Mit einem Lehrer wird auch dessen Unterrichtsfach angelegt, mit dem Schüler wird auch dessen Schulklassen angelegt. Wie würde man so was machen??

Danke vorab
FHS

 

[Xyz1]

Ein Klassendiagramm wäre hier hilfreich...

    public static void main(String[] args) {
        List<Schueler> schueler = new ArrayList<Schueler>();
        schueler.add(new Schueler());
        List<Lehrer> lehrer = new ArrayList<Lehrer>();
        lehrer.add(new Lehrer());
        Schulklasse sk = new Schulklasse(schueler);
        Unterrichtsfach uf = new Unterrichtsfach(lehrer);
    }

hoffentlich verwechsele ich nix mit Aggregation.

 

[Baldur]

Ein Tutorial kann ich spontan nicht nennen, aber ich würde dir empfehlen, Klassen und vor allem deine Konstruktoren so wenig komplex wie möglich zu machen.

Hast du dich denn schonmal mit Datenbanknormalisierung auseinandergesetzt? Dabei gehts auch darum, die Komplexität einzelner Tabellen zu minimieren und auf das Wesentliche zu reduzieren. Das wäre für den Anfang ein sinnvoller Schritt, und im Anschluss kannst du, wie DerWissende vorschlägt auch ein Klassendiagramm draus machen, um dir das alles besser vorstellen zu können.

Der Konstruktor für z.B. die Lehrer-Klasse sollte dann auch nur das allernötigste bekommen, sprich z.B. den Namen. Alles andere sollte im Nachhinein per setter-Methoden übergeben werden. Wenn nämlich der Konstruktor von einem Unterrichtsfach den Lehrer braucht, der das Fach hält, der Lehrer aber auch eine Liste all seiner Fächer im Konstruktor haben will, dann hast du ein Problem, weil du keins der Objekte ohne das andere erstellen kannst. Das Problem würdest du lösen, wenn du erst die Objekte alle anlegst, und sie später z.B. mit lehrer.addFach(geschichte); verknüpfst.

 

[Xyz1]

Das stimmt. Ein Unterrichtsfach beinhaltet Lehrer; eine Schulklasse beinhaltet Schüler. Wenn da "Zyklen" beinhaltet sind, wird's sehr kompliziert.

Ein Lehrer könnte aber auch Unterrichtsfächer beinhalten; ein Schüler könnte aber auch Schulklassen beinhalten.

Also ich bräuchte etwas mehr darum wissen, um helfen zu können.

 

[Xyz1]

Nonsens, ein Schüler beinhaltet 1 bis n Klassen (Verlauf ja/nein), ein Lehrer beinhaltet 1 bis n Fächer (ausgebildet nur für ein Fach? ja/nein). So ergibt's doch Sinn.

Will man jetzt wissen, wer alles das Fach Geschichte unterrichtet, schaut man nicht in Geschichte vorbei, sondern schaut bei jedem Lehrer vorbei.

 

[Baldur]

Das ist, was ich mit der Datenbanknormalisierung meinte. Am Ende hat man die Klassen Schüler, Lehrer, Fach usw mit den notwendigsten Attributen und kennt die Beziehungen zwischen den Klassen. Lehrer:Fächer ist eine 1:n Beziehung und lässt sich mit einer Liste von Fächern bei jedem Lehrer implementieren.
Schwieriger wäre da die Beziehung zwischen Klasse und Fächer, die müsste ja eigentlich m:n sein. Das könnte man aber auch implementieren, indem man Klassen und Fächern jeweils eine Liste für das jeweils andere Objekt gibt.

 

[Xyz1]

die müsste ja eigentlich m:n sein.

n:m wird doch mit einer Zwischentabelle aufgelöst. Aber wir sind doch gar nicht bei Databases.

https://de wikipedia org/wiki/Kardinalit%C3%A4t_%28Datenbankmodellierung%29#n:m und ff.

nicht direkt umgesetzt werden.

Also ich denke, wir schmeißen hier gerad alle in einen Topf. Das sollten wir nicht tu. Ein ER hat er glaub ich nicht gefragt.

Ich möchte jetzt auch gar nicht, eine Enterprise Business Lösung hervortun.

 

[Baldur]

Richtig, aber die Normalisierungen bei Datenbanken lässt sich ja auch bei Klassen anwenden und hilft ggf auch sich leichter vorzustellen, wie die Klassen am Ende aussehen sollen. Es hilft ja auch der Kapselung, wenn man vorher die Komplexität der Objekte reduziert.

Bei Datenbanken braucht man für n:m dann die Verknüpfungstabelle, aber bei dem Programm würde es reichen wenn die Klassen-Klasse einfach eine Liste von Fächern hat. Ggf kann auch jedes Fach noch eine Liste von Klassen haben, die in dem Fach unterrichtet werden, ist aber eventuell nicht wirklich notwendig.

 

[fhs14647]

Hallo Profis
Zuerst mal ein Lob, Ihr verdient die Anrede "Profis" zur Recht ;-)
Der Hinweis mit der Datenbankmodellierung hilft tatsächlich! Auch den möglichen Zirkelbezug von Lehrern und Fächern habe ich kapiert.
Was mich aber auch immer verunsichert ist der Ort der Instanziierung der Objekte. Im Fall von DerWissende wurden alle Objekte in der main-Methode der Schulklasse gemacht.
Wann (??) macht man die Objektinstanziierung beispielsweise NICHT in der main-Methode, sondern direkt im Konstruktor einer Klasse (auch bei den von Euch geschilderten Nachteilen eines Zirkelbezuges)
Ein Beispiel, das sicher nicht gerade intelligent ist .. Wenn ein Lehrerobjekt angelegt wird, soll immer auch ein gesonderter, reservierter Parkplatz angelegt werden, also eine 1:1 Beziehung. Wäre der folgende Code hier sinnvoll??

public class Lehrer {  
    private String name;
    private UnterrichtsFaecher fach;
    private LehrerParkPlatz platz;
  
    public Lehrer(String _name)
    {
      this.name = _name;
      platz = new LehrerParkPlatz();
    }

 

[Xyz1]

Naja, dann Komposition...



Edit:

Im Fall von DerWissende wurden alle Objekte in der main-Methode der Schulklasse gemacht.

Weil mein Projekt so hieß, irgendwie muss ich den Bums ja nennen, das geht ja auch in jeder anderen Klassen.

 

[Xyz1]

Also gut. Parkplätze sind in der Realität dynamisch. Kommt ein neuer Lehrer hinzu, wird schnell ein Parkplatz gebaut. Weil ein Parkplatz so einfach gebaut werden kann, wird ein Parkplatz auch schnell wieder entfernt, wenn ein Lehrer entfernt wird.

Also etwas macht das sin.

Komposition ist die verstärkte Aggregation als Teil-Ganzes-Beziehung. Kein Parkplatz ohne Lehrer, vereinfacht gesagt. In der Realität nicht immer so, aber in deinem Beispiel schon. und dann könnte man Parkplätzen auch noch (Code-)Namen geben.

 

[fhs14647]

OK, ich glaube, langsam checke ich es ;-)

Danke Euch allen für Eure Hilfe!
Noch eine Frage (und speziellen Dank) an DerWissende: mit welchem Tool machst du deine tollen Klassendiagramme. Ich arbeite mit der IDE Netbeans, gibt es hier ev. ein Plugin?

Liebe Grüße und danke nochmals
FHS

 

[mrBrown]

OK, ich glaube, langsam checke ich es ;-)

Danke Euch allen für Eure Hilfe!
Noch eine Frage (und speziellen Dank) an DerWissende: mit welchem Tool machst du deine tollen Klassendiagramme. Ich arbeite mit der IDE Netbeans, gibt es hier ev. ein Plugin?

Liebe Grüße und danke nochmals
FHS

http://plugins.netbeans.org/plugin/55435/easyuml

Lucidchart ist ansonsten noch recht praktisch und empfehlenswert

 

[Xyz1]

Jo, des isses, ist aber Geschmacksfrage, was man nehmen möchte.