You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig Russell <Cr...@Sun.COM> on 2005/04/18 20:16:05 UTC
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!
Re: Company model for JDO 2.0 TCK
Posted by Craig Russell <Cr...@Sun.COM>.
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: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!
>
>
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!
RE: Company model for JDO 2.0 TCK
Posted by David Jordan <da...@objectidentity.com>.
I know, just suggesting a way to reduce the workload.
David Jordan
Object Identity, Inc.
-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM]
Sent: Monday, April 18, 2005 3:37 PM
To: 'JDO Expert Group'
Cc: jdo-dev@db.apache.org; jdo-tck-ext@Sun.COM
Subject: Re: Company model for JDO 2.0 TCK
Hi David,
Good point. But this change does not change everything to use
interfaces and abstract classes. Existing and new code that uses
Company concrete classes will not change at all. In the metadata you
continue to identify the concrete classes as persistent and everything
else as non persistence capable.
The only thing that changes is the ability to define the abstract
classes and interfaces as directly persistent so we can test this
capability.
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: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!
>
>
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!
Re: Company model for JDO 2.0 TCK
Posted by Craig Russell <Cr...@Sun.COM>.
Hi David,
Good point. But this change does not change everything to use
interfaces and abstract classes. Existing and new code that uses
Company concrete classes will not change at all. In the metadata you
continue to identify the concrete classes as persistent and everything
else as non persistence capable.
The only thing that changes is the ability to define the abstract
classes and interfaces as directly persistent so we can test this
capability.
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: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!
>
>
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!
RE: Company model for JDO 2.0 TCK
Posted by David Jordan <da...@objectidentity.com>.
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!