Just me $0.02: In my personal code, I always try and make the
designated[1] constructor take all *required* parameters to setup that
object to function correctly. If there's any that can be assumed, I may
make other constructors that call the designated constructor with the
appropriate default values for missing parameters. That way, any
clients of the code cannot help but create fully correct functional
objects. I feel it makes for better API.
Craig
[1] terminology from ObjC days coming through.. .for the innocent, it's
the constructor which all other constructors end up calling into, after
supplying any default values. Was easier in ObjC when the call to
another constructor (this() or super() in Java) didn't need to be the
very first line of the current constructor... blech.
On Mon, 2003-03-03 at 06:00, Holger Hoffstätte wrote:
>
> > I am confused, ObjectId doesn't have a default constructor.
>
> No, _I_ am confused! You are right. I thought that the default constructor
> would always be implicit, but it seems that's not the case when
> subclassing from Object (sigh). It's not a problem then.
>
> <crawling back under rock>
>
> > In case of DbAttribute, you can always call setName before adding to an
> > entity. We use it all over in the unit tests. I don't have any serious
>
> Well, you and I know that, but I'm regularly dealing with people who
> happily call everything that they can..in random order. :-/
>
> > objections to making it protected (but not private), I just don't see a
> > need to do so.
>
> It's not obvious from the API, that's all.
>
> Holger
This archive was generated by hypermail 2.0.0 : Sun Mar 02 2003 - 13:50:45 EST