Zitat von
stOrM:
Die Basisklasse TUpdateEngine soll beim Create prüfen, um welches Zielbetriebssystem es sich handelt.
Wenn das erledigt ist, sollen nur die Funktionen und Proceduren aus dem Publicteil von aussen ansprechbar sein, die auch zum Zielbetriebssystem passen.
Das wäre doch gerade der falsche Weg.
Ziel muss es sein die Unterschiede zwischen den Windows-Versionen quasi "glattzubügeln".
Hierbei kann das
Strategie-Designpattern helfen.
Es gibt dann folgende Klassen:
* TWindowsUpdater (Basisklasse der drei folgenden Klassen)
* TWinXP
* TWinVista
* TWin7
* (TWin8)
Dann gibt es noch eine Faktoryklasse:
Delphi-Quellcode:
TWindowsUpdaterFactory=class(TObject)
class function CreateWindowsUpdaterObj:TWindowsUpdater;
end;
Die Faktoryklasse erzeugt passend zum Betriebssystem ein TWinXP, TWinVista oder TWin7-Objekt.
Zuletzt gibt es noch die Klasse TUpdateEngine.
Diese Klasse bekommt von Aussen ein Objekt der Klasse TWindowsUpdater zugeteilt.
Innerhalb von TUpdateEngine gibt es keine If-Abfragen oder Case-Anweisungen die sich auf das Betriebssystem beziehen.
Sämtlicher Code der irgendwie Betriebssystemabhängig arbeitet ist in die TWindowsUpdater Unterklassen gewandert.
Vergleiche das skizzierte System mal mit dem Konzept der Druckertreiber.
Niemand der bei klarem Verstand ist würde heutzutage für jeden Druckertyp eine Druckroutine schreiben.
Stattdessen gibt es eine Menge von Operationen, die vom jeweiligen Druckertreiber umgesetzt werden.
Die Anwendung spürt so gut wie nichts davon, auf welchem Drucker sie ihre Ausgaben macht.