Re: Inherited constructors
Re: Inherited constructors
- Subject: Re: Inherited constructors
- From: Drew McCormack <email@hidden>
- Date: Thu, 30 Aug 2001 09:26:21 +0200
You failed to grok the "designated initializer" thing.
d> No, in general I find Obj-C extremely elegant and powerful, but I
think
d> it would be better if constructors were not inherited.
I am quite afraid you are wrong in that.
Whoa, the obj-C police are out in force today!
Well, we are all entitled to an opinion. The thing that bugs me about
the constructor setup in obj-C is that it is possible to construct
objects in meaningless states. Maybe this is not really a big problem,
because you can always make your class immutable (ie hide setters) so
that a class user is forced to use a constructor that does produce a
meaningful state, but it still bugs me.
For example, if a user needs to create an object containing an integer
value of 5, they should obviously call [obj initWithIntValue:5]. Yet the
class still includes other constructors which do pointless things. For
example, I chain my 'init' method to 'initWithIntValue' (yes, I did
"grok the designated initializer thing") and pass 0 for example.
Absolutely pointless. It simply clutters up the interface. If a user
wants an object holding 0, it is far safer if they explicitly demand it
by calling [obj initWithIntValue:0]. If a user calls [obj init], a new
programmer will have to dig deep into the inheritance hierarchy to
figure out all the default values. This just means the code is harder to
read, and more prone to error.
Sure, these things aren't that important. The obj-C way probably does
lead to less code overall, and the C++/java way leads to more control
and less interface clutter, but it is all personal preference. I can see
advantages to each way of doing things.
Drew McCormack