Skip to main content

Re: AbstractQuantity's class

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: AbstractQuantity's class
  • Date: Wed, 17 Sep 2014 04:23:07 -0300

Another proposal is, remove the factory methods in AbstractQuantity, remove
the public in the class and make it visibla just to the package, and create
the QuantityFactory:

I saw some advantagens:


   - Hide the implementations
   - Just show the API
   - the client don't need know the implementation
   - Single responsability to factory - now one class will do that
   - the AbstractQuantity follows the SOLID principle


On Tue, Sep 16, 2014 at 3:55 AM, Werner Keil 
< >
 wrote:

> That's along the lines of similar ones in JDK or JavaMoney;-)
> Would you avoid the of() method in concrete classes to solve Otavio's
> Problem/question?
>
> As Anatole is at Hackergarten, we can probably offer him to join if he
> wants.
>
> Cheers,
> W
> Am 16.09.2014 08:07 schrieb "Jean-Marie Dautelle" 
> < >:
>
> Hello,
>> Quantities would not extends any class, its purpose is to provide static
>> factory method. Starting with Java 8, interface may have static factory
>> (but Java 8 it is not your target).
>> I would stay away from static factory method, except to get the "quantity
>> factory" (cf. unit of measurement 6.x api):
>>     MyQuantityFactory.getInstance().newQuantity("10 m");
>> Cheers,
>> JM
>>
>>
>> On Tue, Sep 16, 2014 at 12:37 AM, Werner Keil 
>> < >
>> wrote:
>>
>>> Sorry but it is not the answer to the question you askd, there is no
>>> practice (see JSR 354) like MonetaryAmounts.of() or Collections.of().
>>>
>>> Those are merely facade methods, a Quantities extends AbstractQuantity
>>> makes no sense, it is just wrong.
>>> Seems we probably need Hackergarten or the community to ask them for the
>>> right name. It certainly is not Quantities based on all other APIs.
>>>
>>> Beside, if we start putting such facades like Quantities into the RI,
>>> where does that leave the SPI elements or how wold it use them?
>>>
>>>
>>>
>>> On Tue, Sep 16, 2014 at 12:28 AM, Werner Keil 
>>> < >
>>> wrote:
>>>
>>>> What exactly should "Quantities" be, a facade like "MonetaryAmounts",
>>>> etc. from JavaMoney??
>>>>
>>>> If it was to replace BaseQuantity, that is not a name for a concrete
>>>> class I'm afraid. The TemporalAmount used in JSR 310 is actually a
>>>> TemporalAmounts (since it represents more than a single amount) but if we
>>>> had
>>>> Quantities extends AbstractQuantity or
>>>> Quantities implements Quantity??
>>>>
>>>>
>>>> java.util.Collections does not implement java.util.Collection either,
>>>> it is merely a facade, no need for an of() there[?]
>>>> So what you suggested would be a facade along the lines of what Anatole
>>>> mentioned, but it cannot replace AbstractQuantity.
>>>>
>>>> Class.of() returns an instance of that class, so a Quantities facade
>>>> could offer a method like
>>>>
>>>> Quantities.getQuantityFactory(), but it  can't extend or implement
>>>> Quantity, nor return a Quantity as such via of().
>>>>
>>>> Regards,
>>>> Werner
>>>>
>>>> On Mon, Sep 15, 2014 at 11:40 PM, Jean-Marie Dautelle <
>>>>  >
>>>>  wrote:
>>>>
>>>>> Hi All,
>>>>> Indeed, JScience use Amount but with a different semantics (using that
>>>>> same name would create for me a headache due to name clashing).
>>>>> It should be noted that Amount has to be a class (not an interface) in
>>>>> order to provide static factory method (Java 7).
>>>>> Usually (at least in JScience), you will have something like Amount
>>>>> (interface) and Amounts with terminating s for the class holding static
>>>>> factory method to produce Amount instances.
>>>>> But since you intend to return Quantity types, I would suggest using
>>>>> Quantities.of(100d, SI.METRE) - That would be consistent with standard
>>>>> practices.
>>>>> Best regards,
>>>>> Jean-Marie.
>>>>>
>>>>>
>>>>> On Mon, Sep 15, 2014 at 9:51 PM, Werner Keil 
>>>>> < >
>>>>> wrote:
>>>>>
>>>>>> Dear Experts,
>>>>>>
>>>>>> If you don't see a conflict between a more general "Amount" class
>>>>>> here and other types in different value-oriented APIs like JSR 354, we 
>>>>>> may
>>>>>> take the inspiration by the likes of JScience or ICU4J, both using 
>>>>>> *Amount
>>>>>> for such types.
>>>>>>
>>>>>> ICU4J combines it with things like "Currency" in
>>>>>> http://icu-project.org/apiref/icu4j/com/ibm/icu/util/CurrencyAmount.html
>>>>>> the other concrete class is even called "TimeUnitAmount", but I would
>>>>>> not really see any of those as proper additions either.
>>>>>>
>>>>>> How do you intend to use the "faster" quantity sub-types, currently
>>>>>> all returned by factory methods in AbstractQuantity?
>>>>>> The "Amount" type like e.g. that in ICU4J (there it is named Measure,
>>>>>> but unlike JSR 363 it does not separate between API and 
>>>>>> implementation, so
>>>>>> everything are classes) holds a Number, so in theory using different
>>>>>> concrete number sub-classes would work for
>>>>>> Amount.of(100d, SI.METRE) as opposed to
>>>>>> Amount.of(BigDecimal.TEN, SI.METRE) could handle that all.
>>>>>>
>>>>>> What about alternate classes with a lower footprint, especially in
>>>>>> SE? Actually they might matter more, but if using objects like Double,
>>>>>> Integer or Long worked equally well under ME, we could and should keep 
>>>>>> that
>>>>>> in sync, with the exception of BigDecimal/BigInteger[?]
>>>>>>
>>>>>> Martin, others WDYT?
>>>>>>
>>>>>> Regards,
>>>>>> Werner
>>>>>>
>>>>>> On Mon, Sep 15, 2014 at 9:07 PM, Otávio Gonçalves de Santana <
>>>>>>  >
>>>>>>  wrote:
>>>>>>
>>>>>>> Amount.of() sounds good.
>>>>>>> On Sep 15, 2014 4:04 PM, "Legrand, Karen" 
>>>>>>> < >
>>>>>>> wrote:
>>>>>>>
>>>>>>>>  -1 for QuantityAmount.  It looks very odd to have two nouns that
>>>>>>>> are essentially synonyms together like that. I think it would be much
>>>>>>>> better to use either ‘Quantity’ or ‘Amount’ by itself.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Leonardo Lima 
>>>>>>>> [mailto: ]
>>>>>>>> *Sent:* Monday, September 15, 2014 10:44 AM
>>>>>>>> *To:* 
>>>>>>>> 
>>>>>>>> *Subject:* Re: AbstractQuantity's class
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> QuantityAmount sounds redundant, doesn't it?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 14, 2014 at 9:03 PM, Otávio Gonçalves de Santana <
>>>>>>>>  >
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Actually I would like to work this and in Lambda expressions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Could be QuantityAmount then?
>>>>>>>>
>>>>>>>> anyone?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 14, 2014 at 6:06 PM, Werner Keil 
>>>>>>>> < >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Since we drop the .org domain soon, I would not call that UOMo (the
>>>>>>>> Eclipse project certainly will keep the name, after all it also 
>>>>>>>> support
>>>>>>>> UCUM which has another .org domain, too)
>>>>>>>>
>>>>>>>> Why would Quantities get an of() method? What would be imaginable
>>>>>>>> is some sort of factory/facade in RI or SE, but except a
>>>>>>>> getInstance(Length.class) similar to the current QuantityFactory 
>>>>>>>> class
>>>>>>>> (it's a singleton returning exactly one instance here, see MEEP or 
>>>>>>>> CLDC8,
>>>>>>>> they also use both of() and getInstance() for each purpose, just 
>>>>>>>> like Josh
>>>>>>>> Bloch explained) there is nothing to be of() in this case.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> QuantityAmount sounds like a good alternative of these, let's see
>>>>>>>> at JavaOne, probably in Hackergarten what's best.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 14, 2014 at 9:01 PM, Otávio Gonçalves de Santana <
>>>>>>>>  >
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> I am not referring if the classe be or not be abstract or design,
>>>>>>>> but just the name, I am talking about the nomenclature.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Could be a good name:
>>>>>>>>
>>>>>>>>    - UOMO.of(...)
>>>>>>>>
>>>>>>>>  another one is:
>>>>>>>>
>>>>>>>>    - Quantities.of(...)
>>>>>>>>
>>>>>>>>  or the classic:
>>>>>>>>
>>>>>>>>    - QuantityAmount.of(...)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 14, 2014 at 2:51 PM, Werner Keil 
>>>>>>>> < >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sorry, no more Measurable, please
>>>>>>>>
>>>>>>>> We've been there once.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> You bet Spring was probably created a while ago and may not follow
>>>>>>>> all patterns we may see now
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Something else e.g. QuantityAmount<Q extends Quantity> extends
>>>>>>>> AbstractQuantity<Q> is worth considering, like in UOMo.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> And the subsequent of() methods may be on such a concrete class.
>>>>>>>>
>>>>>>>> If you look at let's say the Collections API, it shows a similar
>>>>>>>> pattern of
>>>>>>>>
>>>>>>>> Interface > AbstractBaseClass > ConcreteClass.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This "author" may not have done everything consistently there, see
>>>>>>>> EnumSet, but other than that it is still a better piece of API than 
>>>>>>>> let's
>>>>>>>> say 310 with hundreds of methods on final classes that are largely
>>>>>>>> incompatible and a TemporalAmount which actually should be called
>>>>>>>> TemporalAmounts, TemporalAmountCollection or whatever
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 14, 2014 at 8:32 AM, Werner Keil 
>>>>>>>> < >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sorry but we had that confusion with JSR 275, so ONE Measurement is
>>>>>>>> enough, we must not have Measure implements Measurement, that would 
>>>>>>>> just be
>>>>>>>> a mess.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> JScience called that "Amount", but you see a lot of very popular
>>>>>>>> projects (SpringFramework) doing exactly the same. There are
>>>>>>>> Abstract*.valueOf() or similar constructions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>>   Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
>>>>>>>> Lead | Eclipse UOMo Lead, Babel Language Champion | Apache
>>>>>>>> Committer | Java Godfather
>>>>>>>>
>>>>>>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | 
>>>>>>>> #Java_Social
>>>>>>>> | #DevOps
>>>>>>>>
>>>>>>>> Skype werner.keil | Google+ gplus.to/wernerkeil
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC
>>>>>>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to
>>>>>>>> Life Science and the Internet of Everything"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * JavaOne 2014: Sep 30, San Francisco, USA, Werner Keil, JCP EC
>>>>>>>> Member, JSR 354 EG Member will host "Java and Digital Currencies, 
>>>>>>>> Friend or
>>>>>>>> FOE"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP
>>>>>>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E'
>>>>>>>> class DevOps", "JSR 363"
>>>>>>>>
>>>>>>>> * ApacheCon Europe: 17 Nov 2014, Budapest, Hungary. Werner Keil,
>>>>>>>> JCP EC Member, Apache DeviceMap Committer will present "Apache
>>>>>>>> DeviceMap"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg,
>>>>>>>> Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will
>>>>>>>> present "Apache DeviceMap" (GER)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 14, 2014 at 12:29 PM, Otávio Gonçalves de Santana <
>>>>>>>>  >
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi Guys.
>>>>>>>>
>>>>>>>> How is going?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I believe we have a possible problem with nomeclature in
>>>>>>>>  AbstractQuantity's class, looking this example:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Quantity<Length> metre = AbstractQuantity.of(10, SI.METRE);
>>>>>>>>
>>>>>>>> Quantity<Length> foot =  metre.to(US.FOOT);
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> IMHO, Abstract* is not a good name to a factory, maybe just
>>>>>>>> Measure, so will:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Quantity<Length> metre = Meansure.of(10, SI.METRE);
>>>>>>>>
>>>>>>>> Quantity<Length> foot =  metre.to(US.FOOT);
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> WDYF?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>
>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>
>>>>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>>>>>
>>>>>>>> 55 (11) 98255-3513
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>
>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>
>>>>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>>>>>
>>>>>>>> 55 (11) 98255-3513
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>
>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>
>>>>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>>>>>
>>>>>>>> 55 (11) 98255-3513
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>
>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>
>>>>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>>>>>
>>>>>>>> 55 (11) 98255-3513
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> It is not the strongest of the species that survives, nor the most
>>>>> intelligent. It is the one that is most adaptable to change. - Darwin's
>>>>> Origin of Species (digest)
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> It is not the strongest of the species that survives, nor the most
>> intelligent. It is the one that is most adaptable to change. - Darwin's
>> Origin of Species (digest)
>>
>


-- 
Otávio Gonçalves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
55 (11) 98255-3513

GIF image

GIF image

GIF image

GIF image

GIF image



RE: AbstractQuantity's class

(continued)

RE: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Jean-Marie Dautelle 09/15/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Jean-Marie Dautelle 09/16/2014

Re: AbstractQuantity's class

Werner Keil 09/16/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014
 
 
Close
loading
Please Confirm
Close