Skip to main content
This revision made December 18, 2012 00:13, 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) Platform 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) Platform 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) JDKPlatform 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) JDKPlatform 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
 
 
Close
loading
Please Confirm
Close