Umgang mit Klassen mit vielen Versionen, Adapter oder Factory?

8

Ich arbeite mit einer Third-Party-Bibliothek zusammen, die alle drei neue Versionen der gleichen (meist) Klassen enthält -4 Monate. Ich möchte nicht jede Klasse aktualisieren müssen, die sie jedes Mal verwendet, wenn eine neue Version aus ist.

Die Bibliothek ist folgendermaßen strukturiert, wobei der Dienst die Klasse derselben Version verwendet. v201609/myClass v201609/myService v201701/myClass v201701/myService

Ich kann keinen Adapter in den Dienst einfügen, daher muss ich die tatsächliche Klasse erstellen. Um zu veranschaulichen: $myService->handle(new MyClass);

Meine Lösung, wo Fabriken die eigentlichen Klassen verwenden und aufbauen: (MyServiceFactory::build())->handle(MyClassFactory::fromModel($myModel));

Jedes Mal, wenn eine neue Version der Klassen veröffentlicht wird, muss ich alle meine Fabriken aktualisieren.

Fragen:

  1. Ist das der optimale Ansatz für dieses Problem?
  2. Ist Factory die richtige Namenskonvention für diesen Ansatz?
JC Lee 07.01.2017, 12:01
quelle

3 Antworten

2

Das Problem ist, dass sie die Versionsnummer in jeder Position des Namensraums verwenden. Meiner Meinung nach ist deine Lösung nicht so schlecht.

Das Problem ist, wenn Sie möchten Deklaration im Code eingeben , aber das könnte nur einen Nachteil erzeugen. Dann gehts gleich zu Factories . Dann müssen sie alle paar Monate aktualisiert werden.

Autoloader selbst wird dies nicht beheben, da Sie die Klasse noch im Werk deklariert haben. Darüber hinaus möchten Sie das Problem, das Projekt mit der Version zu koppeln, auslassen - im Ergebnis werden Sie die Typdeklaration für diese Objekte auslassen.

Guter Rat ist es, Integrationstests (PHPUnit) zu verwenden, dies wird jedes Problem mit der Datenstruktur nach dem Update finden, Sie werden dies benötigen.

Zweiter Hinweis - im Konstruktor, sende die aktuelle Version zum Laden und benutze das Laden nach dem String-Namen

  

gebe neues $ fullClassName ()

zurück

mit korrektem Klassennamen und Version. Dann werden Sie das nur in Ihrer Konfigurationsdatei für eine gegebene Fabrik ändern. Verwenden Sie use nicht für nachfolgende Klassen.

Ich hoffe, dies wird Ihr Problem vollständig lösen.

    
timiTao 15.05.2017 14:24
quelle
1

Aus meiner Sicht ist dieses Namespacing-System lächerlich. Sie veröffentlichen ihre Bibliothek mit einem Versionstag, und darin enthaltene Klassen sind nur diese Version. Wenn Sie sich für ein Upgrade entscheiden, erhalten Sie nur eine Version. Wie jede andere Bibliothek.

So, jetzt habe ich dieses System gespuckt, wie kann ich es reparieren?

Eine Lösung besteht darin, einen Ereignishandler in Composer zu verwenden, z. B. post-package-update , um die letzte Versionsnummer in eine Datei zu speichern. Dann liest Ihre Fabrik diese Datei und lädt die richtige Version der Bibliothek

    
JesusTheHun 26.06.2017 14:57
quelle
1

Meiner Meinung nach liegt Google hier falsch. Sie verwenden semantisches Tagging in ihrem GitHub-Repo, was sie also den Leuten sagen sollten, ist, die richtige Version mit Composer anstelle ihrer schlechten Lösung zu installieren, wobei die neueste getaggte Version auf github 3 oder 4 ältere Versionen enthält in einem Namespace-Ordner.

Nachdem Sie das gesagt haben, ist Ihre Idee gar nicht so schlecht. Ein schnelles Suchen und Ersetzen würde auch funktionieren.

Ich würde ein Problem auf ihrem Github ansprechen und erklären, warum sie das Git & amp; Komponieren Tags!

    
delboy1978uk 26.06.2017 15:33
quelle

Tags und Links