Hmmm - on second thought, maybe a ResultObjectFactory can't solve this
issue.  But I really dislike the idea of changing iBATIS so that it, in
effect, ignores the interfaces you declare by remembering their
implementations.  If there's an interface, there's always a possibility of
more than one implementation.  I think it would be wrong to have iBATIS try
to deduce what you mean here.

I think the best way to handle this would be to skip the immutable interface
and write private setters.  iBATIS can use the private setters as of V2.2.

BTW - it's not that I don't like immutability, I just think that this
pattern doesn't really achieve it.  If someone is bent on changing
your so-called immutable object, it's so easy to do.  The real problem here
is that you have to trust programmers to do the right thing.  If you don't
trust them not to call the setters, how can you trust them not to cast the
interface to the concrete class?  I think the ultimate solution is to have
iBATIS work with parameterized constructors but that is a V3 thing.

Jeff Butler


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

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