Dies ist mehr eine Designfrage als alles andere ...
Ich mag Scalas Fallklassen sehr und benutze sie oft. Ich finde jedoch, dass ich oft in meine Parameter in Options (oder vielmehr Lift Boxes ) einwickle und Standardwerte einstelle, um Flexibilität zu ermöglichen und zu berücksichtigen, dass ein Benutzer nicht immer alle Parameter angibt. Ich glaube, ich habe diese Praxis übernommen.
Meine Frage ist, ist das ein vernünftiger Ansatz? Angesichts der Tatsache, dass alles optional sein kann, kann es eine Menge Vortex und Überprüfung geben, bis hin zu der Frage, ob ich nicht nur meine Fallklassen wie Map[String, Any] benutze und mich frage, ob ich nicht besser dran wäre Map .
Lass mich dir ein echtes Beispiel geben. Hier modelliere ich eine Geldüberweisung:
%Vor% Relativ einfach zu verstehen, denke ich. In diesem einfachsten Fall könnten wir Transaction wie folgt deklarieren:
Ich kann mir schon vorstellen, dass du denkst, es sei ausführlich. Und wenn wir alles spezifizieren:
%Vor% Andererseits, obwohl Sie Full überall herumwerfen müssen, können Sie immer noch einen schönen Mustervergleich durchführen:
Ist das ein vernünftiger Ansatz? Würde ich mit einem Map besser bedient? Oder sollte ich Fallklassen auf andere Weise verwenden? Vielleicht eine ganze Hierarchie von Fallklassen verwenden, um Transaktionen mit unterschiedlichen Informationsmengen darzustellen?
Die Verwendung einer Fallklasse ist weniger flexibel als eine Karte, da Sie nur vordefinierte Felder zuweisen / zuordnen können. Sie müssen zuvor eine vollständige Fallklassenhierarchie erstellen.
Andererseits bietet die Fallklasse eine Art "Kompilierungsvalidierungen", weil alle Typen explizit definiert sind (im Gegensatz zu Map[String,Any] ) und Sie nicht versehentlich ein nicht spezifiziertes Feld zuweisen können. Fallklassen sollten auch schneller sein, da Sie die Map-Hashtable nicht durchlaufen müssen, um das zu finden, wonach Sie suchen.
Das "Ausführlichkeits" -Problem kommt von dem unveränderlichen Aspekt von Fallklassen, aber Sie haben genau das gleiche Problem mit unveränderlichen Karten. Die Lösung scheint Objektive zu sein. Es gibt ein sehr nettes Gespräch hier:
Wenn etwas wirklich optional ist, dann haben Sie wirklich keine andere Wahl. null ist nicht eine Option (kein Wortspiel beabsichtigt).
Ich würde stark jedoch von der Verwendung des Lift-Box-Typs abraten, es sei denn, Sie benötigen es speziell für den Umgang mit Lift-APIs. Sie führen nur eine unnötige Abhängigkeit ein.
Ich würde auch ernsthaft darüber nachdenken, ob es wirklich Sinn macht, eine Amount ohne eine bestimmte Währung zu haben. Wenn gültig ist, würde die Erstellung eines dedizierten "Null-Objekts", das eine nicht näher spezifizierte Währung darstellt, zu einer saubereren API führen:
Alternativ:
%Vor% Für die Unterklassen TransactionSide finde ich es seltsam, dass Sie Currency getrennt von Amount angeben können (was bereits den Begriff der Währung einbettet). Ich würde bevorzugen:
Endlich ...
Ja, verwenden Sie Maps, wenn sie gut zu Ihrer Domain passen. Sie sorgen für viel saubereren Code.
Tags und Links scala map pattern-matching case-class