Enhancement: Association Interfaces

[GoogleCodeExporter]

What steps will implement this Enhancement?

1.) Create a net.openid.association.Assocation interface, that simply has
the getters/ setters for the current net.openid.association.Association.
2.) Create an AssociationImpl (or whatever you prefer to call it) that
models only the attributes of the Association (essentially, purely a model
object).
3.) Create a class called AssociationFactory, and move all of the public
static creation methods out of Association, and into the factory.
4.) Provide a public default constructor in the AssociationImpl class, so
that the Factory (and other code like EJB3) can instantiate and use the
model class.

RATIONALE: This would separate the model from the business logic, and allow
people to do other things with the Association classes (like persist them
to a database using Hibernate/Ejb3 without mapping them to a different class).

I've got much of this written already, too.

Original issue reported on code.google.com by sappenin on 5 Feb 2007 at 6:15

[GoogleCodeExporter]

Original comment by Johnny.B...@gmail.com on 6 Feb 2007 at 12:36

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Does Hibernate or EJB3 require you to derive your persisted classes from a 
special
base class?

If not, then why can't you directly persist the existing Association class?

Original comment by mscurte...@pingidentity.com on 6 Feb 2007 at 1:22

[GoogleCodeExporter]

EJB3/Hibernate Entity beans require a public empty constructor be defined, as 
well as
an interface for the model object.  On the J2EE side, the EJB object gets 
manipulated
via its interface.

I *could* just sub-class the current openid4java Association.  But I wouldn't 
be able
to pass my EJB Association into the openid4java code (or vice versa) because 
the EJB
class/interface would be different than the openid4java Association (they 
wouldn't
share the same interface).  If there was a common interface for Association, 
these
could be passed around as the same thing without conversion.  

It's not a show-stopper to leave Association alone.  I can just sub-class the
Association, and convert it back and forth, but I think it would be best to 
create an
interface, and then separate the model from the business logic with this class 
using
the factory pattern.

Original comment by sappenin on 6 Feb 2007 at 4:54

[GoogleCodeExporter]

Original comment by marius.s...@gmail.com on 6 Feb 2007 at 8:19

• Changed state: Started

[GoogleCodeExporter]

Marius,  

Any more thoughts on this issue?  I can make these changes if you prefer.  Or, 
if you
would rather not transition this code in the way I described, I'll just work 
around
it in my OP code.  Let me know how you plan to proceed with this issue.  Thanks!

Original comment by sappenin on 8 May 2007 at 3:52

[GoogleCodeExporter]

We looked at the code again and it feels like leaving the code as is probably 
is the
best solution.

You will have to create a DTO class for associations in order to persist them. 
Maybe
you can create Hibernate/EJB implementations for the consumer and server 
association
stores.

Introducing an interface and an implementation class and also adding a public 
default
constructor would require changes in lots of other classes. Currently there are 
no
setters and no public default constructor on purpose, you can create 
associations
only through factory methods, and this guarantees valid objects all the time.

We could move the factory methods to a separate class, but they would function
exactly the same. Are there any benefits on doing this?

Original comment by marius.s...@gmail.com on 9 May 2007 at 6:59

[GoogleCodeExporter]

Hey Marius,

Thanks for your reply.  See my comments inline.  

> Introducing an interface and an implementation class and also adding a public 
> default constructor would require changes in lots of other classes. 
> Currently there are no setters and no public default constructor on purpose,
> you can create associations only through factory methods, and this guarantees 
> valid objects all the time.

Hmm...I wonder if we're not quite understanding each other correctly.  I would 
be
perfectly happy if the current openid4java Association class maintained a 
private
constructor (really, it could stay exactly as it is) as long as Association 
would
implement an Association *Interface* (I'm even ok omitting "setters" in the new
interface -- read more below).  That way, I could make my own Association
implementations, use them in EJB or wherever, and also use them in the 
OpenID4java
code directly.  

I wonder if the following proposal might satisfy both of our desires (rough 
proof of
concept sample attached):

1.) Create an Association Interface called "Association" (I think there are 
only 4
property getters).  I would be perfectly fine if you left off the setters.  I 
can
extend this interface and add the setters so that it plays nice with EJB on my 
end. 
Since Openid4java doesn't use these setters, I should be able to use my extended
interface with openid4java code without issue (as long as my Association 
interface
extends the openid4java Association interface).

2.) Create a factory class called "AssociationFactory" that has the static 
creation
methods which presently reside in the current Association class.

3.) Inside of AssociationFactory, define an inner class called AssociationImpl 
(or
whatever), with a private constructor and private member variables.  That way, 
nobody
can instantiate a real AssociationImpl except by calling a static method on
AssociationFactory (or by creating their own version outside of Openid4java).

4.) All Assocation *declarations* throughout the openid4java code-base can stay 
the
same (if the new interface is called Association, then this would match current 
class
declarations).

5.) Calls to static Assocation creation/generate methods can be easily renamed 
from
"Association.generate(" to "AssociationFactory.generate(" -- this is a simple
find/replace.

6.) Functionally, things would stay the same on the openid4java side -- these 
changes
would be name changes for the most part, but would allow an interfaced version 
of
Associations to be used throughout.  Using the factory allows us to separate 
model
from creation code, and Openid4java-packaged code is guaranteed to work, yet is
flexible to allow other implementations of the Association object.

Thoughts?

Original comment by sappenin on 12 May 2007 at 2:36

Attachments:

• Association.java
• AssocationFactory.java

[GoogleCodeExporter]

Original comment by marius.s...@gmail.com on 21 May 2008 at 10:22

• Changed state: WontFix