Variablen Werte nach setzen, bei Abfrage wieder alter Wert

[mOiterei]

Guten Abend,
folgender Umstand:

Ich schreibe ein Programm um meine Anbauplanung im Garten zu "digitalisieren".

Ich speichere Daten in .txt Dateien. Das Laden und anzeigen funktioniert super. mit einem Dialogfenster kann ich diese Werte anzeigen und ändern, Dies verändert Größe und Position des JLabels auf dem JPanel. Alles super.

rufe ich nun die Daten ab um sie zu speichern, schreibt er die alten Daten (auch System.out.println gibt die alten Werte aus).

Main-Klasse (erzeugt DataHandler Objekt, startet den Planer und übergibt die zu verwendenden Beete):

GH_start
{
    public static DataHandler     dh        = new DataHandler();
    
    public static void main (String[] args)
    {
        new Planer(dh.ladeBeete());
        
    }
}

Die Klasse hat noch nicht viel zu tun, da kommt später noch mehr

public class Planer
{
    ArrayList<Beet> beete;
    
    public Planer(ArrayList<Beet> beete)
    {
        this.beete = beete;
        new BeetAnsicht(beete).anzeigen(beete.get(0));
        
    }
}

Diese Klasse stellt sowohl den Container in der das Beet angezeigt wird, als auch den Schnittpunkt um verschiedene Beete anzeigen zu lassen (kommt noch):

public class BeetAnsicht extends JDialog implements ActionListener, Daten
{
    private static final long serialVersionUID = 8308404013997791137L;
    
            ArrayList<Beet> beete;
            
    public BeetAnsicht(ArrayList<Beet> beete)
    {
        this.beete = beete;
        speichern.addActionListener(this);

    }
        @Override
    public boolean speichern()
    {
        GH_start.dh.speichereBeete(beete);
        return false;
    }
        public void actionPerformed(ActionEvent ae)
    {
        if(ae.getSource() instanceof JMenuItem)
        {
            if(ae.getSource() == speichern) this.speichern();
        }
            
        
    }

Klasse um alle Daten laden und speichern zu können:

public class DataHandler
{
    static BufferedReader in;
    static BufferedWriter out;
    File pfad = new File(GH_start.pfad);
    File[] dateien = pfad.listFiles();
    URL url;
    String s;
    String[] sa;
    int i;   

    DataHandler()
    {
        super();
    }

    
    /*------------------------------------- LADEN --------------------------------------------- */
    
    public ArrayList<Beet> ladeBeete()
    {       
        File f = new File(pfad.getAbsolutePath()+"/beete/");
        ArrayList<Beet> bl = new ArrayList<Beet>();
        //ERROR abfangen
        if(f == null || !f.exists() || !f.isDirectory())
        {
            System.err.println("DH[60]:"+f+" Ordner existiert nicht!");
            return null;
        }
        else if(f.listFiles().length == 0)
        {
            System.err.println("DH[65]: Ordner "+f.getAbsolutePath()+" ist leer!");
            return null;
        }
        // ansonsten:
        else
        {
            sa = null;
            Beet b = null;
//           
            for(File file : f.listFiles())
            {
                try {
                    in = new BufferedReader(new FileReader(file));
                    //erste Zeile
                    s = in.readLine();
                    if(s!=null && !s.isBlank() && s.contains("#")) sa = s.split("#");
                    else
                        {
                            System.out.println("DH[84]: continued; beet = "+b);
                            continue;
                        }
                    b = new Beet(file.getName(),
                            sa[0].split("x"),
                            Integer.parseInt(sa[1]),
                            Integer.parseInt(sa[2]),
                            sa[3],        sa[4]);
                    
                    //zweite Zeile, dritte, ...
                    //Endivie#101,60#1#1
                    //name   # x , y#ausr#anzahl
                    
                    String str = in.readLine();
                    String[] point;
                    Pflanze p;
                    while(str != null && !str.isBlank())
                    {
                        sa = str.split("#");   
                    
                        p = null;
                        p = GH_start.getPflanze(sa[0]);
                        point = sa[1].split(",");
                        
                        if(p!=null)
                            {
                            if(point != null && point.length==2)
                                p.setLocation(Integer.parseInt(point[0]), Integer.parseInt(point[1]));
                                    else System.err.println("DH[112] : Point null oder length != 2");
                            if(sa[2] != null && !sa[2].isBlank())
                                p.setAusrichtung(Integer.parseInt(sa[2]));
                                    else System.err.println("DH[115] : sa[2] null oder isBlank");
                            if(sa[3] != null && !sa[3].isBlank())   
                                p.setAnzahl(Integer.parseInt(sa[3]));
                                    else System.err.println("DH[118] : sa[3] null oder isBlank");
                            b.addReihe(    p,
                                        new Point(p.getX(),p.getY()),
                                        Integer.parseInt(sa[2]));
                            
                            }
                        else System.err.println("DH [112] Pflanze aus PflLi == null");

                        str = in.readLine();
                    }
                    
                    in.close();
                
                } catch (FileNotFoundException e) {
                    e.printStackTrace();
                } catch (IOException e) {
                    e.printStackTrace();
                }
                
                bl.add(b);
            }
            
            return bl;
        }

    }

    public ArrayList<Pflanze> ladePflanzen()
    {
        System.out.println("DH [142]: lade Pflanzen...");
        File f = new File(pfad.getAbsolutePath()+"/Pflanzen/Liste.txt");
        ArrayList<Pflanze> pl = new ArrayList<Pflanze>();
        
        if(f == null || !f.exists())
        {
            System.err.println("DH[149]:"+f+" Datei existiert nicht!");
            return null;
        }

        else
        {
            try {
                in = new BufferedReader(new FileReader(f));

            
            for(s = in.readLine(); s!=null&&!s.isBlank(); s = in.readLine())
                {
                    //name#abstand#düngung#sonne#ph#saat#pfl#ernte
                     sa = s.split("#");
                     if(sa==null || sa.length<8)
                         {
                     System.err.println("DH [165]: "+sa[0].strip()+" -- Array == null ODER länge <8  -- continued;");
                     continue;
                     }
                     try{
            
                         pl.add(new Pflanze(sa[0].strip(),
                                 sa[1],
                                 sa[2],
                                 sa[3],
                                 sa[4],
                                 sa[5].split("-"),
                                 sa[6].split("-"),
                                 sa[7].split("-")));
                     }catch( ArrayIndexOutOfBoundsException iob)
                     {System.err.println("DH[179]: Pflanze: "+sa[0].strip()+" - "+iob.getLocalizedMessage()); }
                     catch( NumberFormatException nfe)
                     {System.err.println("DH[181]: Pflanze: "+sa[0].strip()+" - "+nfe.getLocalizedMessage());}
                };
                
                return pl;
            } catch (FileNotFoundException e) {
                e.printStackTrace();
            } catch (IOException e) {
                e.printStackTrace();
            }


        }
        return null;
    }
    
    /**
     *  nutzt speichernBeet(Beet) in Schleife
     */
    public void speichereBeete(ArrayList<Beet> beetListe)
    {
        for(Beet b : beetListe)   
            {
                System.out.println("DH [189] speichere Beet: "+b);
                speichereBeet(b);
            }
    }
    
        public boolean speichereBeet(Beet b)
    {
        /* File : beetname.beet
         *
         * breitexlänge#feste,ph,Licht,Düngung
         *
         *     int festigkeit;
         *    int ph;
         *  Anspruch licht;
         *  Anspruch düngung;
         */
        File f = new File(pfad.getAbsolutePath()+"/beete/");

        try {
            out = new BufferedWriter(new FileWriter(f+"/"+b.getName()));
            out.write(b.speicherDaten());
            out.newLine();
        
            if(b.getPflanzen().isEmpty())    return true;
        
            else
            {
            for(Pflanze pfl : b.getPflanzen())
                {
                    System.out.println("DH[239] Writer out = "+pfl.speicherDaten());
                    out.write(pfl.speicherDaten());
                    out.newLine();
                }

            out.flush();
            }
            out.close();
        } catch (IOException e) {
            JOptionPane.showMessageDialog(null, e.getMessage(),
                    "Fehler beim Speichern: "+b, JOptionPane.ERROR_MESSAGE);
            return false;    }
        
        // bis ende durchgelaufen :
        return true;
    }

Das Interface wird von jeder Klasse implementiert, die geladen oder gespeichert werden muss

public interface Daten
{

    boolean laden() throws IOException;

    boolean speichern();

    String speicherDaten();

    abstract String getPfad();

    void setPfad(String s);

    String getName();

    JMenuItem laden     = new JMenuItem("laden"),

              speichern = new JMenuItem("speichern");
}

Mir ist, als würde ich zwei Objekte erzeugen, das eine bearbeiten und zum speichern ein anderes der selben Klasse aufrufen. Ich kann aber seit Tagen keine doppelte Zuweisung o.ä. finden.

über Hilfe wäre ich sehr dankbar, ich hoffe das der Code reicht

MfG

 

[KonradN]

Der gezeigte Code reicht nicht aus. BeetAnsicht bräuchten wir auch komplett. Meine Vermutung ist aktuell, dass Du zwar Daten aus einem Beet in die Controls übernimmst, aber veränderte Daten gehen nicht zurück in die entsprechende Instanz. Aber ohne den genauen Code bleibt das eine reine Vermutung.

Ansonsten ist die Aufteilung auch etwas unsauber (meiner Meinung nach) - Es macht Sinn, so eine Anwendung aufzuteilen in halt Daten und dann die Anzeige, die darauf basiert. Das ist nicht wirklich erfolgt. Hier wäre dann ein Pattern wie MVC oder MVVM sinnvoll.

 

[mihe7]

Da schließe ich micn @KonradN an und würde noch ergänzen, dass da noch mehr im argen ist: viel zu viel static, zyklische Abhängigkeiten, zu große Scopes, Ressourcen werden nicht sauber freigegeben. Vielleicht postest Du einfach mal den ganzen Code, notfalls gezippt, dann kann sich das jemand mal im Zusammenhang ansehen.

 

[mOiterei]

Danke erstmal für die Rückmeldung. BeetAnsicht dann erstmal hier komplett, und alle (hoffentlich) entscheidenden Klassen als .zip im Anhang.

MVC oder MVVM sagt mir derzeit garnichts, dazu werde ich mich mal noch schlau machen.

public class BeetAnsicht extends JFrame implements ActionListener, Daten
{
    private static final long serialVersionUID = 8308404013997791137L;
    
            ArrayList<Beet> beete;
            
            JButton            löschen    = new JButton("Löschen");
            JTextField        name    = new JTextField(10);
            GNumberField     wf        = new GNumberField(5);
            GNumberField     hf        = new GNumberField(5);
            
            static JMenuBar    bar        = new JMenuBar();
            
            JMenu             beetMenu= new JMenu("Beet auswählen");
            JMenu            optionen= new JMenu("Optionen");
            JMenu            pflListe= new JMenu("Pflanzenliste");

            JMenuItem         item;
    
    public BeetAnsicht(ArrayList<Beet> beete)
    {
        this.beete = beete;

        speichern.addActionListener(this);
        optionen.add(speichern);
                
        bar.add(optionen);
    }

    public static Beet anlegen()
    {

         /*Objekte für JOptionPane anlegen
         *
         *Variablen für Beet:
         *name
         *H x B
         *jahr - date.getYear
         *anspruch1 - jCombobox
         *anspruch2 -     "
         */
        JTextField             name  = new JTextField();
        GBeetDimension        gbd      = new GBeetDimension(0,0);
        JComboBox<Anspruch> anspS = new JComboBox<Anspruch>(new Anspruch[] {Anspruch.schattig, Anspruch.halb, Anspruch.sonnig});
        JComboBox<Anspruch> anspD = new JComboBox<Anspruch>(new Anspruch[] {Anspruch.schwach,    Anspruch.mittel,Anspruch.stark});
        JSlider             anspPH= new JSlider(4, 10, 7);
        JSlider                feste = new JSlider(0, 10, 5);
        
        anspPH.setPaintTicks(true);
        anspPH.setPaintLabels(true);
        anspPH.setPaintTrack(false);
        anspPH.setMajorTickSpacing(1);
        
        feste.setPaintTicks(true);
        feste.setPaintLabels(true);
        feste.setPaintTrack(false);
        feste.setMajorTickSpacing(1);
        
        /* OBjekte zusammen fassen*/
        Object[] msg  = {"Beetname:", name,
                         "Höhe[cm] x Breite[cm]:", gbd,
                         "Anspruch [Licht]:", anspS,
                         "Anspruch [Dünger]:", anspD,
                         "Anspruch [PH]:", anspPH,
                         "Bodenfestigkeit:", feste};
        
        /* JOP anlegen */
        JOptionPane jop = new JOptionPane(msg, JOptionPane.PLAIN_MESSAGE, JOptionPane.OK_CANCEL_OPTION);
        jop.createDialog("Beet anlegen").setVisible(true);
        
        
        
        return    new Beet(name.getText(),
                gbd.getDimension(),
                feste.getValue(),
                anspPH.getValue(),
                anspS.getSelectedItem()+"",
                anspD.getSelectedItem()+""
                );
    }
    
    public void anzeigen(Beet b)
    {       
        setTitle("Beet: "+b.name);
        setBounds(300, 300, b.getWidth()+5, b.getHeight()+5);
        setLocationRelativeTo(null);
        setPreferredSize(new Dimension(b.getWidth()+30, b.getHeight()+70));
        setResizable(false);
        setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);
        
        add(new JLabel("Beet: "+b.name+"("+b.getBreite()+"x"+b.getHöhe()+")"), BorderLayout.NORTH);
        add(Box.createVerticalStrut(10), BorderLayout.SOUTH);
        add(Box.createHorizontalStrut(10), BorderLayout.WEST);
        add(Box.createHorizontalStrut(10), BorderLayout.EAST);
//ScrollPane o.F.
        add(new JScrollPane(b), BorderLayout.CENTER);
        
        if(beete != null && beete.size()>1)   
        {    for(Beet beet : beete)   
                 {
                    JMenuItem item = new JMenuItem(beet+"");
                    item.addActionListener(this);
                    beetMenu.add(item);
                 }
        }
        bar.add(beetMenu);
        bar.add(new JLabel("Linienabstand = "+this.beete.get(0).getRasterGr()+" cm"));
        setJMenuBar(bar);
        setVisible(true);
        
    }

    @Override
    public void actionPerformed(ActionEvent ae)
    {
        if(ae.getSource() instanceof JMenuItem)
        {
            if(ae.getSource() == speichern) this.speichern();
        }
            
        
    }

    @Override
    public boolean laden()
    {
        beete = null;
        beete = GH_start.dh.ladeBeete();

        return beete!=null;
    }

    @Override
    public boolean speichern()
    {
        GH_start.dh.speichereBeete(beete);
        
        return false;
    }

    @Override
    public String getPfad() {
        return null;
    }

    @Override
    public void setPfad(String s) {
        
    }

    @Override
    public String speicherDaten() {
        return null;
    }

}

 

[mihe7]

Danke erstmal für die Rückmeldung. BeetAnsicht dann erstmal hier komplett, und alle (hoffentlich) entscheidenden Klassen als .zip im Anhang.

lol, wir brauchen schon die .java-Dateien, nicht die .class-Dateien

 

[mOiterei]

Ach Scheiße, tut mir leid

 

[mOiterei]

Achso und danke für den Hinweis mit der Aufteilung und dem MVC. Das gefällt mir als Leitfaden zur Organisation auch wirklich gut

 

[mOiterei]

Da schließe ich micn @KonradN an und würde noch ergänzen, dass da noch mehr im argen ist: viel zu viel static, zyklische Abhängigkeiten, zu große Scopes, Ressourcen werden nicht sauber freigegeben. Vielleicht postest Du einfach mal den ganzen Code, notfalls gezippt, dann kann sich das jemand mal im Zusammenhang ansehen.

Zu dieser Nachricht muss ich auch nochmal nachharken für mein Verständnis. Die Begriffe sind mir nicht alle bekannt.

static ist klar, das versuche ich auch zu minimieren. Das überarbeite ich, wenn es funktioniert noch einmal.

zu zyklischen Abhängigkeiten musste ich mich erst belesen, bin aber nicht wirklich daraus schlau geworden was ich dann ändern sollte. Zumindest würde das was mir dazu einfällt meiner Meinung nach die Übersichtlichkeit beeinträchtigen.

große Scopes heißt, das zu oft public verwendet wird, oder? Damit gehe ich um, wie mit dem static.

Ressourcen freigeben: dazu musste ich mich benefalls erst belesen ( ähnliches hatte mich bereits interessiert, aber ich habe wohl nach den falschen Begriffen gesucht) aber auch hier wieder ist mir das alles nicht wirklich eindeutig. häufig heißt es da, dass die garbage collection meist ausreichend Arbeit leistet. Es geht um langlebige Variablen, soweit klar. Geht es dir um das "null - setzen" von Variablen in Methoden? Oder geht es da nochmal um andere Vorgehensweisen?

Tut mir leid, dass ich nicht so tief in der Materie stecke. An sich arbeite ich immer nach "learning-by-doing" und belese mich, wenn ich auf Probleme stoße. Zumal ich auch eher mit Beispielen etwas anfangen kann, als "sturer Theorie"

MfG

 

[mihe7]

zu zyklischen Abhängigkeiten musste ich mich erst belesen, bin aber nicht wirklich daraus schlau geworden was ich dann ändern sollte. Zumindest würde das was mir dazu einfällt meiner Meinung nach die Übersichtlichkeit beeinträchtigen.

Wenn Du in einem Typ A (z. B. Klasse) einen Typ B verwendest, ist A von B abhängig. Verwendet Typ B jetzt auch Typ A, dann hast Du eine zyklische Abhängigkeit.

große Scopes heißt, das zu oft public verwendet wird, oder? Damit gehe ich um, wie mit dem static.

Der Scope ist der Gültigkeitsbereich. Instanzvariablen sind z. B. innerhalb der Klasse verfügbar, in der sie deklariert wurden. Lokale Variablen nur in dem Block, in dem sie deklariert wurden usw. Wenn man eine Variable, die nur lokal verwendet wird (bzw. werden sollte), als Instanzvariable deklariert, ist der Scope zu groß.

Mal drei Beispiele:

public class A {
    private int i;

    public void ausgabe() {
        for (i = 0; i < 10; i++) {
            System.out.println(i);
        }
    }
}

public class B {
    public void ausgabe() {
        int i;
        for (i = 0; i < 10; i++) {
            System.out.println(i);
        }
    }
}

public class C {
    public void ausgabe() {
        for (int i = 0; i < 10; i++) {
            System.out.println(i);
        }
    }
}

Klasse A: Scope von i ist die Klasse, Klasse B: Scope von i ist die Methode ausgabe (man könnte z. B. nach der Schleife auf i zugreifen), Klasse C: Scope von i ist die Schleife (so ist das richtig).

aber auch hier wieder ist mir das alles nicht wirklich eindeutig. häufig heißt es da, dass die garbage collection meist ausreichend Arbeit leistet.

Okay, hier ist mit Ressource die vom Betriebssystem zur Verfügung gestellte Ressource in Form einer Datei (bzw. eines Handles) gemeint. Die Datei wird geöffnet, aber nicht in jedem Fall wieder geschlossen; das File-Handle wird ggf. erst freigegeben, wenn die JVM beendet wird.

Beispiel:

try {
    BufferedReader reader = new BufferedReader(new FileReader("/pfad/zur/datei"));
    reader.readLine();
    reader.close();
} catch (IOException ex) {
    ex.printStackTrace();
}

Mit reader.close() wird die Ressource wieder freigegeben. Problem an der Geschichte: wenn in reader.readLine() eine Exception auftritt, wird reader.close() nicht aufgerufen. Man kann sich jetzt darauf verlassen, dass reader irgendwann vom GC abgeräumt wird um beim Finalisieren die Datei schon geschlossen wird, sollte man aber nicht unbedingt tun. Zumal in der Zwischenzeit ja weitere Zugriffe auf die Datei erfolgen könnten usw.

Vor Java 7 war das gar nicht mal so einfach, das richtig umzusetzen:

BufferedReader reader = null;
try {
    reader = new BufferedReader(new FileReader("/pfad/zur/datei"));
    reader.readLine();
    reader.close();
} catch (IOException ex) {
    ex.printStackTrace();
} finally {
    if (reader != null) {
        try {
            reader.close();
        } catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

Zunächst muss man den Reader außerhalb des try-Blocks deklarieren (Thema: Scope), weil im finally-Block darauf zugegriffen werden muss. finally ist ein Block, der immer ausgeführt wird, auch, wenn eine Exception ausgelöst wurde. Dort muss nun der reader auf null geprüft werden, schließlich könnte die Exception bereits beim Erstellen des Readers ausgelöst worden sein. Dann muss man den reader schließen, was aber seinerseits zu einer Exception führen könnte, die man dementsprechend abfangen muss.

Mit Java 7 wurde try-with-resources eingeführt, womit das alles sehr einfach wird:

try(BufferedReader reader = new BufferedReader(new FileReader("/pfad/zur/datei"))) {
    reader.readLine();
} catch (IOException ex) {
    ex.printStackTrace();
}

Dieses Konstrukt gibt die Ressourcen von reader ganz automatisch in jedem Fall wieder frei (= schließt den Reader automatisch).

 

[mOiterei]

Wenn Du in einem Typ A (z. B. Klasse) einen Typ B verwendest, ist A von B abhängig. Verwendet Typ B jetzt auch Typ A, dann hast Du eine zyklische Abhängigkeit.


Der Scope ist der Gültigkeitsbereich. Instanzvariablen sind z. B. innerhalb der Klasse verfügbar, in der sie deklariert wurden. Lokale Variablen nur in dem Block, in dem sie deklariert wurden usw. Wenn man eine Variable, die nur lokal verwendet wird (bzw. werden sollte), als Instanzvariable deklariert, ist der Scope zu groß.

Mal drei Beispiele:

public class A {
    private int i;

    public void ausgabe() {
        for (i = 0; i < 10; i++) {
            System.out.println(i);
        }
    }
}

public class B {
    public void ausgabe() {
        int i;
        for (i = 0; i < 10; i++) {
            System.out.println(i);
        }
    }
}

public class C {
    public void ausgabe() {
        for (int i = 0; i < 10; i++) {
            System.out.println(i);
        }
    }
}

Klasse A: Scope von i ist die Klasse, Klasse B: Scope von i ist die Methode ausgabe (man könnte z. B. nach der Schleife auf i zugreifen), Klasse C: Scope von i ist die Schleife (so ist das richtig).


Okay, hier ist mit Ressource die vom Betriebssystem zur Verfügung gestellte Ressource in Form einer Datei (bzw. eines Handles) gemeint. Die Datei wird geöffnet, aber nicht in jedem Fall wieder geschlossen; das File-Handle wird ggf. erst freigegeben, wenn die JVM beendet wird.

Beispiel:

try {
    BufferedReader reader = new BufferedReader(new FileReader("/pfad/zur/datei"));
    reader.readLine();
    reader.close();
} catch (IOException ex) {
    ex.printStackTrace();
}

Mit reader.close() wird die Ressource wieder freigegeben. Problem an der Geschichte: wenn in reader.readLine() eine Exception auftritt, wird reader.close() nicht aufgerufen. Man kann sich jetzt darauf verlassen, dass reader irgendwann vom GC abgeräumt wird um beim Finalisieren die Datei schon geschlossen wird, sollte man aber nicht unbedingt tun. Zumal in der Zwischenzeit ja weitere Zugriffe auf die Datei erfolgen könnten usw.

Vor Java 7 war das gar nicht mal so einfach, das richtig umzusetzen:

BufferedReader reader = null;
try {
    reader = new BufferedReader(new FileReader("/pfad/zur/datei"));
    reader.readLine();
    reader.close();
} catch (IOException ex) {
    ex.printStackTrace();
} finally {
    if (reader != null) {
        try {
            reader.close();
        } catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

Zunächst muss man den Reader außerhalb des try-Blocks deklarieren (Thema: Scope), weil im finally-Block darauf zugegriffen werden muss. finally ist ein Block, der immer ausgeführt wird, auch, wenn eine Exception ausgelöst wurde. Dort muss nun der reader auf null geprüft werden, schließlich könnte die Exception bereits beim Erstellen des Readers ausgelöst worden sein. Dann muss man den reader schließen, was aber seinerseits zu einer Exception führen könnte, die man dementsprechend abfangen muss.

Mit Java 7 wurde try-with-resources eingeführt, womit das alles sehr einfach wird:

try(BufferedReader reader = new BufferedReader(new FileReader("/pfad/zur/datei"))) {
    reader.readLine();
} catch (IOException ex) {
    ex.printStackTrace();
}

Dieses Konstrukt gibt die Ressourcen von reader ganz automatisch in jedem Fall wieder frei (= schließt den Reader automatisch).

Ich danke dir! Das ist eine echt tolle Erklärung. Bzw sind es ja mehrere da mache ich mich dann gleich zeitnah daran das umzusetzen!

Eine Frage dazu aber noch verständnishalber: Wo liegt denn das Problem einer zyklischen Abhängigkeit? Geht es da um zugriffsprobleme? Könnte das also bspw. Mein Problem auslösen?

 

[KonradN]

Wo liegt denn das Problem einer zyklischen Abhängigkeit? Geht es da um zugriffsprobleme?

Die Probleme, die auftreten können, sind vielseitig. Prinzipiell muss es keine wirklichen Probleme geben - auch mit zirkulären Abhängigkeiten kann alles funktionieren. Aber es wird komplexer.

- Es kann Änderungen erschweren. Durch die gegenseitigen Abhängigkeiten zieht eine Änderung meist sehr viel mehr Änderungen mit sich. Wenn Du also A änderst, dann musst Du auch B ändern. Wäre die Abhängigkeit zu B nicht da, dann wäre da nie Änderungsbedarf.

- Die Wiederverwendbarkeit ist eingeschränkt. Wenn Du A nutzen willst, dann musst Du auch B nutzen. Aber das kann eine Einschränkung sein. Beispiel: Dein Daten (Beete) haben eine direkte Abhängigkeit zu einer Swing Klasse, die Beete anzeigt. Dann funktionieren deine Beete nur in einer Swing Anwendung und nur mit genau dieser Anzeige. Du kannst also nicht die Klasse A nutzen um dann unabhängig von B damit etwas anderes zu machen (Also bei dem Beispiel: Plötzlich eine Kommandozeilen Anwendung bauen oder so).

- Es kann auch zirkuläre Abhängigkeiten geben, die zu Henne Ei Problemen führen. Ein A anlegen braucht ein B. Um B anzulegen braucht es ein A. Aber das ist ein sehr konkretes Problem und da kann man dann natürlich auch diverse Lösungen finden. Es erhöht nur eben die Komplexität.

Das kann man aber sehr gut vertiefen. Ein wichtiges Prinzip von den sogenannten SOLID Principles (Das sind wichtige Prinzipien bei Objektorientierter Entwicklung) ist das Single Responsibility Principle und dazu findet sich auch einiges an Erläuterungen mit jeweils vertiefender Lektüre. Aber teilweise halt auch Interface Segregation Principle.

Die Frage ist aber, ob man da jetzt schon das alles so sehr vertiefen will / muss. Denn unter dem Strich wären jetzt erst einmal paar grundlegende Vorgehensweisen umzusetzen. Und die kann man ggf. erst einmal als solche hin nehmen ohne die Begründung im aller Tiefe verstanden zu haben.

 

[mOiterei]

Also ich habe das nun so verstanden, dass nicht nur die Performance sondern auch die Übersichtlichkeit meines Codes vorallem unter den zyklischen Abhängigkeiten und dem Aufbau leidet.
Also bin ich nun dabei zwischen M, V und C aufzuteilen.
Mein Problem nun, dass ich in jeder Klasse die im DataHandler eine Rolle spielt das Interface "Daten" implementiert habe. Dadurch hatte ich die Möglichkeit Art "durchlaufendes Speichern" aufzurufen.
Also: DataHandler#speichern { for (KlasseA ka: KlasseB.get...) {ka.speichern()};}

Ist das eine saubere Lösung oder sollte ich eine Variante ohne Interface wählen?

Desweiteren bin ich mir nun unsicher, ob auch bspw. MouseListener o.ä. Zum Controller oder zum View gehören.

Ich hoffe meine Fragerei wird nicht zu viel, aber das alles ist mir jett wirklich neu und dadurch muss ich einige Aufbauweisen der letzten Jahre neu überdenken und begreifen.