Initialisation pattern
Initialisation pattern
- Subject: Initialisation pattern
- From: André Francisco <email@hidden>
- Date: Thu, 13 Aug 2015 03:07:47 +0000
- Importance: Normal
Hi all,
I've been reading about object initialisation in Objective-c, as well as the recent additions of NS_UNAVAILABLE and NS_DESIGNATED_INITIALIZER. It's been confusing what the correct approach would be, mostly due to limitations imposed by the compiler. My main goal is obviously to ensure proper object initialisation, both when an object is directly instantiated and when a constructor call is propagated by a child subclass.
It's noticeable that my background comes mostly from C++ and Java, both languages in which constructors are not inherited by child classes, unlike Objective-c. I can't make sense out of constructor inheritance, to be honest. The fact that a constructor makes sense in a given class does not mean it will to its children. -init is a great example of this if a given class has mandatory parameters with no default values.
Lets analyse some approaches:
Override the parent constructor and make up some defaults - this is, IMO, the worts approach. It'll force you to come up with defaults even if they are senseless. Callers will have to rely on documentation in order to understand what the defaults are doing, if anything at all. I've read about "set all to zero" approaches but in this case enums come to mind. Obviously not only enums will suffer from this, but setting an enum to zero does not mean that it's an invalid state, quite the contrary. Even so, the instance would still be useful so I really don't see a point. Instead of this approach I'd rather:Always return nil. Without the parameters required initialisation should fail. In Objective-c returning nil is how an initialiser fails, so it actually makes sense. This approach although reasonable still relies on documentation to figure out what valid initialisers would be. This could get messy after a few levels of inheritance.Use NS_UNAVAILABLE on constructors that do not provide required parameters (ie., parameters without defaults). This would be my favourite approach as it is enforced by the compiler if the method is called directly, except that you cannot redefine the method on a subclass. Lets say a given class is implemented and flags -init as NS_UNAVAILABLE, while implementing a second initialiser -initWithParameter:. This is a base class and it doesn't make sense not to provide the given parameter, whatever the reason may be. Some other class, a child of the first, is not implemented which does provide a default parameter - too late, -init is already unavailable. I've seen recommendations on creating a second initialiser, such as -initWithDefaults, but again, what happens after a few levels of inheritance?
None of this approaches solves the problem entirely. Either NS_UNAVAILABLE was revertible or constructors were not inherited at all. Other than that, I couldn't come up with an ideal solution.
Please advise.Best regards,André.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden