Originariamente inviato da andbin
Poi se il tuo table model deve essere usabile da altri bisogna vedere cosa gli altri si aspettano. Si aspettano un classe chiamata espressamente TabellaDati?
Sì, si aspettano espressamente una classe chiamata TabellaDati, che estenda AbstractTabellaDati. Direttive del professore...

Ora ho riguardato meglio il tuo codice postato prima. Ci sono diverse cose che non mi piacciono. Non mi piace quel metodo statico getTabellaDati in AbstractTabellaDati che lancia deliberatamente UnsupportedOperationException. Non ha senso ... se si invoca un metodo statico sul nome di una classe astratta generalmente è perché ci si aspetta di ricevere una istanza di una implementazione "concreta" (singleton o creata ogni volta è un altro discorso).
Prendi per esempio java.util.Calendar (classe astratta). Puoi invocare i metodi statici getInstance(), getInstance(Locale), ecc... e ti danno una istanza di una implementazione concreta (qui nella maggior parte dei casi, salvo per Locale "particolari", sono dei GregorianCalendar, sottoclasse concreta).

Quindi quel tuo metodo statico ha poco senso. Poi l'hai messo anche in TabellaDati, ma non è un overriding!! (per essere precisi è un "hiding") Quindi non centra nulla direttamente con quello in AbstractTabellaDati.
La classe AbtractTabellaDati non è modificabile, è scritta dal professore e deve rimanere identica...

Inoltre il fatto che la struttura dati è "di classe" e non di istanza non è proprio molto bello, se puoi ripensaci sopra.
E il fatto che l'assegnazione dei dati veri e propri è "cablata" con quel SerieA.getSerieA(), beh, potrebbe essere sensato (per quello che vi siete posti) ma sarebbe stato più bello se fosse stato stabilito uno standard più appropriato per assegnare i dati.
Ci ripenseremo su... non piace troppo nemmeno a me, ma non sono il solo nel gruppo.

Che vuol dire??
tableChanged è il metodo in TableModelListener e lo implementa solo chi vuole ricevere notifiche dei cambiamenti nel table model. JTable in primis lo implementa e gli serve appunto per riceve le notifiche e aggiornarsi in modo tempestivo/appropriato di conseguenza.

Se tu vuoi implementare un TableModelListener e registrarlo sul table model per qualche motivo, es. logging, notifica all'utente con una dialog che dica es. "Riga X modificata", ecc... sei libero di farlo.
Ma non capisco cosa vuol dire "universale", visto che appunto chiunque lo può implementare e per farci quello che vuole.
È esattamente quello che mi chiedo anche io, ma non saprei dire di più. Questo è quello che ho capito! Il client deve occuparsi di fornire un TableModelListener da registrare sulla propria tabella, e la libreria si occupa di notificarlo con un TableModelEvent.
Io personalmente, dovendomi attenere a queste specifiche ho fatto così:
la classe ClientGrafico (di cui una versione vecchia è lì sopra) implementa TableModelListener, e quindi definisce un metodo TableChanged.... VUOTO. Non sarebbe la prima volta che il professore richieda escamotage del genere giusto per far vedere che hai capito come dovrebbe funzionare (cosa che, a dire il vero, non è proprio vera... il mio progetto FUNZIONA, ma sono ancora confuso). La soluzione PER LA MIA LIBRERIA è perfetta. Nel senso che per come volevo io il progetto, funziona tutto. La libreria si aggiorna correttamente, e non esiste valore da inserire nelle celle editabili che metta in difficoltà la tabella.
Ma, a parola del professore, devo pensare a implementare il metodo tableChanged() in modo che funzioni con qualsiasi altra libreria, qualsiasi tipo di TableModelEvent gli venga passato insomma, anche se tutto ciò per la mia libreria è completamente inutile.
Se non mi sono spiegato bene è perché anche io non ho capito bene...