I just started picking up objective c and I have been following a tutorial online.
In the tutorial, it set the NSMutableAray pointer in the implementation (.m file) in the curly brackets.
I thought the pointer variable should be declared in the header file.
What is the reason / benefit of having the pointer variable in the implementation file in the curly brackets?
#interface AppDelegate ()
#end
#implementation AppDelegate
{
NSMutableArray *_players;
}
Two reasons for declaring instance variables in the #implementation:
The instance variable is private to the implementation, it is implicitly private, cannot be made public, and no even subclasses can see it. This restricts access from outside the implementation to the value of the instance variable, or to setting its value, to public (or protected) methods/properties declared in the interface.
It de-clutters the public #interface by removing details which are not relevant to the user of the class, but only to its implementation.
Originally Objective-C did not support declaring instance variable in the #implementation, but it has for a few versions of Xcode/clang by now. In old code you will still see instance variables in the #interface, but it is better in new code to declared them in the #implementation.
HTH
Apparently so private interface is unavailable outside
Related
If I'm declaring an ivar in a .m file, either in an #implementation block or in a class extension, is there any benefit to marking it #private?
It seems that whether or not they are private, a compiler error is generated. However, according to Apple, accessing private variables causes a link error. So it does seem that there's an advantage to declaring them #private. Is that correct?
Instance variables declared in the #interface have a default class of #protected. Declarations in the #implementation are private. An explicit #private attribute is unnecessary in the latter case.
May I know what is the difference between instance variable in .h file and property in .m file in objective c?
I know that both cannot be used outside the class. Any other difference?
A. You can add ivars inside the implementation, too:
#implementation AClass
{
id ivar;
}
Therefore the difference is not that ivars has to be in the header (interface). (But see below B.)
B. If an ivar should not be used outside, there is no reason to put it in the public header. Why do you want to inform somebody about an ivar, if he cannot use it? This is source code spamming.
C. A property adds (or uses) an ivar. Additionally it adds accessor methods.
D. A property provides additional semantic information, especially about atomicity and setter semantics, if it is declared in the header.
Up to here it should be clear that properties are usually the better way to model an object state. So why do we have ivars in headers?
This is for legacy. In former times we did not have declared properties. There has been some reasons for having ivars in the header (for example to tell the compiler the object size), but this are gone. The only meaning for declaring ivars in the header in nowadays is that you make them public and let others access them directly for performance reasons. You should have very good performance reasons to do so. I had never had them.
In addition to Jef's answer:
If you want to make ivars public to subclasses, you can put them into a class continuation in an extra file. Let's have an example:
MyClass.h
// We do not put ivars in the public header. This is an implementation detail.
#interface MyClass : NSObject
…
#end
MyClass_SubclassAddition
// We do put ivars in an extra header with a class continuation, to make them visible for subclasses
#interface MyClass()
{
id ivar;
}
#end
MyClass.m or MySubclass.m
// We use both headers in the implementation and subclass implementation:
#import "MyClass.h"
#import "MyClass_SubclassAddition.h
#implementation MyClass
…
#end
You can get rid of the "subclass ivar problem", if you use setters in initializers. Whether this is wrong or not to do so, is a different discussion. Personally I prefer to use setters. But do not let us start that discussion again (and again and again …)
the biggest practical difference is that subclasses can see and use ivars which are declared in the .h, where if they are in an extension at top of the implementation file a subclass cannot access them.
I like to start with them in the .m file but i'll happily move one to the header in order to use it from a subclass.
I'm starting with obj-c and there's a few things I don't get.
First of is I (oh I'm coming from an AS3 coding perspective) thought that if you wanted to have a variable in your class, you needed to declare it first in the header with the #property operator, and then #synthesize in the .m file, and also you had to declare the method in the header as well, but I've come across situations where variables are just defined in the methods in the .m file, without any declaring anywhere, and the same for the methods, methods that are just written straight into the .m file with no declaring and they work fine.
So what's the point of the #property/#synthesize for variables and declaring the methods in the header files? it is all to do with scope?
What you are talking about is not referred to the declaration of a variable but to expose it from outside of the class through a getter and a setter.
The #property/#synthesize are just a shortcut to automatically create two methods which are
- (void) [class setVariable:(type)var]
- (type) [class variable]
that can set and get the variable from other classes.
Not every variable needs to be set or got from outside the class.
The header (.h) file should contain what you want other classes to know about this class. A class extension -- an interface section inside the .m file -- is a good place for private declarations. (If a method is defined before it is used, that serves as a declaration. It isn't optimal but it works.)
There are three main categories of variables in Objective-C:
Instance variables
Static-scope variables (static, global, and function-static)
Automatic-scope variables (locals and function/method parameters)
When you declare and synthesize a property, an instance variable is created for you. Local variables, on the other hand, are declared in the scope of a code block, and cannot be declared through a property.
I've been learning Object Oriented Programming in Objective-C and I'm a little confused about method declaration and implementation.
In some lectures I've been studying, the professor declares public methods in the .h file and then implements them in the .m file; or he may declare them private in the .m file and them implement them in the #implementation ClassViewController section.
Sometimes, however, he doesn't declare methods at all and just skips to method implementation in the #implementation ClassViewController section.
How do I make this distinction where to declare something either public or private, or not having to declare anything at all?
Methods should be declared publicly when you want that method to be accessible to outside classes, and privately otherwise. A method that was declared in a superclass does not need to be declared again in it's subclasses if you override it. As far as methods that are implemented without any previous declaration, that method can still be called, but it is only 'visible' to methods below it in the file, and will throw a warning otherwise. As such, this is rarely done (it is declared privately instead), with the exception of if that method is intended to be the target of an #selector.
The short answer is that all methods should be declared (either publicly or privately).
But I suspect what you actually saw your professor do was override a method that was already declared in a superclass.
So for example, if you wanted to override viewDidLoad in your CustomViewController, you would not declare viewDidLoad again, because that method was already declared in the header for UIViewController (the superclass).
You would simply go to the implementation of your subclass and write your implementation of viewDidLoad which would override the one you inherited. If you go watch the lecture again, I'm guessing that is what you saw.
Why are people using
#interface ViewController : UIViewController
{
#private
UIButton* button_;
}
#private declarations in public headers? Declaring a variable inside an implementation yields the same result, doesn't it? It feels strange to me, I thought a public header should only contain really public members. What to do with protected members?
#implementation ViewController
UIButton* button_;
#end
The only difference I know of is that this variable is only visible inside the current compilation unit (the .m file, right?)
Does the same hold true for methods? I could compile fine with proper method ordering or forward declarations. Why do people care to declare categories for private methods? For testing purposes only?
The variable declaration inside the #implementation block will create a global variable, and not an instance variable. Instance variables need to be defined as part of the #interface.
While you can create an additional #interface block, by means of a category or extension, but it can only contain method declarations, and not instance variables.
I would say that while it might "feel" wrong to you to put private instance variables in a supposedly public header, I wouldn't worry about it.
Take a look at pretty much any header file for a Cocoa class (except for the cluster classes), and you'll see that Apple declares their instance variables in their public header files.
Since Apple is OK with it, I don't think you have much to worry about. =)
FYI: All instance variables are protected by default.
Does the same hold true for methods?
No, methods are visible to any part of the program. If you know the selector you can callit.
I could compile fine with proper method ordering or forward declarations. Why do people care to declare categories for private methods? For testing purposes only?
Private categories are a form of forward declaration. You can think of them as if they were C prototypes.
Andrew
#private is referring only to the iVars.
By default you can access ivars of an instance like so:- id iShouldNotDoThis = foo->bar;
#private means you can't access the ivar like that and have to use the access methods.
id thisIsBetter = [foo bar];
Nothing to do with private categories or methods.