Strategie Design Pattern, Generics und TypeSafety

8

Ich möchte das folgende Strategie-Muster in Kombination mit Factory erstellen, aber ich möchte, dass es typsicher ist. Ich habe bis jetzt folgendes gemacht:

%Vor%

Im Allgemeinen, was auch immer ich versuche, irgendwo werde ich eine ungeprüfte Besetzung haben. Hat jemand eine Idee, wie ich den Code typsicher gestalten kann?

Prüfe effektives Java Ich bin auch auf dieses Muster gestoßen:

%Vor%

So kann ich jetzt wie Ingo vorgeschlagen

verwenden %Vor%

als

%Vor%

Oder wäre das besser mit enums?

    
ChrisGeo 11.11.2013, 14:39
quelle

3 Antworten

5

Ich würde einfach ein Parser<T> an die getResults() -Methode übergeben und das Fabrik-Zeug vergessen. Schau, wenn du sagst:

%Vor%

Sie versprechen, dass die Methode einen Parser beliebigen Typs erstellt, den der Aufrufer wünscht. Dies ist nur typsicher mit Parsern möglich, die alle eine leere Sammlung zurückgeben. Außerdem können Sie keine Parser<String> von dieser Funktion zurückgeben, da String nicht mit jedem vom Aufrufer gewünschten Typ übereinstimmt.

Wenn Sie jedoch schreiben:

%Vor%

Sie haben genau das, was Sie wollten: Die Methode getResult ist unabhängig von der Funktionsweise des Parsers und gibt dennoch eine Sammlung des richtigen Typs zurück.

Und später statt

%Vor%

Sie sagen:

%Vor%

Das ist Klang und macht Sinn.

    
Ingo 11.11.2013 17:03
quelle
3

Normalerweise verwende ich dieses Format. Ich weiß, dass viele Leute es nicht mögen, aber bisher hat niemand einen besseren Ansatz vorgeschlagen.

%Vor%

Sie können Class Objekte weitergeben, wenn Sie jedes Mal eine neue Instanz wünschen:

%Vor%

Hinweis: Ich bin bestrebt, einen besseren Ansatz zu finden. Wenn Sie also ein paar Gedanken haben, teilen Sie sie bitte in einem Kommentar mit.

    
Adam Arold 11.11.2013 14:44
quelle
3

Ich begrüße Ihren Wunsch, das Strategie-Muster zu verwenden; +1 dafür. Ich denke Ingo's Kommentare sind genau richtig.

Nur ein zusätzlicher Kommentar (aus Effective Java, 2. Ausgabe):

%Vor%

Um Joshua Blochs Worte zu verwenden, "erscheint diese Lösung kompakt und sogar elegant." Es kann jedoch auch zerbrechlich und schwierig zu pflegen sein. Im Allgemeinen sollten Sie versuchen, Enum-Konstanten nicht zu aktivieren, da der Code bei jedem Wechsel der Enumeration bricht.

Dies ist genau der richtige Zeitpunkt, um eine abstrakte Methodendefinition in Ihrer Enumeration zu verwenden und den gewünschten Code genau dort mit der Enum-Konstante zu platzieren. Dies garantiert, dass Sie nie vergessen, den benötigten enum-assoziierten Code zu Ihrem Projekt hinzuzufügen und sicherzustellen, dass jedes Mal, wenn Sie Ihrer enum hinzufügen, dass Ihr Projekt nicht bricht.

Wenn Ihre Ziele dies zulassen, ist es sogar möglich oder ratsam, die gesamte Factory-Methode in Ihr enum zu verschieben und Ihre enum-Klasse die Strategie-Schnittstelle implementieren zu lassen.

    
scottb 11.11.2013 18:12
quelle