Hi David,
I'll take a look at this idea. I had thought that it made sense to allow the entire model to be represented by interfaces, but I'll see.
I still don't understand what the down side is, though.
Craig
On Apr 18, 2005, at 11:25 AM, David Jordan wrote:
Do you really need to make everything based on interfaces and abstract classes? It may make more sense to just do this for one part of the model, enough to test the functionality that needs to be tested.
David Jordan Object Identity, Inc.
-----Original Message----- From: Craig Russell [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 2:16 PM To: JDO Expert Group; [email protected]; [EMAIL PROTECTED] Subject: Company model for JDO 2.0 TCK
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!
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
