Jeff,

Thanks for the reply. I know not everyone likes the immutable pattern, but I have found it tremendously useful and cuts down on a lot of synchronized behavior because it creates thread-safe access. I am not promoting its use for everything, but because I have quite a few classes which do this, I have constantly found this a problem when using iBATIS.

How would a ResultObjectFactory solve this problem? I read up on it, but can you give me exactly what you're thinking?

Thanks,
Paul

Jeff Butler wrote:
First thought - ugh. I really don't care for domain classes being built this way. We did it once and it really didn't solve anything. If a programmer wants to break the immutability, it is a simple matter to cast the interface to the mutable implementation. So it's just a lot of hassle for no benefit. (BTW - I know this is promoted in the Sun blueprints catalog, but I still think it's awful. But that's just my 2 cents - YMMV) Second thought - if you really want to do this, you can code a ResultObjectFactory and supply the concrete implementations yourself. Jeff Butler


On 1/14/07, *Paul Benedict* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    I have this problem currently in iBATIS 2. I would prefer it be solved
    in 2.4, but if it is more extensive in scope, then I wouldn't mind
    seeing it pushed off to version 3.

    Here are two classes which have two immutable interfaces:
    interface A {          class AImpl implements A {
      String getName();      String getName();
    }                        void setName(String name);
                           }

    interface B {          class BImpl implements B {
      A getA();              A getA();
    }                        void setA(A a);
                           }

    At the moment iBATIS cannot create a BImpl because the get/setA
    methods
    are returning the interface signature (not the concrete mutable
    class).
    Even though iBATIS will call setA with an AImpl, it forgets the
    implementation and cannot find setName on the returned object.

    However, I think iBATIS CAN solve this problem!!! It's very easy: the
    mapper needs to remember the concrete implementation injected, and
    cast
    that when calling the setter.

    The only way to currently solve this problem is by altering the
    class to
    do this below. Here I have provided a separate set of properties just
    for iBATIS object construction. It's not pretty but it's the only way
    for iBATIS to "remember" the concrete type injected:

    class BImpl implements B {
      A getA();
      void setA(A a);
      AImpl getAImpl();
      void setAImpl(AImpl);
    }

    Thoughts?

    Paul



Reply via email to