[
http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58237 ]
Aitor Imaz commented on IBATIS-50:
----------------------------------
I agree with the submitter. Programming against interfaces is usually better
practice than programming against concrete classes. Furthermore, there are a
few situations where an object creation mechanism like the one proposed could
be useful.
For instance, to simulate polymorphism on a relational database. Let's say you
have a "SHAPES" table with a "TYPE" column, where TYPE 1 = Circle, TYPE 2 =
Square, TYPE 3 = Triangle, etc. If I'm not wrong, there's currently no
mechanism to map rows from that table to objects of a Circle, Square and
Triangle class, which would all implement a Shape interface. The only way I can
think of is to first obtain the type, then create the object, and finally to
pass that object to an iBATIS sqlmap and populate the result object.
If iBATIS had a way to delegate class instantiation, such a problem could be
solved. Something along the lines of what the submitter proposed and the
TypeHandlerCallback mechanism could be used:
public interface InstanceFactory {
Object createInstance(ResultGetter getter);
}
A possible implementation being:
(...)
public Object createInstance(ResultGetter getter) {
Shape shape = null;
if (getter.getInt() == 1) {
shape = new Circle();
} else if (getter.getInt() == 2) {
shape = new Square();
}
...
return shape;
}
(...)
A "factory" result property would have to be specified per resultmap, which
would be evaluated before the result object creation.
I'm sure there are a few more examples of possible uses for a mechanism as the
one proposed.
> Ability to override the default bean creation mechanism
> -------------------------------------------------------
>
> Key: IBATIS-50
> URL: http://issues.apache.org/jira/browse/IBATIS-50
> Project: iBatis for Java
> Type: Wish
> Components: SQL Maps
> Versions: 2.0.9
> Reporter: Philippe Laflamme
>
> Currently, iBatis is responsible for creating instances of classes used in
> result maps. It relies on the assumption that objects can be obtained using
> the Class.newInstance() method (or something equivalent).
> The assumption forces users of the framework to create classes with a no-arg
> default constructor. IMHO, this also has the effect of favoring
> implementation inheritance (extends) over interface inheritance.
> Although this is not a problem in most cases, the ability to plug in an
> external instance factory would provide more flexibility and favor good
> programming practices. Amongst other things, it would provide developers the
> ability write code in terms of interface.
> A simple solution is to provide an extension point where resultMap class
> instances are obtained from.
> The simplest form would be:
> public interface InstanceFactory {
> Object createInstance(Class resultMapClass);
> }
> The default implementation would do something along the lines of:
> [...]
> return resultMapClass.newInstance();
> [...]
> Developers could configure iBatis to either use the default implementation or
> their own custom implementation. The setting could be part of the
> sqlMapConfig file or even per resultMap.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
