Einzelnen Beitrag anzeigen

Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#1

Allgemeines Interface

  Alt 29. Aug 2011, 09:53
Guten Morgen zusammen

Ich weiß nicht so recht, wie ich das Problem denn nennen soll, da ich noch nie so recht mit Schnittstellen gearbeitet habe. Bisher habe ich auch immer recht spezifische Klassen geschrieben, ebenso war das Applikations-Design nicht unbedingt allgemein gehalten. Das wird jetzt nach und nach geändert, ist ja auch im Sinne von OOP

Ich habe im Moment folgende abstrakte "Startup"- und Applikations-Klasse, die ich für meine Anwendungen nutzen will -- TApHandledObject fügt einem TObject via AllocateHwnd nur ein Handle hinzu, um kommunizieren zu können.
Delphi-Quellcode:
TCustomApplicationController = class abstract(TApHandledObject)
private type
  TCustomStartupLoader = class abstract
  public type
    TCustomRequest = class abstract
    end;

    IRequestHandler = interface
      // GUID
      procedure Process(Request: TCustomRequest);
    end;
  private
    FApplicationController : TCustomApplicationController;
    FThread : TThread;
  protected
    procedure Execute(); virtual; abstract;
    procedure Request(Request: TCustomRequest); virtual;
  end;

private
  FStartupLoader : TCustomStartupLoader;
public
  constructor Create(); override;
  destructor Destroy();
end;
Ich habe folgende "Vision": der ApplicationController startet den StartupLoader-Thread der in der Execute-Methode -- asynchron zum MainThread -- alle möglichen Jobs erledigt, die die Anwendung zum Start benötigt: applikationsweite Einstellungen setzen, Log initialisieren, allg. Einstellungen laden, Datenbankverbindung aufbauen, evtl. auch Business-Objekte aus DB laden etc. Während des Startups zeigt der ApplikationsControlelr einen SplashScreen an, oder macht einfach gar nichts.

Was aber, wenn z.B. die Zugangsdaten für die Datenbank nicht korrekt sind? Einfach eine GUI einblenden kann ich ja nicht, da die Jobs ja asynchron zum MainThread laufen. Die Idee hier ist, dass der StartupThread ein Request an den MainThread schickt, dieser den Request entsprechend bearbeitet und eine Antwort zurück schickt.
Code:
MainThread --+--> Zeige SplashScreen ------------> Frage User nach ---------------------------------------> Zeige MainForm
             |                                ^    Zugangsdaten      |                                 ^
             |                                |                      |                                 |
             | Starte                         | Request              | Antwort                         |
             |                                |                      |                                 |
             v                                |                      v                                 |
       StartupThread --> JobA --> JobB --> Problem --> Warten ----------> Problem lösen --> JobC --> Fertig
Und hier will ich nun eine Schnittstelle bauen, die wie folgt agieren soll:
Code:
StartupThread ------------------> ApplicationController ------------------> RequestHandler
                TCustomRequest                           TCustomRequest         |
                                                                                | bearbeitet
                                                      <-------------------------+
                                                        und schickt zurück
Der StartupThread erzeugt ein TCustomRequest-Objekt, welches je nach Problem anders aussieht. In meinem DB-Beispiel beinhaltet dieses z.B. die Eigenschaften: Hostname, Database, Username, Password. Dieses Objekt schickt der StartupThread an den ApplicationController, der wiederrum eine Liste an registrierten Handlern hat und das Objekt an den passenden Handler weiterleitet. Implementiert dieser Handler das Interfac IRequestHandler, so kann der Request bearbeit und zurück an den StartupThread geschickt werden.

Klingt ja alles ganz schön und könnte so auch funktionieren, aber ist das auch okay so? Würdet ihr sowas anders lösen? Gibts Optimierungspotential?
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat