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]>
