Programmstruktur so akzeptabel?

[diggaa1984]

hi,

ausgehend von diesem Thread (Singleton-Diskussion) und von folgenden Codeschnipsel von Marco13 aus diesem Thread:

class DataModelEvent 
{ 
    ... 
} 


interface DataModelListener 
{ 
    void dataAdded(DataModelEvent event); 
} 


public class DataModel { 
    
        private List<DataModelListener> dataModelListeners = ... 
        // add/remove-Methoden für DataModelListeners 

   public void addData(String name, int age) 
        { 
                .... 
                fireDataAddedEvent(....); 
   } 


        private void fireDataAddedEvent(....) 
        { 
            DataModelEvent dataModelEvent = new DataModelEvent(....); 
            for (DataModelListener dataModelListener : dataModelListeners) 
            { 
                dataModelListener.dataAdded(dataModelEvent); 
            } 
        } 
    
} 

class DataModelView implements DataModelListener 
{ 
    public void dataAdded(DataModelEvent event) 
    { 
        schreibDenKramInEineJListOderSonstwohin(); 
    } 
}

wollte ich meine Blamage mit dem Singleton für den Datenzugriff mal in Griff bekommen ^^

folgende grobe Idee:

DataStorageT beinhaltet dabei die zu bearbeitenden Daten (Liste von Personendaten).
MyConcreteListener müsste nun die jeweilige GUI-Komponenten beinhalten (MyConcreteListener sei hier stellvertretend für mehrere Klassen zu betrachten).

Ist die Variante so einigermaßen gut gewählt? Im Prinzip will ich bei Änderung der Daten durch eine Komponente (sei es durch Menü oder Buttons, oder Änderungen in einer Tabelle, welche ausschlaggebend für ComboBox-Inhalt sein könnte) die anderen Komponenten updaten (Listen, Tabelle, ComboBoxen, was auch immer ich da reinbaue).

2. Hätte ich nun die Möglichkeit die Listener-Implementierung auf 2 arten von Komponenten zu nutzen.
Zum einen könnte ich jede erdenkliche Komponente als Listener implementieren, und somit nur die Events bearbeiten die für die Komponente nötig sind (was ich aber als Overhead ansehe, da bei jedem Event alle Komponenten prüfen würden ob das Event sie betrifft).

Andere Variante: Ich benutze ein CardPanel, welches ich alleinig auf dem MainFrame platziere. Innerhalb dieses CardPanels wird immer nur ein Panel (quasi eine Card) angezeigt, welches dann alle nötigen Komponenten enthält, die ich zu diesem Zeitpunkt sehen möchte. Ein Wechsel der Ansicht bedarf dann nur noch dem Wechsel des zu sehenden Panels auf dem CardPanel. Ich könnte diese Cards als Listener implementieren, sodass diese bei einem Event prüfen welcher Art dieses ist, und entsprechende Komponenten informieren. Somit hab ich das Eventhandling zentral in der Card-Klasse liegen, was die ganze Sache aufblähen könnte, aber es existiert kein Overhead mehr wie im 1. Fall, da nun nur noch die Komponenten angesprochen/aktualisiert werden, für welches das Event bestimmt ist.

Vielleicht n bissel konfus, aber 2. Variante is mir zwecks des Overheads die Bessere.
Wenn noch was unklar ist, einfach melden ;D


EDIT: ob nun (angelehnt an 2. variante) nur die Listener das Interface kennen sei ma eben dahingestellt, ändern kann man die Datenstruktur ja auch von nem Menü, welches ja nichts zu aktualisieren braucht

 

[Marco13]

Grundsätzlich ist das jetzt IMHO nicht verkehrt. Man müßte ggf. noch genauer wissen, welche Möglichkeiten es gibt, vom GUI aus die Daten zu manipulieren. Man könnte evtl. noch einen Controller zwischen das GUI und die eigentlichen Daten schalten, aber häufig verschmelzen GUI und Controller (durch anonyme innere Klassen etc.), und durch das IDataStorage hat man eigentlich schon viel Flexibilität (d.h. die GUI kennt ja das konkrete DataStorageT nicht, sondern ruft nur methoden des Interfaces auf). Nicht ganz klar ist auch, wie die Daten im GUI angezeigt werden. Je nachdem, was alles an "Daten" vorhanden ist, könnte man schon durch "feingranularere" Methoden im IMyListener, oder durch irgendwelche IDs für die Events erreichen, dass man weiß, WAS genau upgedatet werden soll. Aber "jede erdenkliche Komponente als Listener implementieren" ist sicher nicht Sinn der Sache. Man hat irgendwelche Daten, und überlegt sich dann eine GUI-Komponente, die eine Ansicht auf diese Daten darstellt. Und (nur) DIE registriert sich als Listener. Dass die noch unterkomponenten enthalten wird, ist klar. Plakativ: Wenn man als Daten eine Liste mit 10 Einträgen hat, und die Einträge als Button-Beschriftungen darstellen will, würde man natürlich nicht 10 "DataListenerButton extends JButton implements SomeListener" erstellen, sondern EINE "DataViewThatDisplaysAllTheStuffInButtons extends JPanelOderSonstwas implements TheListener".

 

[diggaa1984]

Grundsätzlich ist das jetzt IMHO nicht verkehrt.

Kommt ja von dir die Variante.

Man müßte ggf. noch genauer wissen, welche Möglichkeiten es gibt, vom GUI aus die Daten zu manipulieren.

Im Prinzip gibt es eine Tabelle welche alle Daten beinhalten wird (Personen und deren spezifische Infos).
Die Datenstruktur (Anzahl der Personen und Art der Infos (quasi Attribute)) können ebenfalls verändert werden (zB über Buttons oder Menüs). Mehr eigentlich schon nicht.

Nicht ganz klar ist auch, wie die Daten im GUI angezeigt werden.

Da gehts mir nicht anders ... also prinzipiel wird es eine Tabelle geben, Listen und ComboBoxe für diverse Wahlmöglichkeiten. Später bestimmt noch son Spezialding wie "Steckbrief"-Komponente, welche dann ein Foto und grundlegende Infos der Person enthält.

Je nachdem, was alles an "Daten" vorhanden ist, könnte man schon durch "feingranularere" Methoden im IMyListener, oder durch irgendwelche IDs für die Events erreichen, dass man weiß, WAS genau upgedatet werden soll.

Hatte ich mir auch schon gedacht, aber genauere Gedanken dazu kommen dann später. Wollte erstmal das Prinzip abhaken