Consiglio su struttura JInternalFrame duplicato

[fermat]

ciao!

io ho due JInternalFrame praticamente identici.
uno per gli autori, e uno per gli editori.
ma la struttura grafica è la stessa.
e anche le operazioni che fanno.
in pratica cambiano alcune cose del tipo:
-la scritta sui bottoni (Aggiungi autore o Aggiungi editore)
-alcuni parametri di alcuni metodi (ad esempio il file da cui prendere i dati per riempire le combo; il file è passato come parametro ad un metodo)

quindi: fare due classi separate o fare una classe parametrizzata in modo da impostare le varie cose a seconda del parametro che arriva al JInternalFrame??

[andbin]

quindi: fare due classi separate o fare una classe parametrizzata in modo da impostare le varie cose a seconda del parametro che arriva al JInternalFrame??

Una classe base con configurazione/componenti/logica comune e poi 2 sottoclassi con ciò che è specifico (e/o da ridefinire). Nei costruttori delle sottoclassi puoi configurare ciò che è fisso (es. testo di un pulsante).

Senza conoscere bene il contesto e cosa hai scritto, non saprei però che altro dire.

[fermat]

Una classe base con configurazione/componenti/logica comune e poi 2 sottoclassi con ciò che è specifico (e/o da ridefinire). Nei costruttori delle sottoclassi puoi configurare ciò che è fisso (es. testo di un pulsante).

Senza conoscere bene il contesto e cosa hai scritto, non saprei però che altro dire.

ok, provo a darti qualche dettaglio in più.

in sostanza la finestra si preoccupa di:
-aggiungere un autore / editore -> viene richiamato un web service remoto specifico (aggiungi_autore.php / aggiungi_editore.php), che aggiunge il record sulla tabella corretta
-di listare tutti gli autori / editori presenti -> i dati vengono presi da due file json (autori.json / editori.json)
-di modificare l'autore / editore selezionato nella combo box -> viene richiamato un web service remoto specifico (modifica_autore.php / modifica_editore.php), che modifica il record sulla tabella corretta; al servizio viene passato l'id e il nome; ho due classi che rappresentanto una l'autore e una l'editore (con i getter e setter)
-di cancellare l'autore / editore selezionato nella combo box -> viene richiamato un web service remoto specifico (cancella_autore.php / cancella_editore.php), che cancella il record sulla tabella corretta; al servizio viene passato l'id; ho due classi che rappresentanto una l'autore e una l'editore (con i getter e setter)

le strutture delle tabelle remote sono uguali; cambiano solo i nomi dei campi.
le strutture dei file json sono uguali; cambiano solo i nomi dei campi.
di conseguenza, anche ai servizi remoti passo la stessa quantità di parametri (il nome nel caso di aggiunta; id e nome nel caso di modifica; id nel caso di cancellazione).

[schumy2000]

Nel mio applicativo ho creato una superclasse chiamata InternalFrameParent e tutte le finestre estendeva la classe sopracitata, che a sua volta estendeva JInternalFrame, questo perché tutte le finestre dovevano implementare un comportamento uguale.
Una situazione del genere mi è capitata, ma (forse per fretta) ho fatto tutto in una stessa classe.
Avevo la necessità di aggiornare delle statistiche di un giocatore, ma nella stessa finestra ho fatto anche il modulo dell'aggiunta.
Nella classe in cui richiamo questo modulo passo anche un codice numerico che mi determina la funzione della classe (aggiornamento/aggiunta).

Ciao.

[fermat]

ciao!

sono riuscito solo ora a metterci la testa.
ok avere una classe base, e poi le due sottoclassi che estendono quella.
ma cmq c'è qualcosa che mi sfugge.

il layout generico (bottoni, textfield, ecc) lo imposto nella classe base poi passo il testo come parametro?

oppure, ho questo moetodo:

    private void riempiCombo() {
        comboUpAuthor.removeAllItems();
        comboUpAuthor.addItem("*");
        try {
            ArrayList<Author> listAuthor = jsonRead.getAllAuthors();
            listAuthor.stream().forEach((strAuthor) -> {
                comboUpAuthor.addItem(strAuthor);
            });
        } catch (IOException ex) {
            JOptionPane.showMessageDialog(null, ex.getMessage());
        }
    }

tutto relativo a Author.
poi c'è ne è uguale per Editor.
anche qui, imposto un metodo generico a cui passo dei parametri??

[andbin]

ma cmq c'è qualcosa che mi sfugge.
il layout generico (bottoni, textfield, ecc) lo imposto nella classe base poi passo il testo come parametro?
tutto relativo a Author.
poi c'è ne è uguale per Editor.
anche qui, imposto un metodo generico a cui passo dei parametri??

Guarda che se si tratta di "configurazioni" di valori che restano poi fissi per il resto della durata del frame (es. una dicitura su un pulsante), gli approcci a livello di design sono svariati:

1) I costruttori delle sotto-classi passano al costruttore della super-classe tutti i dati di configurazione. Se i dati sono tanti, come variante si può definire una classe che definisce l'insieme dei dati di configurazione, in modo da passare un solo oggetto.

2) La super-classe espone i campi dei vari componenti comuni (es. JButton ecc..) verso le sotto-classi sfruttando tipicamente/preferibilmente il livello di accesso "protected", in modo che i costruttori delle sotto-classi possano fare tutti i set che vogliono.

3) La super-classe non espone direttamente i campi (che tiene private) ma espone verso le sotto-classi dei metodi (idem, meglio protected) del tipo setTestoPulsanteXyz(String) in modo che i costruttori delle sotto-classi possano fare le impostazioni ma in modo più "controllato".

[fermat]

allora, ho cercato si seguire la terza soluzione.
nella super-classe ho impostato il layout di base, e messo alcuni metodi generici come protected.
ad esempio:

    protected void setTextButtonAdd(String text) {
        btnAdd.setText(text);
    }

    protected void setTextButtonUp(String text) {
        btnUp.setText(text);
    }

    protected void setTextButtonDel(String text) {
        btnDel.setText(text);
    }

    protected void riempiCombo(ArrayList<? extends Object> list) {
        comboUp.removeAllItems();
        comboUp.addItem("*");
        list.stream().forEach((strObj) -> {
            comboUp.addItem(strObj);
        });
    }

il metodo riempiCombo, riempiraà la jcombobox o con oggetti Author o con oggetti Editor (a seconda di quello che mi serve).
poi nella sotto-classe:

public class FrameAuthor extends FrameAEBase {

    private ReadJson jsonRead = new ReadJson();
    private ArrayList<? extends Object> list = null;

    public FrameAuthor() {
        super();
        super.setTextButtonAdd("Aggiungi autore");
        super.setTextButtonUp("Modifica autore");
        super.setTextButtonDel("Cancella autore");
        try {
            list = jsonRead.getAllAuthors();
        } catch (IOException ex) {
            JOptionPane.showMessageDialog(null, ex.getMessage());
        }
        super.riempiCombo(list);
    }
}

a parte il funzionamento (l'ho testato e funziona), può andar bene??

[andbin]

a parte il funzionamento (l'ho testato e funziona), può andar bene??

Grosso modo sì. Ma ci sono alcune cose dubbie.

Innanzitutto cosa fa ReadJson? Non vedo argomenti al suo costruttore e neanche al getAllAuthors. Quindi legge un JSON da cosa/dove e con quale API? Probabilmente è tutto "cablato" nel ReadJson.

Poi non mi piace molto quel ArrayList<? extends Object>. Dovresti cercare di parametrizzare in modo più accurato questa lista. Anche perché in un ArrayList parametrizzato così non puoi inserire nulla (a parte un null letterale). E questo quindi dipende da cosa fa getAllAuthors.

[fermat]

allora, ReadJson ha diversi metodi per la lettura di alcuni file json.
ha un metodo per ogni file json da leggere.
ad esempio, getAllAuthors:

    public ArrayList<Author> getAllAuthors() throws IOException {
        File file = new File(UrlAndPath.JSON_AUTORI);
        ArrayList<Author> list = new ArrayList<>();
        if (file.exists()) {
            Gson gson = new Gson();
            JsonParser parser = new JsonParser();
            try (BufferedReader bf = new BufferedReader(new FileReader(file))) {
                JsonArray jarray = parser.parse(new JsonReader(bf)).getAsJsonArray();
                for (JsonElement e : jarray) {
                    Author au = gson.fromJson(e, Author.class);
                    list.add(new Author(au.id, au.name));
                }
            }
        }
        return list;
    }

il file da leggere, in effetti, è impostato in maniera "fissa", prendendolo da una classe che ha solo delle costanti che uso in varie parti del programma.
come vedi vado a creare un ArrayList<Author> (una cosa simile faccio per gli Editor).

per quanto riguarda ArrayList<? extends Object>, hai ragione.
ma non mi è venuto in mente altro.
perchè al metodo riempiCombo, dovrei passare o ArrayList<Author>, o ArrayList<Editor>, a seconda della sotto-classe che richiamo.

[andbin]

ad esempio, getAllAuthors:
(una cosa simile faccio per gli Editor).

Se in getAllEditors hai usato sostanzialmente lo stesso codice di getAllAuthors ... allora hai creato una duplicazione di logica. Cerca di accentrare quella logica in un solo punto. Cioè la logica: "dato un File JSON con un array dammi un List<T>" la puoi facilmente generalizzare, sfruttando bene le type variable dei generics.

perchè al metodo riempiCombo, dovrei passare o ArrayList<Author>, o ArrayList<Editor>, a seconda della sotto-classe che richiamo.

Sui generics e sul combobox comunque ci sarebbe anche un'altra questione, più importante. Stai usando almeno Java 7 (vedo l'uso del "diamond" <> ) e da Java 7 JList/JComboBox e i relativi model sono diventati "generici". Dato che il comboUp ce l'hai nella classe base .... come hai parametrizzato JComboBox?
Se non ci hai pensato (hai usato il raw-type) o l'hai fatto JComboBox<Object>, sappi che si può fare di molto meglio. Vuoi un indizio?