Hi,
Currently the Company model has concrete classes for the domain model. Since JDO 2.0 supports abstract classes and interfaces to directly model persistence, I'd like to propose refactoring the domain classes into three different parts per domain class, using Company as the example:
ICompany: the interface that declares only the get/set properties
ACompany: the abstract class that extends ICompany and declares and implements the equals, compareTo, deepCompareFields, and hashCode methods
Company: the concrete class that extends ACompany. This class declares fields and implements the accessors of the class.
This would allow existing code that uses Company to continue unchanged, as the Company contract is not changed. However, it would allow us to test the JDO 2.0 feature of persistent abstract classes and interfaces.
The downside of making the change is that it triples the number of .java files and might be confusing.
What do you all think?
Craig
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
