Referenz Objekt aufrufen

[hasocuk]

Hallo zusammen,

ich mache mir Gedanken, wie ich auf Objekte, die weiter oben in der Struktur angesiedelt sind zugreifen kann.

 

[LimDul]

Nun, indem du korrekt auf sie zugreifst.

Spezifiziere deine Frage mal mit einem konkreten Beispiel? Was ist "weiter oben in der Struktur"?

 

[Kirby.exe]

Hallo zusammen,

ich mache mir Gedanken, wie ich auf Objekte, die weiter oben in der Struktur angesiedelt sind zugreifen kann.

Sende mal deinen Code, dann kann man dir besser helfen

 

[hasocuk]

Sorry für den Fehlbeitrag, habe zu schnell gedrückt auf den Button!

Hallo zusammen,

ich mache mir Gedanken, wie ich auf Objekte, die weiter oben in Richtung Kopf in der Struktur angesiedelt sind zugreifen kann. Beziehungsweise auch auf Objekte, die durch wiederum andere Objekte erzeugt wurden. Wie kann ich mir Zeiger erzeugen die auf Bestimmte Knoten zeigen und diese weitergeben?

Meine Vorstellung ist, Der Zeiger / Referenz von Auto wird weitervererbt und steht im Innenraum, Bereifung, Motor, aber auch in Lenkrad und Sitze zur Verfügung. Der Zeiger auf Innenraum, wäre daher in dem Objekt Sitze und Lenkrad verfügbar. Könnt ihr mir bitte ein Beispiel geben, wie ihr sowas lösen tut.

Im Pseudo Code, habe ich einige stellen zu meinen Problem markiert. Vielen Dank im Voraus

Gruß
Hasan

public class Start {
public static Auto start;

public static void main(final String[] args) {
start = new Auto("BMMM");
}
}
public class Auto {
String name;
Innenraum myInnenraum;
Bereifung myBereifung;
Motor myMotor;
public Auto(String name) {
this.name = name;
init();
}
public void init() {
myInnenraum = new Innenraum("Sport");
myBereifung = new Bereifung();
myMotor =new Motor();
}
}

public class Innenraum {
Sitze mySitze;
Lenkrad myLenkrad;
String Ausstattungsklasse;
public Innenraum(String txt){
this.Ausstattungsklasse =txt;
this.mySitze = new Sitze();

this.myLenkrad = new Lenkrad();
}
}
public class Bereifung {
String Felgentyp;
String Felgenroesse;
public Bereifung(){
// Hier würde ich gerne Abfragen, welche Marke,
// Daher auf das Auto Objekt zugreifen
// wenn BMM dann Felgentyp = new ALU("BMM"); //usw.
}
}
public class Lenkrad {
public Lenkrad() {
// Hier würde ich gerne Abfragen ob das Objekt --> Sitzart z.B. Sport ist
// wie kann ich auf das Object zugreifen
}
}

public class Sitze {
String sitzart;
}
public Sitze(String sitz) {
this.sitzart = sitz;
}

 

[httpdigest]

Das ist ein guter Anwendungsfall für nicht-statische innere Klassen. Diese besitzen eine implizite Sichtbarkeit auf die Instanz der äußeren Klasse:

public class Auto {
  public class Innenraum {
    public class Lenkrad {
      public Lenkrad() {
        System.out.println(Innenraum.this.sitze.sitzart);
      }
    }
    public class Sitze {
      private String sitzart;
      public Sitze(String sitzart) {
        this.sitzart = sitzart;
      }
    }
    private Sitze sitze;
    private Lenkrad lenkrad;
    private String ausstattungsklasse;
    public Innenraum(String ausstattungsklasse) {
      this.ausstattungsklasse = ausstattungsklasse;
      this.sitze = new Sitze("leder");
      this.lenkrad = new Lenkrad();
    }
  }
  public class Bereifung {
    private String Felgentyp;
    private String Felgenroesse;
    public Bereifung() {
      System.out.println(Auto.this.bereifung);
    }
  }
  public class Motor {
  }
  private String name;
  private Innenraum innenraum;
  private Bereifung bereifung;
  private Motor motor;
  public Auto(String name) {
    this.name = name;
    init();
  }
  public void init() {
    innenraum = new Innenraum("Sport");
    bereifung = new Bereifung();
    motor = new Motor();
  }
}

 

[hasocuk]

Hallo httpdigest vielen Dank für deine Antwort.

Das klappt auch und finde es als eine leichte Vorgehensweise. Aber bekomme bedenken für mein vorhaben, wegen der Übersicht wegen der Verschachtelung. Ich wollte für mein Projekt unabhängige Klassen die einerseits vererben und veränderte Kindklassen sind, wo ich je nach Produkt individuell zusammenbauen kann nach Abhängigkeiten und diese auch eine Art Schnittstelle zum zusammenbauen des Models sind. Daher wäre mein Aufbauwunsch für mein Model, das diese als einzelne Klassen anzulegen wegen der Wartbarkeit, Framesteuerung usw.. Oder verstehe das Konzept nicht?

Um beim Beispiel zu bleiben, Kraftfahrzeug --> Auto, Bus, Motorrad, Auto --> Sportwagen, Van, Limousine, Motor --> für Auto, Bus, Motorrad und diese wiederum Diesel, Elektro, Benziner. Mein eigenes Projekt würde zum Teil 3-4 Vererbungsebenen von der Hauptklasse haben und hier möchte ich die Kontrolle beibehalten können.

Von Oben kann ich ja zugreifen, da sage ich Auto.Innenausstattung.Lenkrad.Methode(), gibt es hier keine Technik / Möglichkeit die Referenzen im unterem Knoten bereitzustellen wie oben beschrieben?

--- Meine Vorstellung ist, Der Zeiger / Referenz von Auto wird weitervererbt und steht im Innenraum, Bereifung, Motor, aber auch in Lenkrad und Sitze zur Verfügung. Der Zeiger auf Innenraum, wäre daher in dem Objekt Sitze und Lenkrad verfügbar ----

Danke nochmals!
Hasan

 

[httpdigest]

gibt es hier keine Technik / Möglichkeit die Referenzen im unterem Knoten bereitzustellen wie oben beschrieben?

Klar gibt es die. Nutze einen Konstruktorparameter, der die Instanz der äußeren Klasse als Argument bekommt, und speichere die Instanz in einer Instanzvariable. Heißt (z.B: für die Klasse Bereifung):

private final Auto auto;
public Bereifung(Auto auto) {
  this.auto = auto;
}

Innere Klassen in Java funktionieren genauso, nur, dass man den Konstruktorparameter nicht explizit sieht und angeben muss.
Nach diesem Schema kannst du dann beliebig wieder hochnavigieren.

 

[Thallius]

Das Ganze wiederspricht aber dem eigentlich OOP Gedanken. Es gibt nämlich eigentlich keinen Grund warum das Lenkrad wissen muss in welchem Auto es eingebaut ist.

Gruß

Claus

 

[Kirby.exe]

Das Ganze wiederspricht aber dem eigentlich OOP Gedanken. Es gibt nämlich eigentlich keinen Grund warum das Lenkrad wissen muss in welchem Auto es eingebaut ist.

Gruß

Claus

Da muss ich dir wiedersprechen, denn wenn das Lenkrad ein Airbag besitzt sind diese an Fahrzeuge gebunden, somit müsste es schon wissen an welchem Auto es montiert ist...z.B. die Fahrgestellnummer

 

[hasocuk]

Vielen Dank, das hilft mir so sehr weiter, werde mich jetzt da rein arbeiten.

 

[kneitzel]

Da muss ich dir wiedersprechen, denn wenn das Lenkrad ein Airbag besitzt sind diese an Fahrzeuge gebunden, somit müsste es schon wissen an welchem Auto es montiert ist...z.B. die Fahrgestellnummer

Nein, wieso sollte das Lenkrad die Fahrgestellnummer kennen oder das Auto? Wenn ich das Lenkrad (Ein System, das einfach eine Eingabe in Form einer Drehung entgegen nimmt und weiter gibt) so begrenze, dann kann ich daraus nichts anderes mehr machen. Also so Ein Auto Lenkrad kann ich dann nicht an einem Boot befestigen.... ==> Das zeigt, wie wichtig die Reduzierung der Abhängigkeiten ist. Das Folgende macht es evtl. auch deutlich:

Das schöne bei der Objektorientierung ist doch eben, dass man sich schön an der Realität entlang hangeln kann.
- Das Lenkrad ist einfach ein Lenkrad. Das kann Airbags haben, muss es aber noch nicht mal.
- Das Lenkrad muss das Auto selbst nicht kennen. Es muss aber das Lenksystem kennen, denn wenn es benutzt wird (also sowas wie "10° nach rechts gedreht", dann muss es das weiter geben, so dass sich z.B. die Stellung der Räder verändert)
- Die angesprochenen Airbags haben mit dem Lenkrad kaum etwas zu tun. Sie kommen da dann halt rein. Aber das Lenkrad hat mit den Airbags ja nichts zu tun. Die Steuerung übernimmt ein Steuerungskasten. Dem ist das Fahrzeug aber auch egal. Das Airbag Steuersystem kennt Sensoren und werte die Signale der Sensoren aus. Und es kennt die Airbags. Wenn dann bestimmte Sensorsignale vorliegen und das Gerät nicht auf Störung ist, dann werden Airbags ausgelöst und direkt auf Störung gegangen - Das Steuersystem schaltet sich sozusagen mit Auslösung auch selbst dauerhaft ab.
- Die Sensoren interessieren sich für das Auto selbst auch nicht. Sehr wohl aber Positionsveränderungen. Dabei ist es den Sensoren aber egal, ob diese in einem Auto, Flugzeug oder sonst wo verbaut sind. Die Sensoren messen z.B. die Beschleunigung und das war es auch schon!

Durch die Begrenzung der Abhängigkeiten kann ich alles frei verwenden ohne es anzupassen. Die G-Sensoren baue ich überall da ein, wo ich sie brauchen kann.

 

[hasocuk]

Hallo JustNobody,

ich meine hier, Grundsätzlich hast du recht das die Eigenschaften des Lenkrad Objektes nicht vom Auto abhängen darf, aber wenn du in die Richtung Konfiguration denkst, sieht es mir nach etwas anders aus. Du hast eine Reihe an meinetwegen Lenkrädern, die du in eine Box zur Auswahl stellen möchtest. Genau hier ist es von Interesse mir nach zu wissen, welches Auto ist aktuell ausgewählt zur Begrenzung. Weiterhin kommen Restriktionen hinzu, wo du es erst Optionen nach gewählter Ausstattung verfügbar machen möchtest oder die Auswahl eines Soundsystems, soll weiteren Einfluss nehmen z.B. den Ausbau des Standardradios und den Einbau des Radio++Systems.

Mir nach ist es auch nötig und von Vorteil nicht nur den Objekt-Model des Autos zur Bestimmung zu nutzen, sondern das das untere Objekt das Auswahlelement vom Lenkrad die Auswahlmöglichkeit nach den Abhängigkeiten abregelt. Daher ein Teil der wählbaren Lenkräder sind defaultmäßig registriert und weitere kommen hinzu oder die Auswahl reduziert sich innerhalb einer Konfiguration. Anhand von einzelnen Auswahlelementen werden dann die Eigenschaften des eigentlichen Lenkrad Objekts gebaut (Beschrieben) und dieses ist nicht im voraus statisch fest. Das ist mein Grund, wieso ich von unten und in die Seite prüfen möchte, wo ist welches Objekt mit welcher Eigenschaft vorhanden.

Gruß
Hasan

 

[Thallius]

Falsch herum. Das Auto definiert welche Lenkräder es benutzen kann. Nicht das Lenkrad muss wissen in welches auto es passt.