First things first: let's put the JDO(R) implementation into a
package called ojb.jdo
.
The naive way of implementing JDO(R) would be to have a short
look at the code in the package ojb.odmg
(and its subpackages), and write the code for ojb.jdo
with some kind of copy & paste reuse from the ojb.odmg
stuff. This approach is shown in the next diagram (figure 2)
Figure 2: package diagram for a quick and dirty approach. The JDO(R)
implementation reuses code fragments from the ODMG implementation.
Green symbolizes new code.
This approach will be fast and will allow to maintain the ODMG and
the JDO(R) branches independently.
But there are also disadvantages: Due to the similarities between
JDO(R) and ODMG with respect to transaction handling both packages
will contain duplicate code. This may result in double maintenance
efforts. Duplicate code is also a typical indicator for bad design.
This "code smell" may be resolved by an additional level of
abstraction.
I suggest to factor out a ObjectTransactionManager (OTM) that
contains all basic Object transaction services (lock management
etc.). This OTM will be used by JDO and ODMG implementations. This
OTM will add a new level of genericity to OJB. The dependencies are
depicted in the next diagram (figure 3).
Figure 3: package diagram for the refactoring approach. The ODMG
implementation and the JDO(R) implementation depend on the OJB
ObjectTransactionManager that itself is based on PersistenceBroker
code. Green symbolizes new code. Pink symbolizes refactorings.
If we choose this approach there are at least two possible strategies:
-
First factor out the OTM and refactor the ODMG implementation
to use the OTM. Then write the JDO implementation based on the
OTM.
Problem: we have to know in advance what JDO and ODMG have in common.
-
First write a rapid prototype of the JDO implementation as
suggested by figure 2.
Advantage 1: we will have a working prototype soon.
Advantage 2: Writing this prototype will show us in detail the OTM
intersection between JDO and ODMG.
Then write the OTM based on this knowledge.
Finally refactor ODMG implementation and JDO implementation to use the
OTM.
The second strategy looks most promising to me.