OOP Zugriff auf Objekte von außen

[apa13179]

Hallo,
ich habe ein Java-Projekt das zum Einlesen versch. Messdatn dienen soll.

In der Klasse FileHandler erzeuge ich ein Objekt Header (Head1) und mehrere Objekt Messdaten (Measure1, Measure2 ...).
Ich will jetzt in der Klasse ÜbergabeDB die vorher erzeugten Objekte aufrufen und in die DB schreiben.

Wie bekomme ich den Zugriff auf die Objekte hin?

 

[Joose]

Mittels getter/setter Methoden oder einfach nur als Parameter könntest du Objekte übergeben.

EDIT:
Die Klasse "FileHandler" sollte ja nur das Einlesen der Daten übernehmen, die Klasse "ÜbergabeDB" sollte nur das Eintragen in die Datenbank regeln.

Sprich du brauchst noch eine Klasse welche die Logik deiner Applikation abbildet.
Diese Klasse erzeugt nun ein Objekt von FileHandler und bekommt die erstellten Objekte als Rückgabe einer Methode "leseDaten" oder per getter.
Diese Objekte kann man nur per setter oder als Parameter an eine Methode eines ÜbergabeDB-Objektes geben.

 

[kneitzel]

Also wie das konkret geht kann man nur direkt am Code zeigen. Normalerweise gibt man Referenzen auf Instanzen weiter über die man dann (ggf. über weitere Referenzen) an die Daten heran kommt.

Also so ein Ablauf könnte dann irgendwo so aussehen:

FileHandler fileHandler = new FileHandler();
fileHandler.soSomething();
UebergabeDB uebergabe = new UebergabeDB(fileHandler); // Falls der Konstrutor ein FileHandler nutzen kann.
UebergabeDB uebergabe = new UebergabeDB(fileHandler.getHeader, fileHandler.getData); // Hier werden nur die Daten selbst übergeben. Macht es etwas unabhängiger aber da wäre ein Interface evtl. besser...
UebergabeDB uebergabe = new UebergabeDB();
uebergabe.setHeader(fileHandler.getHeader()); // Jetzt halt über Setter statt über Konstrultor.

Oder eben der indirekte Weg

public class SomeClass {
    FileHandler fileHandler;

    public FileHandler getFileHandler() {
       return fileHandler;
    }

    public void someCodeSomewhere() {
      fileHandler.soSomething();
      UebergabeDB uebergabe = new UebergabeDB(this); // Jetzt kann halt die ÜbergabeDB Klasse SomeClass.getFileHandler aufrufen.

Unter dem strich ist es halt einfach so, dass Du eine Art Netz aus Referenzen aufbaust. (Wobei die meisten Dinge nur eine Baumstruktur haben.) Also oft hast Du eine Instanz einer Klasse, die die Applikation darstellt oder den Server oder was halt die Basis ist. Und dort hast Du dann halt weitere Dinge wie Zugriff auf DataLayer, Model, Controller, ...

Es ist halt wichtig, das OO Design ordentlich zu machen, dann ergibt sich der Rest von alleine.

 

[apa13179]

OK. Danke.

Also kann ich auf ein Objekt nur in der Methode zugreifen, in der ich es erstelle?

 

[Joose]

Ja in Java wird hier von "Scope" gesprochen: Hier eine ausführlichere Beschreibung http://java.about.com/od/s/g/Scope.htm

 

[apa13179]

OK. Alles klar.
Dann eben mit getter und setter.

 

[apa13179]

Mein Ansinnen war, dass ich zuerst alle Daten aus der Textdatei zusammentrage und danach eine DB-Verbindung aufbaue und alles in die DB übertrage und danach Verbindung wieder kappen.

So werde ich mehrmals auf die DB zugreifen müssen, da ich denke das der Code sonst unübersichtlich wird.

 

[kneitzel]

Wieso sollte der Code unübersichtlich sein? Das ist ja nur eine Frage der Schreibweise.

Du kannst ja folgendes haben:
a) Eine Klasse, die nur die Daten eines Datensatzes hält (POJO = Plain Old Java Object)
b) Eine Klasse, die eine Textdatei liest und dann eine Liste der Daten liefert.
c) Nun kann eine Funktion die Datenbank öffnen und für jeden Datensatz in der Liste diesen in die Datenbank eintragen.
Wo Du die Datenbank genau öffnest ist dabei dann auch egal - das kann im Punkt b) sein (halt ausserhalb der for each Schleife und C) bekommt dann die Connection mit) oder es kann in c) sein.

Generell ist folgendes zu bedenken:
Nur weil Du im Code ständig Datenbankverbindungen "öffnest", geschieht dies nicht wirklich! Viele Treiber nutzen ein Connection Pooling, d.h. der Treiber ist zuständig für die Verwaltung der Connections. Wenn eine Connection angefordert wird, dann schaut er, ob noch eine offene Connection da ist. Ist dies der Fall, wird diese Connection geliefert. Ist dies nicht der Fall, dann wird eine neue Verbindung aufgebaut.
Beim Schließen der Verbindung, wird die Verbindung nicht geschlossen sondern landet geöffnet in diesem Pool.

Es ist ein Best Practice bei uns, die Datenbankverbindungen immer nur kurz offen zu halten.

Also unter dem Strich zwei Punkte:
- Sauberes Design ist unabhängig davon möglich, was Du genau machen willst. Eine Aussage wie "Ich will die Connection offen halten" sorgt nicht für schlecht lesbaren Code. Egal was für Anforderungen kommen: Clean Code ist möglich.
- Keine Optimierungen! Nicht versuchen hier etwas zu optimieren a.la. "Ich will die Datenbank offen halten". Gerade bei Dingen, die schon Millionen anderer Entwickler gemacht haben, ist es sehr wahrscheinlich, dass es da schon andere Lösungen gibt (wie hier das Connection Pooling).

 

[Joose]

Hier ein kleiner Beispielcode:

public class Applikation() {
   private FileHandler file;
   private DatabaseHandler database;

   public Applikation() {
     file = new FileHandler();
     database = new DatabaseHandler();
   }

   public void Work() {
     file.Read();
     List<SomeData> datalist = file.getData();;
     // daten manipulieren wenn gewünscht .....
     database.insertData(datalist);
   }
}

Deine beiden Klassen zum File einlesen, bzw. in die DB schreiben bleiben nahezu unverändert