Skip to main content
This revision made December 18, 2012 00:11, by keilw

Design principles

  • Value types (Simple immutable types, depending on even simpler immutable types or primitives)
  • Method naming and style in alignment with java.util.Currency, where applicable BigDecimal, unless otherwise recommended by (Oracle) JDK Architects
    • same method name prefixes - getInstance() for factories, other operations modeled after BigDecimal to the extent it makes sense. See JavaFX or other APIs.
    • overall API "feel" shold mirror BigDecimal, unless otherwise recommended by (Oracle) JDK Architects
  • Works acceptably with other JVM languages (Groovy, Scala, Clojure...) most do with java.util.Currency, or BigDecimal, thus integration will be similar.
    • Possibly have to align with OpenJDK and other parts like JavaFX


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.getInstance(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 java.util.Currency, where applicable BigDecimal, unless otherwise recommended by (Oracle) '''Design principles''' * Value types (Simple immutable types, depending on even simpler immutable types or primitives) * Method naming and style in alignment with JSR-310JDK Architects ** same method name prefixes - ofgetInstance() for factories, wiotherth f opeor rations immutabmodeledle se aftters, plus/mter Binus gDetc (ecimal to the exteandnt ait makes semendnsed. if JSR-310 See nJamingvaFX isoramothended)r APIs. ** overall API "feel" shold mirror BigDecimal, unle ** overall API "feel" shold alsoss motherwise irrrecommended by (Oracle)or JSR-310 JDK Architects * Works acceptably with other JVM languages (Groovy, Scala, Clojure...) most do with java.util.Currency, or BigDecimal, thus integration will be similar. * 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 ** Possibly have to align with OpenJDK and other parts like JavaFX ... 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.getInstance(30, GBP) or similar. Factories may exist separate to this, but should not be the first design option.
 
 
Close
loading
Please Confirm
Close