harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][beans] Code seems duplicate for primitive persistence delegate
Date Fri, 13 Jul 2007 21:18:37 GMT
Either way is fine by me.  I don't think there is a significant difference.

Regards,
Tim

Spark Shen wrote:
> 2007/7/12, Alexei Zakharov <alexei.zakharov@gmail.com>:
>>
>> Spark,
>>
>> I don't see many reasons to couple all persistence delegates into a
>> single class. IMO "one  class to one persistence delegate" model is
>> obvious and easy to understand. AFAIU RI implements its persistence
>> delegates in this way. BTW what do you mean by code duplication here?
> 
> 
> For example, looking into the implementation for
> java_lang_BytePersistenceDelegate & java_lang_DoublePersistenceDelegate.
> They both have a instantiate method and an empty initialize method.
> The instantiate method of BytePersistenceDelegate is like:
>        Byte value = (Byte) oldInstance;
>        return new Expression(oldInstance, Byte.class, "new",new Object[] {
> value });
> 
> while the instantiate method of DoublePersistenceDelegate is like:
>        Double value = (Double) oldInstance;
>        return new Expression(oldInstance, Double.class, "new", new Object[]
> { value }); //$NON-NLS-1$
> 
> IMHO, the logic are similar, and can be changed to:
> return new Expression(oldInstance, oldInstance.getClass(),
>                "new", new Object[] { oldInstance });
> The situation exist for other primitive type persistence delegate. They are
> the PDs I listed in my original post.
> 
> The behavior of instantiate() method is unique to each PD and all that
>> we can do is to create a single class with a big big switch that
>> includes the code from all our PDs. Do we really want this?
> 
> 
> I agree with you that a big switch is not a good method. I think we can 
> put
> PrimitiveTypePersistenceDelegate into the persistenceDelegates in class
> initializer instead of a big switch:
>    static PrimitiveTypePersistenceDelegate primitiveTypePD = new
> PrimitiveTypePersistenceDelegate();
>    static {
>        persistenceDelegates.put(int.class, primitiveTypePD);
>        persistenceDelegates.put(double.class, primitiveTypePD);
>        // etc.
>    }
> There is another benefit here: we eliminate type name extraction logic for
> primitive type.
> 
>> IMHO it is
>> not an Object-Oriented way.
>>
>> Sorry if I misunderstand your idea. Please explain in more details if so.
>>
>> Thanks,
>>
>> 2007/7/12, Spark Shen <smallsmallorgan@gmail.com>:
>> > During developing PersistenceDelegate for java.lang.reflect.Field, I
>> find
>> > code duplication in many primitive type persistence delegate.
>> >
>> > There are 8 primitiveType persistenceDelegate:
>> > java_lang_BooleanPersistenceDelegate
>> > java_lang_BytePersistenceDelegate
>> > java_lang_CharacterPersistenceDelegate
>> > java_lang_DoublePersistenceDelegate
>> > java_lang_FloatPersistenceDelegate
>> > java_lang_IntegerPersistenceDelegate
>> > java_lang_LongPersistenceDelegate
>> > java_lang_ShortPersistenceDelegate
>> >
>> > Each of the 8 class has two method: instantiate & initialize, and the
>> logic
>> > of the 2 methods are similar.
>> > IMO, we could use one PrimitiveTypePersistenceDelegate instead to
>> reduce
>> > code duplication.
>> > --
>> > Spark Shen
>> > China Software Development Lab, IBM
>> >
>>
>>
>> -- 
>> Alexei Zakharov,
>> Intel ESSD
>>
> 
> 
> 

Mime
View raw message