Konzeptfrage: Gleiche Codebasis, Kundenspezifische Anpassung

[Andreas H.]

Hallo,

wir haben eine Software erstellt, die für eine Werkzeugmaschine die NC-Programme vom Server auf die Steuerung kopiert und dort auswertet, welche Werkzeuge benutzt werden.

Nun haben verschiedene Kunden auch verschiedene Anforderungen, was die Auswertung und die Anzeige des Auswertungsergebnis angeht. Die Anzeige erfolgt in einer ListView.
Da die Anwendung relativ tief in die Steuerung eingebunden ist, verbietet sich die Anzeige weiterer Fenster. Die Anwendung hat nur das Hauptformular.

Ich möchte nicht für jeden Kunden ein eigenes Projekt pflegen müssen. Für jeden Kunden sind nur die Listview und ein paar Funktionen/Prozeduren anzupassen, wobei die zum Teil in Klassen (eigene Units) ausgelagert sind.

Aus der Hüfte geschossen würde ich das mittels bedingter Kompilierung erschlagen. Dann müsste ich die Listview dynamisch erzeugen.

Wie würdet ihr so etwas realisieren?

Gruß Andreas

[Bernhard Geyer]

Entweder ein Pluginsystem entwerfen oder per Konfiguationsdatei das Verhalten steuern.

[Der_Unwissende]

Da würde ich Bernhard zustimmen.
Bedingte Kompilierung wird schnell etwas unschön (und unübersichtlich), da man dann immer gucken muss, was sich in welchem Scope befindet und wann mitkompiliert wird. Das mit dem Plugin-System kannst Du aber auf ähnliche Art und Weise umsetzen. Zum Beispiel eine abstrakte Klasse / ein Interface schaffen, in dem die Methoden, die sich unterscheiden können abstrakt sind. Für jeden Kunden kannst Du dann eine Implementierung entwerfen.
In Deinem Projekt kannst Du dann mittels dem Factory-Pattern entscheiden, welche Implementierung verwendet werden soll.

Gruß Der Unwissende

[Andreas H.]

OK,

abstrakte Klassen, Interface: gehört habe ich diese Begriffe schon.

Und was ist Factory-Pattern?

Habt ihr kontrete Beispiele parat?

Gruß Andreas

[Der_Unwissende]

Zitat von Andreas H.:

abstrakte Klassen, Interface: gehört habe ich diese Begriffe schon.

Ok, abstrakt sind Methoden, die einfach noch nicht implementiert werden. Du legst die Signatur (name, Parameter, Rückgabewert) fest und sagst eben, dass diese Methode in dieser Klasse existiert, die Implementierung jedoch lässt Du weg. Erst die Nachfahren (die erben von dieser Klasse) implementieren dann diese Methoden. Hier solltest Du Dir einfach die Objekt Orientierte Programmierung (OOP) anschauen, dann wird Dir der Nutzen schnell klar.
Einfach gesagt sind die erbenden Klassen nur spezieller als die Elternklasse. Das heißt, überall wo Du eine Instanz der Elternklasse verwenden kannst, kannst Du erst recht einen Nachfahren verwenden, da die Funktionalität erhalten bleibt.
Am Beispiel:

Delphi-Quellcode:

type 
  TElternKlasse = abstract class(TObject) // Vor Delphi 2006 das abstract an dieser Stelle weglassen
    public 
      procedure doFoo; virtual; abstract; // hier ist virtual; abstract; unabhängig von der Delphi Version
  end; 

  TNachfahreA = class(TElternKlasse);
    public 
      procedure doFoo; override;
      procedure doA;
  end; 

  TNachfahreB = class(TElternKlasse);
    public 
      procedure doFoo; override;
      procedure doB;
  end; 
...

procedure TNachfahreA.doFoo;
begin
  ShowMessage('Nachfahre A wurde gewählt');
end; 

procedure TNachfahreB.doFoo;
begin
  ShowMessage('Nachfahre B wurde gewählt');
end; 

...

Und dann eben bei der Nutzung:

Delphi-Quellcode:

var vk: TVorfahrKlasse;
    na: TNachfahreA;
begin
  na := TNachfahreA.Create;
  na.doFoo; // zeigt den Dialog mit A 
  na.doA; // funktioniert, denk Dir eine Implementierung aus
  na.Free;

  vk := TNachfahreA.create;
  vk.doFoo; // zeigt den Dialog mit A 
  vk.doA; // wird nicht gefunden, da vk vom Typ TVorfahrKlasse! 
  vk.Free;
  
  vk := TNachfahreB.create;
  vk.doFoo; // zeigt den Dialog mit B
  vk.Free;

  // sollte nicht klappen, immer böse!!!
  vk := TVorfahrKlasse.Create;
  vk.doFoo; // spätestens hier gibt es eine Exception, da keine Implementierung bekannt ist!
  vk.Free;
end;

Das wichtige ist dabei, dass Du zwar eine Instanz von NachfahreA und NachfahreB erzeugst, die behandelst Du aber beide nur als TVorfahrklasse. Das siehst Du halt daran, das vk zwar Instanzen von TNachfahreA/B zugewiesen werden, nutzen kannst Du aber nur das, was die Klasse TVorfahrKlasse an Funktionalität zusichert. Zudem kannst Du nur mit den Nachfahren arbeiten, die die Methode doFoo (bzw. alle abstrakten Methoden) auch implementieren.

Das ganze kannst Du dann auch in Deinem Projekt nutzen. Du schaffst einfach eine Klasse, die eben das Werkzeug steuert und eine Ausgabe auf der TListView vornehmen kann. Aufbauend auf dieser Klasse kannst Du die Codebasis erzeugen, die greift einfach auf die Methoden der Basisklasse zurück. Die Methoden, die sich für unterschiedliche Kunden unterscheiden kannst Du dabei einfach als abstrakt definieren. Für jeden Kunden erzeugst Du dann einen Nachfahren, in dem Du nur noch diese abstrakten Methoden überschreibst.
Bleibt noch das Problem, dass Du für jeden Kunden eine Instanz des richtigen Nachfahren erzeugen musst. Nimm einfach das Beispiel mit Nachfahre A und B. Allgemein kannst Du ein Programm entwerfen, dass eben die Methode doFoo von TVorfahrklasse verwenden möchte (die könnte ja z.B. etwas auf der Listview ausgeben). Allgemein wird also nur eine Klasse verwendet, die diese Methode implementiert (wie ist egal). Du weißt auch wann die Methode aufgerufen wird, was sie macht hängt von der konkreten Implementierung ab.

Nun kommt das Fabrikmuster/Factory Pattern (einfach mal googlen) ins Spiel. Dabei handelt es sich um ein Design-Pattern der Gang of Four (GoF). Es handelt sich eben um eine Fabrik, die Dir eine Instanz erzeugt. Eine Fabrikmethode gibt Dir typischer Weise die Instanz einer Klasse zurück, die eben alles abstrakte implementiert. Für das Beispiel köbnnte eine Fabrik Dir also eine Instanz von TVorfahrKlasse zurückgeben. Der Vorteil ist, dass die Fabrik von der tatsächlichen Implementierung abstrahiert. Du rufst einfach nur die Fabrikmethode auf und ob die Fabrik Dir nun eine neue TNachfahreA, TNachfahreB oder sonst was zurück gibt ist egal.
So kannst Du die gleiche Codebasis für alle Kunden verwenden und musst nur darauf achten, dass die Fabrik abhängig vom Kunden die korrekte Klasse instanziiert (was nur noch Änderungen an einer einzigen Klasse bedingt). Dies kannst Du dann, wie von Bernhard vorgeschlagen, z.B. über eine Konfigurationsdatei steuern (oder auch durch bedingte Kompilierung).

[Andreas H.]

OK Unwissender hört sich gut an.

Ich erstelle eine VK, die die verwendeten Funktionen deklariert.
Ich erstelle für jeden Kunden eine NA, die die in der VK deklarierten Funktionen mit Leben füllt.
In der Anwendung deklariere ich die Klasseninstanzen mit der VK und rufe den Creator der NA auf.

Verstehe ich das mit der Fabrik so, dass ich eine Funktion schreibe, die in Abhängigkeit des Kunden die die richtige Instanz liefert?

Delphi-Quellcode:

case Kunde of
  Kunde1: VK:=TNKKunde1.create();
  Kundex: VK:=TNKKundex.create()
else VK:=nil
end

Je öfter ich Deinen Text lese, desto mehr denke ich, dass das genau das ist, was ich suche!

Ich versuche es mal umzusetzen.

Gruß Andreas

[Der_Unwissende]

Zitat von Andreas H.:

Verstehe ich das mit der Fabrik so, dass ich eine Funktion schreibe, die in Abhängigkeit des Kunden die die richtige Instanz liefert?

Korrekt! Die Fabrik stellt eben eine Methode zur Verfügung und gibt in der VK zurück (abhängig vom Kunden).

Fabriken können natürlich auch noch einiges mehr, z.B. könntest Du auch ein Singleton-Pattern dahinter verstecken, könntest eine Depency Injection oder andere Initialisierungen vornehmen. Deshalb lohnt es sich, dass Du Dir die OOP und insbesondere auch (die davon unabhängigen) Design Pattern anschaust. Da es von denen eine ganze Menge gibt, konzentrier Dich auf die der GoF und selbst dort muss man nicht alle ständig im Kopf haben! Die Begegnen Dir nur häufiger mal und die sind echt wertvoll!
By the way, als Beispiel würden mir auch Bernhard Geyers zahllose und gute Verweise auf das Brückenmuster für die Entkopplung des DBS vom Programm einfallen. Aber das nur nebenbei.

[Bbommel]

Hallo,

ich habe eine ähnliche Problemstellung und finde die Anregungen hier dazu super - vielen Dank dafür.

Was ich mir schon überlegt hatte und was sich ja prinzipiell mit euren Vorschlägen kombinieren ließe: Wäre es nicht sinnvoll, diese angepassten Klassen in eine bpl-Datei auszulagern? Dann brauch ich bei Kunden, bei denen individuelle Anpassungen nötig sind, nur dessen individuelle bpl auszutauschen und alles ist gut, oder?

Wobei ich, im Unterschied zu Andreas, in diesen Anpassungen nicht auf die VCL zugreifen müsste, was das ganze vielleicht machbar machen sollte...

Ich wäre mal an Rückmeldungen dazu interessiert.

Bis denn
Bommel

[Andreas H.]

Vielen Dank,

Das habe ich verstanden und der Weg scheint richtig zu sein.

Dazu muss ich natürlich meine Klassen etwas umorganisieren.

Werde wohl den Threat warmhalten!

Gruß und Danke Andreas

[Andreas H.]

Hallo,

hier noch ne Frage:

Wie funktioniert das Ganze, wenn eine Klasse eine weitere Klasse instanziert und beide sind kundenspezifisch?
Dann muss die Factory in jedem Konstruktor realisiert sein?