Konzeptfrage: Interface oder Messages

[stahli]

Ich finde das schwierig.

Ich würde Dein Hauptmenü als Navigation bezeichnen.
Eventuell könnte man das in Form eines PageControls darstellen.
So kann der User in verschiedene Bereiche wechseln/navigieren.

Die Liste von PKWs würde ich nicht als Navigation bezeichnen, sondern als Master-Datenmenge.
Wenn dort ein Eintrag selektiert wird könnten neben der Liste Details in einem eigenen Bereich dargestellt werden.

Es wird also von außen nach innen immer detaillierter.
Dabei gäbe es aber keine Kommunikation von innen nach außen.
Durch Bewegen innerhalb des PageControls und innerhalb der Master-Listen werden dann einfach andere Detaildaten eingeblendet.

Offenbar willst Du etwas anderes erreichen, aber das habe ich noch nicht verstanden.

[Ghostwalker]

@stahli

Mit Master/Detail hast du schon nicht ganz unrecht. Wichtig ist im wesentlich das Master möglichst unabhängig von Detail ist und umgekehrt.

Master-PKW ist der gleiche wie Master-LKW und Master-Hoverboard. Die Details (oder besser das eigentliche Kernobject des Bereichs) sind aber unterschiedlich.

Beispiel:

MASTER hat immer 3 (Daten)-Element: id,status,text zur Darstellung.

Je nach Detail (PKW,LKW,Hoverboard) haben sie z.T. aber ganz andere Bedeutungen.

Beispiel zum Beispiel:

Der Master weiß, das er bei id xyz den Status grün anzeigen soll. Was "grün" bedeutet,
weiß er nicht (ist ihm auch egal).

Je nach Detail heißt "grün" aber bei einem PKW "Reifendruck ok", beim LKW "Druckluftkessel ok" und
beim Hoverboard "Akku voll" (hat weder Reifen noch Bremsen )

Ich kann also für PKW,LKW,Hoverboard den gleichen Master verwenden, obwohl es unterschiedliche Daten sind.

Dazu muss der Master aber mit Detail kommunizieren.

Master sagt Detail : Bearbeite Element mit ID xyz

Umgekehrt muss Detail aber auch mit Master kommunizieren:

Detail sagt Master : Neues Element mit ID abc Status:blau und Text: Wupti eingefügt.

[stahli]

Ok, langsam wird es klarer.

Drei grundsätzliche Fragen noch:

1) Die Liste von PKW und die Liste von LKW, liegen die persistent in Objekten vor oder werden die direkt über eine TTable aus einer Datenbank geholt?

2) Gibt es im Projekt immer fix eine PKW-Liste und immer eine LKW-Liste oder soll der User sich nach Bedarf beliebige Listenansichten erzeugen können? Ich hatte eine Eingangsfrage noch so verstanden.

3) Hast Du schon mal mit Interfaces gearbeitet?

[Ghostwalker]

@stahli

Zu 1)

Sie werden zur Laufzeit über entsprechende Objekte aus der DB zur Verfügung gestellt.


Zu 2)

Dynamisch. Der User bekommt Sortier-/Filterfunktionen. Daher auch entsprechende List-Objekte

Zu 3)

Jap. Zwar bisher eher im kleinen Rahmen, aber die grundsätzlichen Sachen hab ich kapiert

[Ghostwalker]

und noch ein wenig Code zum Beispiel, in welche Richtung hier meine Gedanken gehen:

Dat Interface:

Delphi-Quellcode:

TYPE
   TMasterData = record
                  id : integer;
                  status : integer;
                  text : String;
   end;

   IDetail = INTERFACE;

   IMaster = Interface
     PUBLIC
       function getItem(index:integer):TMasterData;
       procedure setItem(const index:integer;const data:TMasterdata);
       Property Items[index:integer]:TMasterData read getItem write setItem;

       procedure setDetail(element:IDetail);
       Property Detail:IDetail write setDetail;

       Procedure NewElement(data:TMasterdata);
       Procedure DeleteElement(data:TMasterdata);
   End;

   IDetail = Interface
     PUBLIC

       Procedure SetMaster(element:IMaster);

       Property Master:IMaster write setMaster;

       Procedure AddNew();
       Procedure Edit(id:integer);
       procedure Delete(id:integer);
   End;

Da Master

Delphi-Quellcode:

uses
   MyInterfaces;

TYPE
  PMasterdata = ^TMasterdata;

  TNavi = class(TObject,IMaster)
    PRIVATE
       datalist : TList;
    PROTECTED
       :
       :
       :
    PUBLISHED
       :
       :
       :
    PUBLIC

      function getItem(index:integer):TMasterData;
      procedure setItem(const index:integer;const data:TMasterdata);
      Property Items[index:integer]:TMasterData read getItem write setItem;

      procedure setDetail(element:IDetail);
      Property Detail:IDetail write setDetail;

      Procedure NewElement(data:TMasterdata);
      Procedure DeleteElement(data:TMasterdata);
  end;

Ein PKW

Delphi-Quellcode:

uses
  MyInterface;

TYPE
  TPKW = Class(TObject,IDetail)
    PRIVATE
       ffarbe : Tcolor;
       fleistung: Integer;
       fmarke : TPKWMarke;
       fstatus: integer;
       fid : integer;

    PROTECTED
    PUBLISHED
      property Farbe:TColor read ffarbe write ffarbe;
      property Leistung:integer read fleistung write fleistung
      property Marke : TPKWMarke read fmarke write fmarke
      Property ID:integer read fid write fid;
    PUBLIC
     Procedure SetMaster(element:IMaster);

     Property Master:IMaster write setMaster;

     Procedure AddNew();
     Procedure Edit(id:integer);
     procedure Delete(id:integer);

  End;

Ein Hoverboard

Delphi-Quellcode:

uses
  MyInterface;

TYPE
  THoverboard = Class(TObject,IDetail)
    PRIVATE
       fid : integer;
       fstatus : integer;
       fname : string;
       fflughoehe : integer;
       fakkuleistung : double;

    PROTECTED
    PUBLISHED
      Property ID:integer read fid write fid;
      property Status: integer read fstatus write fstatus;
        :
        :
    PUBLIC
     Procedure SetMaster(element:IMaster);
     Property Master:IMaster write setMaster;

     Procedure AddNew();
     Procedure Edit(id:integer);
     procedure Delete(id:integer);

  End;

Nur mal zur Verdeutlichung grob hingezimmert.

[stahli]

Ok, ich würde das über Observer angehen.

Listboxen können sich z.B. bei einer PKW-Liste registrieren.
Wird etwas in der Liste geändert, werden alle Beobachter informiert und werden sich daraufhin neu zeichnen.
Die Einträge einer Liste wiederum können sich als Beobachter bei einem Datenobjekt eintragen.

Eine Detailview kann sich bei einer Liste anmelden und wird informiert, wenn sich ihr aktueller Eintrag verändert.
Die View kann sich dann das aktuelle Objekt von der Liste abrufen (es muss nicht die ID sein, weil ja ohnehin dort ein Objekt vorliegt) und seinen Inhalt neu zeichnen.

Wird dort ein Wert des Datenobjektes geändert, muss das nicht die View an die Listbox melden weil ja die Listboxitems schon ihr Datenobjekt beobachten und sich bei Änderungsinformationen ohnehin neu zeichnen.

Also müssen i.d.R. die Controls untereinander kaum kommunizieren (außer die Meldung einer Liste an angemeldete Views bei einem Recordwechsel, da die aktuell ausgewählte Recordzeile nichts im Datenmodell zu suchen hat).


Ob Du Die Observerliste über Interfaces oder Objekte (vielleicht mit gemeinsamen Basisklassen) organisierst ist Geschmacksache.
Ich würde jedenfalls die gegenseitige Abhängigkeit der Controls möglichst gering halten.


NACHTRAG:

Zitat von Ghostwalker:

Umgekehrt muss Detail aber auch mit Master kommunizieren:

Detail sagt Master : Neues Element mit ID abc Status:blau und Text: Wupti eingefügt.

Wenn Du in der Detailview einen Eintrag hinzufügen oder löschen willst, dann muss diese View auch die ObjektListe von der Listbox abrufen. Sie muss aber dann nicht die Listbox informieren, wenn Sie ein Add oder Delete ausführt, da die Liste selbst ihre Beobachter über Änderungen informiert. Ok, für die nachträgliche Synchronisation des aktuellen Records kann eine Abstimmung Sinn machen.
Aber über die Beobachterliste kann man ja alle Interessenten anschauen und entscheiden, welche Informationen diese erhalten sollen.

Interfaces muss man hierbei nicht verwenden. Es bringt ein paar Vorteile, aber auch mehr Aufwand.

[Ghostwalker]

Öhmmm......ok.....ich hab mal gemalt.

Dabei sind die schwarzen Verbindungen der Datenfluss.
Die grünen mein Ansatz.
Die roten dein Vorschlag.

(Ich hoffe ich hab dich da richtig Verstanden).

Nochmal im Detail

Zitat:

Listboxen können sich z.B. bei einer PKW-Liste registrieren.
Wird etwas in der Liste geändert, werden alle Beobachter informiert und werden sich daraufhin neu zeichnen.

Jo das ist logisch

Zitat:

Die Einträge einer Liste wiederum können sich als Beobachter bei einem Datenobjekt eintragen.

Ähmm.....nö. Wie schon gesagt wird die Liste direkt aus der DB gefüllt/erzeugt, je nach Sort/Filter. Dem zufolge ist die Liste ein Datenobject (soweit ich das verstanden hab)

Zitat:

Eine Detailview kann sich bei einer Liste anmelden und wird informiert, wenn sich ihr aktueller Eintrag verändert. Die View kann sich dann das aktuelle Objekt von der Liste abrufen (es muss nicht die ID sein, weil ja ohnehin dort ein Objekt vorliegt) und seinen Inhalt neu zeichnen.

Öhm, das wär sinnig für den Fall, das der Datensatz der Detailview aufgrund von Filter aus der Liste
rausfliegen würde. Mehr würde da aber auch nicht drüber laufen. Da die Liste nicht alle Daten eines Datensatzes hat, kann die Detailview auch ihre daten nicht von der Liste bekommen. Wär auch nicht grad sinnig, den Hauptspeicher mit den ganzen Datensätzen zu zupflastern.

Zitat:

Wenn Du in der Detailview einen Eintrag hinzufügen oder löschen willst, dann muss diese View auch die ObjektListe von der Listbox abrufen. Sie muss aber dann nicht die Listbox informieren, wenn Sie ein Add oder Delete ausführt, da die Liste selbst ihre Beobachter über Änderungen informiert. Ok, für die nachträgliche Synchronisation des aktuellen Records kann eine Abstimmung Sinn machen.
Aber über die Beobachterliste kann man ja alle Interessenten anschauen und entscheiden, welche Informationen diese erhalten sollen.

Ok...mal sehen ob ich das so richtig verstanden hab.

Die Detailview übergibt die (eingegeben) Daten an ihr Datenobjekt (einzelner, kompletter DS), dieses Informiert seine Beobachter (u.a. die Datenliste) über die Veränderung. Die Datenliste wiederum informiert den Listview, das er sich neu zeichnet.

hmmm....

[Ghostwalker]

Ok..nach dem ich da nochmal in mich gegangen bin hab ich das jetzt glaub ich verstanden (ignorier einfach die roten und grünen Linien...passen nicht).

Aber letztlich würde das Observer-Pattern hier nur die "Richtung" ändern (statt linksrum, rechtsrum )

Aber worum es mir eigentlich ging ist mehr die Implementierung. Eben ob Interfaces oder Messages (via PostMessage/SendMessage), oder wie auch immer.