Use Advanced Search to search the entire archive.
Re: Proposal
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 21:38:59 -0200
If we create a model to do this operations:
/**
* This interface represents operations to Quantity that needs verification
* ( {@link Quantity#divide(Quantity)} and {@link
Quantity#multiply(Quantity)}).
* @author otaviojava
*
* @param <Q> to do the operation with Quantity<Q>
* @param <E> to verify and cast using Class<E>
*/
public interface QuantityOperations<Q extends Quantity<Q>, E extends
Quantity<E>> {
/**
* The {@link Quantity} to do the operations
* @return the quantity to operation
*/
Quantity<Q> getQuantity();
/**
* Class to do the verification
* @return the Class to verification
* @see Unit#asType(Class)
*/
Class<E> getQuantityClass();
}
*In Quantity change the method to:*
<T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
multipy(QuantityOperations<T, E> operation);
*The implementation:*
@Override
public <T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
multipy(QuantityOperations<T, E> operation) {
QuantityOperations<T, E> operation = supplier.get();
return (Quantity<E>) multiply(operation.getQuantity())
.asType(operation.getQuantityClass());
}
I believe this way, we will use the generics and can verify, so everyone
happy [?]
On Sun, Nov 2, 2014 at 7:50 AM, Jean-Marie Dautelle
<
>
wrote:
>
Hello all,
>
>
I understand your points, but I have the feeling that we are making things
>
more difficult than they need to be.
>
>
We should not forget that the main subject is the unit-api not the
>
"quantity-api".
>
>
Let's put ourselves in the shoes of the user and see what he might want to
>
do:
>
>
public void wait(Time delay) { ... }
>
Mass m = parcel.getWeight();
>
>
I would assume that until that point everyone agree... [?]
>
>
Let's go deeper, we might want to do also:
>
>
Length x = ...
>
Time t = ...
>
Velocity v = x.divide(t);
>
>
If we can do that then I believe that even more people will be happy
>
(especially if it does not involve reflection) [?]
>
>
... And YES, it is possible!
>
>
The first thing we see is that some of the quantities interfaces will have
>
extra methods.
>
>
interface Length extends Quantity<Length> {
>
Area multiply(Quantity<Length>); // Overloading.
>
}
>
interface Area extends Quantity<Area> {
>
Volume multiply(Quantity<Length>); // Overloading.
>
}
>
Length x = ...
>
Volume v = x.multiply(x).multiply(x);
>
>
There is no combination explosion since the number of predefined
>
quantities is bounded. Furthermore, all these are convenient (optional)
>
methods, the asType(Class<Q>) method can be used for complex cases.
>
>
The question now is how do we create these Quantity instances?
>
>
For this problem, the abstract factory pattern (GoF) is a perfect fit. All
>
quantities coming from the same factory will work well together and this
>
approach allows for many many optimizations under the hood !
>
>
// Unit-API
>
interface QuantityFactory {
>
Length lengthOf(double, Unit<Length>);
>
Mass massOf(double, Unit<Length>);
>
...
>
}
>
>
// Unit RI
>
abstract class Quantities {
>
public static QuantityFactory DOUBLE = ...;
>
public static QuantityFactory BIG_DECIMAL = ...;
>
}
>
>
Length x = DOUBLE.lengthOf(2.4, METER);
>
Length two_x = x.add(x);
>
Area x_square = x.multiply(x);
>
>
(Note: I would have preferred plus, minus, time, divide but I can live
>
with that [?])
>
>
There is no need for a Measurement class (and MeasurementConverter).
>
>
The quantity base class will be very close to what we have now except it
>
does not implement any interface.
>
>
public interface Quantity<Q extends Quantity> {
>
Unit<Q> unit();
>
Number value();
>
double doubleValue(Unit<Q>); // To avoid boxing/deboxing.
>
Quantity<Q> add(Quantity<Q>);
>
...
>
}
>
>
Of course if we can converge on this solution I would be really really
>
happy (JScience has many types of numbers such as Rational, Complex for
>
which this approach is a perfect fit) !!!
>
>
Best regards,
>
Jean-Marie.
>
--
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


