db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jordan" <david.jor...@objectidentity.com>
Subject RE: Company model for JDO 2.0 TCK
Date Mon, 18 Apr 2005 18:25:25 GMT

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:Craig.Russell@Sun.COM] 
Sent: Monday, April 18, 2005 2:16 PM
To: JDO Expert Group; jdo-dev@db.apache.org; jdo-tck-ext@Sun.COM
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message