Re: [vote] Re: Constructor for Domain Objects

[Thomas Mahler]

Hi Tal,

thanks for your contribution! I added it to the OJB contrib package. SO it will be part of the next release.

As most votes preferred the private constructor approach I won't add your solution to the main codebase.

cheers,
Thomas

Tal Yalon wrote:

Hi,

  We've extended OJB to use an instantiation factory (a-la TopLink). Using
an instantiation factory is very useful when you want to register objects
and also to differentiate between objects that were created from the DB to
objects that were created from the App (solves INSERT or UPDATE problem for
example, also helps when it comes to caching). It can also be used to fetch
objects from object pools instead of using constructors (although I doubt
the performance increase here).

Attached is our solution, which replaces the row reader with a new one. It
also adds a new confioguration key: InstantiationFactory.
Documentation is scarce though.

I'd be more than glad if it would be added to the CVS :)

Thanks,
Tal

Note: I've done some manual refactoring to remove other infrastructure code
that isn't OJB so there might be a few typos. Package names have to be
renamed aswell ...

-----Original Message-----
From: Ganguli Jaideep [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 4:26 PM
To: OJB Users List
Subject: [vote] Re: Constructor for Domain Objects


it was possible for me

to prevent the Domain Object api developers from being able to create
the object in an 'invalid' state.

I had 'static'  methods which took arguments to create valid instances
for e.g.
Lets say i had a 'Customer' Domain object with 2 attributes 'name' and
'phone' and both name and phone are 'required'.

In the Customer class i would make the constructor private.
I would also provide a 'public static Customer newInstance (name,
phone)' method that allows api users to create new customers.

For existing customers the OR Mapping tool will create the Customer
instance using the private no arg constructor using reflection and load
it with the name and phone data originally set.

So, this way you can prevent the domain object api developers from being
able to create a Customer Object with the name and phone not set. (They
would otherwise be able to do it using a public default no arg
Constructor).

hope this helps

Jaideep

Ganguli Jaideep wrote:

Let's have a little vote
Do we need support for
a) private no argument constructors?

+1

Here's the reason why i thought it as 'something i need'.

With a private constructor I was able to build a it was possible for me
to prevent the Domain Object api developers from being able to create
the object in an 'invalid' state.

So, basically it helped me to create a cleaner domain object api.

Thanks

Jaideep Ganguli

Thomas Mahler wrote:

hi all,

Ganguli Jaideep wrote:

Hi all,

Is it absolutely necessary to have a public no argument constructor

for

my domain objects?

I have worked with another OR Mapping tool before (Toplink) where this
was not necessary. It still needed a no argument constructor, but the
constructor wasn't required to be public, it could be private.

The main reason to rely on a public constructor was performance. If
there is no public constructor you'll have to do some additional
reflection magic to make construction possible.

We wanted to keep things simple, thus we also don't have a feature to
specify factory classes and methods to construct domain objects.

Let's have a little vote
Do we need support for
a) private no argument constructors?

b) userdefined factories to build domain objects?

cheers,
Thomas

Thanks

Jaideep

--
To unsubscribe, e-mail:

<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail:

<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:

<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail:

<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


------------------------------------------------------------------------

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>