Skip to main content
This revision made August 01, 2012 12:39, by keilw

Design principles

  • Value types (Simple immutable types, depending on even simpler immutable types or primitives)
  • Method naming and style in alignment with JSR-310
    • same method name prefixes - of for factories, with for immutable setters, plus/minus etc (and amended if JSR-310 naming is amended)
    • overall API "feel" shold also mirror JSR-310
  • Works acceptably with other JVM languages (Groovy, Scala, Clojure...)
    • Possibly have to align with OpenJDK and other parts like JavaFX (not all but most 310 method names match Groovy, Fantom/JScience or Ceylon, while FX currently doesn't)


Do we want to include the following as a design principle? There is some debate about whether to use factories, why lock it down?

  • No separate factories for the value types
    • specifically, users should be able to write Money.of(30, GBP) or similar. Factories may exist separate to this, but should not be the first design option.
Difference compared to previous revision
'''Design principles''' * Value types (Simple immutable types, depending on even simpler immutable types or primitives) * Method naming and style in alignment with JSR-310 ** same method name prefixes - of for factories, with for immutable setters, plus/minus etc (and amended if JSR-310 naming is amended) ** overall API "feel" shold also mirror JSR-310 * Works acceptably with other JVM languages (Groovy, Scala, Clojure...) ** Possibly have to align with OpenJDK and other parts like JavaFX (not all but most 310 method names match Groovy, Fantom/JScience or Ceylon, while FX currently doesn't) Do we want to include the following as a design principle? There is some debate about whether to use factories, why lock it down? * No separate factories for the value types ** specifically, users should be able to write Money.of(30, GBP) or similar. Factories may exist separate to this, but should not be the first design option.
 
 
Close
loading
Please Confirm
Close