Ich habe eine Permissions -Klasse in Java mit Methoden in fließendem Stil wie folgt:
Die Frage ist, ob ich diese Methoden set{Property} oder nur {property} nennen sollte. Letzteres würde so aussehen:
Wenn ich mir diese Methoden einzeln anschaue, würde ich erwarten, dass read etwas liest, aber andererseits ist es näher an der Absicht, so etwas wie benannte Parameter wie in Scala zu haben:
Dies ist ein klassisches Problem mit fließenden Schnittstellen. Während ich @Bozho zustimme, dass setRead () selbsterklärender ist, besteht das Ziel bei fließenden Interfaces darin, den gesamten "Satz" lesbar zu machen, anstatt einzelne Methodenaufrufe lesbar zu machen.
Ich würde also einen Schritt weiter gehen. Wie wäre es mit:
%Vor%Siehe auch Martin Fowlers Post zu diesem Thema. Er sagt: "Der Aufbau einer solchen flüssigen API führt zu einer ungewöhnlichen API-Angewohnheit"
set{Property} definitiv. Es zeigt an, was die Methode macht. Stellen Sie sich vor, Ihre Immobilie heißt visible oder encoding oder algorithm . Die Verwendung von set macht keinen Sinn.
Sie können aussagekräftigere Aktionsnamen verwenden, die sich vom Namen der Eigenschaft unterscheiden. Zum Beispiel:
visible - & gt; show(..)
encoding - & gt; encode(..)
read & gt; makeReadable(..)
name - & gt; giveName(..) ("name" ist ein Verb, ist aber mehrdeutig)
Die set beeinträchtigt eindeutig die Klarheit. Sie sind nicht wirklich Bohnen-ähnliche Methode, also sage ich es fallenlassen.
Ich würde auch empfehlen, den Builder vom Produkt zu trennen. Bevorzugen Sie Unveränderlichkeit im Produkt.
Wenn Sie Flags haben, denke ich, dass es viel besser ist, boolesche Methoden als Methodenpaare zu verwenden. Die Java-Bibliothek hat diese Änderung von 1.0 auf 1.1 geändert. Trotzdem mag ich Booleans nicht. In true und false gibt es keine wesentlich höhere Bedeutung. enum s sind besser. Besser noch, wenn Sie über etwas sprechen, das als eine Menge betrachtet werden kann (wie im Beispiel), dann verwenden Sie Set (wahrscheinlich als EnumSet implementiert).
Tags und Links scala java fluent-interface naming