Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
This is a pretty noobish question – I’m looking at some Cocoa sample code and there’s @interface blocks in the .m files as well as the headers. For instance, in the AppDelegate class header, a UIWindow and UI navigation are defined as instance variables, but the @property declarations are actually made in the implementation file. Is there a functional reason for this, is it a stylistic choice, or… ?
If you just need e.g. some custom delegates to work with another class internally, there is no need to publicize the interface in the header.
It just adds unneccessary noise and makes interfaces available that might not be designed for public use or are not useful outside of the class’ context.
The same goes for the class’ methods and properties – if you want to use declared properties for your instance variables but don’t want them to be publicly accessible, you don’t neccessarily need to declare them in the header. Class extensions allow you to do that, see e.g. “How to make a private property?”.