Neue Klasse für TableView?

Lucaaa

Bekanntes Mitglied
Hallo!
Ich habe in meinem Programm eine MainUI Klasse. Wie der Name schon sagt, enthält diese Klasse die UI meines Programms. Jetzt habe ich noch eine TableView, die zur Definierung der Spalten (usw.) relativ viel Code benötigt.
Meine Frage ist nun, ob ich das in eine extra Klasse auslagern soll (die mit TableView erweitert wird), oder sollte ich es alles in einer Klasse machen?
 
Ich glaube das warst sogar du.
Es ging darum, dass für jedes meiner Panels eine eigene Klasse gemacht habe
Die allgemeingültige Regel ist halt: "Es kommt drauf an". Das was in dem einen Kontext richtig war, kann im nächsten völlig falsch sein 😛

Eine eigene Klasse für eine Tabelle klingt es aber sinnvoll, das ist viel Code, der zusammen gehört, aber mit dem Rest nur lose gekoppelt sein sollte.
 
Es ging darum, dass für jedes meiner Panels eine eigene Klasse gemacht habe
Es ging wahrscheinlich darum, dass Du jedesmal von einem Container (ich meine, es wäre JPanel gewesen) abgeleitet hast, anstatt diesen einfach zu verwenden. Das ist etwas völlig anderes.

Sagen wir mal, Du brauchst eine Liste mit ... Namen von Automarken. Dann gehst Du doch nicht her und machst:
Code:
public class Automarken extends ArrayList<String> {
     public Automarken() {
         add("Marke1");
         add("Marke2");
         add("Marke3"); 
         ...
    }
}

Bei Komponenten schalten aber alle erstmal um auf den "extends-Mode" (das "ö" im Klassennamen ist Absicht - der Umlaut-Mode ist auch an):
Code:
public class MeinSchönesPanel extends JPanel {
    public MeinSchönesPanel() {
        add(new JLabel("Label:" ));
        add(new JButton("Button"));
        add(new JTextField());
        ...
    }
}

Du siehst die Analogie?
 
"Es kommt drauf an".
Also wenn ich alles richtig gelesen und verstanden habe gillt folgendes:
Wenn du viel Code für ein Element brauchst, das mit dem Rest des Programms nicht so viel zu tun hat, mache eine eigene Klasse (Beispiel meine Tabelle, die ist nur zur Visualisierung von ausgewählten Dateien, das Programm kommt auch ohne Zugriff auf diese zurecht (fast)

Ansonsten: Lass es!
 
Aber das bedeutet dann auch, dass ich das hier nicht machen sollte
Java:
package com.ludevstudio.filecrypter.core;
import java.io.File;
import java.util.ArrayList;
public class FileManager {
 private ArrayList<File> files;
 
 public FileManager() {
  if(files == null) {
   files =new ArrayList<File>();
  }
 }
 
 // get all files
 public ArrayList<File> getFiles() {
  return files;
 }
 
 // add a file
 public void addFile(File file) {
  files.add(file);
 }
 
 // remove a file based on object id
 public void removeFile(File file) {
  files.remove(file);
 }
 
 // remove a file based on index
  public void removeFile(int index) {
   files.remove(index);
  }
  
  
  
  
}

ich brauche die ArrayList im ganzen Programm...
 
Auf keinen Fall.

Durch das "extends" wird aus Automarken ein Subtyp einer ArrayList, d. h. es wird erklärt, dass gilt: Automarken ist-eine ArrayList. Das ist Unfug.

Zum Beispiel ist folgendes möglich:
Java:
public Automarken getMarken() { ... }

// und irgendwo, an ganz anderer Stelle:
List<String> marken = irgendeinObjekt.getMarken();
Wo ist bei "marken" der Automarken-Typ hin? Futsch. Für den Computer ist das kein Problem, denn das Objekt, das getMarken() zurück liefert, ist eine ArrayList, wie durch "class Automarken extends ArrayList<String>" erklärt wurde.

Dein FileManager dagegen nutzt intern "zufällig" eine ArrayList. Das muss nach außen nicht bekannt sein. Er könnte auch eine LinkedList, eine Datenbank oder sonst was verwenden. Insofern kann auch das List-ähnliche Interface sinnvoll sein.

Noch zwei Nebenbemerkungen zu Deinem FileManager: die null-Prüfung im Konstruktor ist überflüssig (files ist an der Stelle null) und die interne Liste sollte nicht einfach so nach außen gegeben werden, damit ist die Kapselung nämlich futsch.
 
Code:
public class Automarken extends ArrayList<String> {
     public Automarken() {
         add("Marke1");
         add("Marke2");
         add("Marke3");
         ...
    }
}

Java:
package com.ludevstudio.filecrypter.core;
import java.io.File;
import java.util.ArrayList;
public class FileManager {
 private ArrayList<File> files;
 
 public FileManager() {
  if(files == null) {
   files =new ArrayList<File>();
  }
 }
 //irrelevanten code entfernt... 
 
}

Wo siehst du da denn Gemeinsamkeiten?

Der wesentliche Punkt ist das extends ArrayList, welches keinen Sinn hat, aber trotzdem von jedem bei GUI-Componenten genauso gemacht wird
 
aber trotzdem von jedem
Na immerhin etwas. Ich bin nicht der einzige!

Stelle null) und die interne Liste sollte nicht einfach so nach außen gegeben werden, damit ist die Kapselung nämlich futsch.
Ja das mit der null Abfrage ist Mist. Da hatte ich einen gravierenden Denkfehler.
Das wirft dann die Frage auf: Wie kriege ich den FileManager in eine zweite Klasse? Muss ich den Dann übergeben? wie ich möchte auf die Arraylist files zugreifen.

Und das mit der getFiles(): was wäre die bessere Lösung?
 
Wie kriege ich den FileManager in eine zweite Klasse? Muss ich den Dann übergeben?
Klar, ein FileManager-Objekt. Wenn Du nur eines brauchst, dann erstellst Du einfach nur eines und gibst das dann den betreffenden anderen Objekten mit.

ich möchte auf die Arraylist files zugreifen.
Möchtest Du jetzt auf den FileManager oder auf eine Liste zugreifen?

Und das mit der getFiles(): was wäre die bessere Lösung?
Zum Beispiel: return Collections.unmodifiableList(files);
 

Neue Themen


Zurück
Oben