Skip to main content

[JIRA] Created: (JAVAMONEY-59) Isolate Validity Services

  • From: "atsticks (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [JIRA] Created: (JAVAMONEY-59) Isolate Validity Services
  • Date: Sat, 24 Aug 2013 19:27:19 +0000 (UTC)
  • Auto-submitted: auto-generated

Isolate Validity Services
-------------------------

                 Key: JAVAMONEY-59
                 URL: https://java.net/jira/browse/JAVAMONEY-59
             Project: javamoney
          Issue Type: Improvement
          Components: Ext: Provided Extensions
    Affects Versions: 0.4-EDR1
            Reporter: atsticks
            Assignee: atsticks
             Fix For: 0.5


when writing on the spec this morning, I felt not satisfied, with our 
solutions how validities for currencies and regions were handled. Basically, 
with {{ValidityInfo}} and {{RelatedValidityInfo}} we already have a 
generalized solution for the return types. But the accessor methods were 
specific on the {MonetaryCurrencies}} and {{Regions}} singletons.

Therefore I propose(in ext) an additional {{Validities}} singleton, which 
provides validities as required. But I still was not satisfied, since there 
were a lots of access methods that did more or less the same, just varying 
the input parameters a bit. Additionally we also support querying of legal 
tender related validities, which are different than the normal currencies per 
region relation. So I was looking for a more flexible solution and came to 
{{ValidityQuery, RelatedValidityQuery}} and {{ValidityType}}.

The distinction what kind of {{ValidityInfo}} is required, I solved by adding 
a ValidityType value type. By default this is set to 
{{ValidityType.EXISTENCE}}, when a new {{ValidityQuery}} is created, but for 
legal tenders or other use cases may have different values, e.g. 
{{ValidityType.of("legalTender"}}.

Basically I see not many disadvantages, but many *Advantages*:
* Validities are not constrained to currencies and regions anymore, also 
other types can be supported, by simply registering corresponding 
ValidityProviderSpi instances.
* Queries can be extended, when useful (must be supported by the provider 
answering the query of course), so also very complex customer specific use 
cases can be modelled.
* The client API is simple (4 methods only in tota).
* Even bitermporal historization would be possible, by adding an additional 
parameter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[JIRA] Created: (JAVAMONEY-59) Isolate Validity Services

atsticks (JIRA) 08/24/2013

[JIRA] Resolved: (JAVAMONEY-59) Isolate Validity Services

atsticks (JIRA) 08/27/2013
 
 
Close
loading
Please Confirm
Close