Aloah...

ich habe mich in letzter Zeit ein wenig mit den verschiedenen Software Pattern beschäftigt. Unter anderem auch mit dem Factory Pattern. Im Internet habe ich hierzu mehrere Beispiele und Erklärungen gefunden. Anhand dieser Beispiele unter Erklärungen habe ich versucht ein eigenes Beispiel zu programmieren.

Mich würde nun Interessieren ob in meinem Beispiel das Factory Pattern korrekt umgesetzt ist (oder auch nicht) und ob Verbesserungen vorgenommen werden müssten.

Nach meinem Verständnis geht es beim Factory Pattern ja darum, dass der Client (in meinem Fall soll dies die Klasse TAppStore sein) keine Ahnung von dem Konkreten Produkt (TSoftwareApp und deren Ableitungen) hat mit dem er arbeiten soll. Das Konkrete Produkt bekommt er ja über eine Subklasse (in meinem Fall die Klassen TOfficeApps / TAppleApps) erstellt/mitgeteilt, die für Ihn das konkrete Produkt erstellt.

Die Klassenstruktur habe ich als Anhang diesem Post hinzugefügt.


Anbei noch eine beispielhafte implementierung:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TfrmPattern.DoFactoryPattern;
var
  SL : TStringList;
  Store : TAppStore;
begin
  SL := TStringList.Create;
  try
    Store := TAppStore.Create(astMicrosoft);
    try
      try
        Store.BuySoftwareApp(atText, SL);
      except
        on E:Exception do
          MessageDlg(E.Message, mtError, [mbOk], 0);
      end;
      try
      Store.BuySoftwareApp(atPresentation, SL);
      except
        on E:Exception do
          MessageDlg(E.Message, mtError, [mbOk], 0);
      end;
    finally
      Store.Free;
    end;
    ShowMessage(SL.Text);
  finally
    SL.Free;
  end;
end;

Wie bereits erwähnt würde micht Eure Meinung zur Art und Weise meiner Umsetzung interessieren...

Macht generell mehr Sinn zusammen mit Interfaces.

Wenn es eine Factory ist, dann nenn es doch auch im Code so 😉

TSoftwareApps -> TAppFactory
TAppleApps -> TAppFactoryApple
TOfficeApps -> TAppFactoryMicrosoft

Das Beispiel mit dem Office-Programmen kommt mir bekannt vor.

Du bist wirklich ein Freund von enums. Mein persönlicher Geschmack wäre es nicht. Für mich ist es noch zu früh am morgen, aber spontan denke ich dass man mit einem

markieren

Code:

TAppFactory
------------
+ createCalculation(): TSoftwareApp
+ createPresentation(): TSoftwareApp
(...)

besser fährt als mit

markieren

Code:

TAppFactory
----------
+ createApp(enum TAppType): TSoftwareApp

Grade wenn man beispielsweise von deinem TAppleApps oder TOfficeApps weitere Unterklassen bilden würde (z.B. TOfficeEvaluationApps das nur Demo-Versionen liefert) müsste man die Case-Statements aus der Überklasse mitschleppen, kopieren, abändern. Fehleranfällig wenn da später geändert wird. Hat man einzelne Methoden für jeden Typ hat man das Problem nicht.


Bzgl. Testbarkeit würde ich auch in der Anwendungsklasse TAppStore davon abrücken hier ein enum zu geben, sich lokal eine in TAppStore.Create(..) hartverdrahtete Factory zu erstellen. Gib ihm nicht ein Enum, gib ihm die fertige Factory.

Ja.
Es würde auch Sinn machen wenn Du erläuterst was du mit "Factory Pattern" meinst. Erst dann kann man entscheiden ob es "korrekt umgesetzt ist".
Dein "Im Internet habe ich hierzu mehrere Beispiele und Erklärungen gefunden." ist etwas arg unspezifisch.
Meinst du eines von den beiden?
https://de.wikipedia.org/wiki/Abstrakte_Fabrik
https://de.wikipedia.org/wiki/Fabrikmethode

Aus dem Quelltext geht aufgrund der "Familie" von Office-Produkten hervor dass es die abstrakte Fabrik ist.

Ich hoffe der Post kommt jetzt nicht doppelt... Da ich meine Antwort aber nicht sehe, gehe ich davon aus das beim Post versuch etwas schief gelaufen ist...

Zitat von Rollo62:

Macht generell mehr Sinn zusammen mit Interfaces.

Vielen Dank für den Link. Den werde ich mir mal anschauen...

Zitat von freimatz:

Ja.
Es würde auch Sinn machen wenn Du erläuterst was du mit "Factory Pattern" meinst. Erst dann kann man entscheiden ob es "korrekt umgesetzt ist".
Dein "Im Internet habe ich hierzu mehrere Beispiele und Erklärungen gefunden." ist etwas arg unspezifisch.
Meinst du eines von den beiden?
https://de.wikipedia.org/wiki/Abstrakte_Fabrik
https://de.wikipedia.org/wiki/Fabrikmethode

Eigentlich wollte ich eine normales "Factory Pattern" abbilden. Beim einlesen habe ich hauptsächlich mit den folgenden beiden Links gearbeitet:
https://www.philipphauer.de/study/se...ory-method.php
http://www.nickhodges.com/post/Delph...e-Factory.aspx

Das ich hierbei jetzt schon Richtung "Abstract Factory Pattern" abgedriftet bin, war mir so nicht bewusst...

Zitat von Der schöne Günther:

Wenn es eine Factory ist, dann nenn es doch auch im Code so 😉
TSoftwareApps -> TAppFactory
TAppleApps -> TAppFactoryApple
TOfficeApps -> TAppFactoryMicrosoft

Vielen Dank für den Hinweis. Meine Klassen habe ich entsprechend deinen Vorschlägen umbenannt.

Zitat von Der schöne Günther:

Du bist wirklich ein Freund von enums. Mein persönlicher Geschmack wäre es nicht. Für mich ist es noch zu früh am morgen, aber spontan denke ich dass man mit einem

markieren

Code:

TAppFactory
------------
+ createCalculation(): TSoftwareApp
+ createPresentation(): TSoftwareApp
(...)

besser fährt als mit

markieren

Code:

TAppFactory
----------
+ createApp(enum TAppType): TSoftwareApp

Grade wenn man beispielsweise von deinem TAppleApps oder TOfficeApps weitere Unterklassen bilden würde (z.B. TOfficeEvaluationApps das nur Demo-Versionen liefert) müsste man die Case-Statements aus der Überklasse mitschleppen, kopieren, abändern. Fehleranfällig wenn da später geändert wird. Hat man einzelne Methoden für jeden Typ hat man das Problem nicht.

Bei deinen Vorschlägen bezüglich der "Create" Methoden stehe ich grad ein wenig auf dem Schlauch...
Meinst Du es so, dass die TAppFactory nicht mehr über den Enum die zu erstellende TSoftwareApp ermittelt, sondern das eine Methode exakt die TSoftwareApp erstellt die benötigt wird? Wenn ich das so richtig Verstanden habe, an welcher Stelle muss dann geprüft bzw. entschieden werden welche TSoftwareApp erstellt werden soll?

Zitat von Der schöne Günther:

Aus dem Quelltext geht aufgrund der "Familie" von Office-Produkten hervor dass es die abstrakte Fabrik ist.

Verstehe ich zwar nicht, aber egal. Ich verstehe nicht mal wozu mach so eine abstrakte Fabrik braucht.
Wir haben in unserer Software zig Fabriken. Wenige davon sind Fabrikmethoden, die meisten jedoch eigene Fabrikklassen. Diese sind jedoch nicht abstrakt sondern konkrete. Zur Unterscheidung gibt es einen Key, oft ist das ein enum.
Oft gibt es noch eine Registry, die konkreten Klassen registrieren sich dort mit Ihrem Key. Die Fabrik sucht dann mit dem Key in der Registry und erzeugt die entsprechenden Klasse.

Zitat von freimatz:

Zitat von Der schöne Günther:

Aus dem Quelltext geht aufgrund der "Familie" von Office-Produkten hervor dass es die abstrakte Fabrik ist.

Verstehe ich zwar nicht, aber egal. Ich verstehe nicht mal wozu mach so eine abstrakte Fabrik braucht.
Wir haben in unserer Software zig Fabriken. Wenige davon sind Fabrikmethoden, die meisten jedoch eigene Fabrikklassen. Diese sind jedoch nicht abstrakt sondern konkrete. Zur Unterscheidung gibt es einen Key, oft ist das ein enum.
Oft gibt es noch eine Registry, die konkreten Klassen registrieren sich dort mit Ihrem Key. Die Fabrik sucht dann mit dem Key in der Registry und erzeugt die entsprechenden Klasse.

Hast Du hierfür mal ein Beispiel wie Ihr das abbildet?

Hilft dieser Thread vielleicht weiter?

Zitat von DeddyH:

Hilft dieser Thread vielleicht weiter?

Vielen Dank für den Link, werde ich mir morgen dann mal anschauen...