Andrus Adamchik wrote:
>
> Holger Hoffstätte wrote:
> > (protected/private)
>
> Maybe, but we need to make a decision on a per case basis. Is it
> possible that in some situations default constructor that does not work
> is simply a bug and we need to fix the bug and add a unit test?
Not in the cases that I had in mind; it's more an API ease-of-use thing.
For example ObjectId has an implicit public constructor, but the resulting
instance is useless since the only setter - setIdKeys() - is protected, so
the other constructors are the only 'usable' ones.
Similar Attribute and Relationship. If you construct e.g. an empty
DbAttribute and try to add it to a DataMap, it will raise an exception
because it has no name yet. I think it might be better to just prevent
this in the first place; the empty constructor can be made protected so
that subclassers can still use it. Personally I have started to make
everything private at first in order to keep the publicly accessible API
to a minimum, but I understand this is different and difficult to do in a
framework. Therefore protected would be a good compromise, IMHO.
Holger
This archive was generated by hypermail 2.0.0 : Sun Mar 02 2003 - 11:19:42 EST