Learning Objective-C and other c based Languages I learned that you should put the #includes and the #imports in the header file. And the #class goes there as well. Recently looking at example code from apple and other sources around the web the #class is in the header and all the imports are in the implementation file.
Which is correct? Are there reasons for both? Also why do you need to provide the #class declaration if you are importing the header file.
Neither case is "more correct", there are definitely reasons for both behaviours. For example, think about the case where you have two classes, each which has a reference to an object of the other type:
ClassA.h:
#interface ClassA : NSObject
{
ClassB *b;
}
ClassB.h:
#interface ClassB : NSObject
{
ClassA *a;
}
This code won't compile - you have a circular dependency in these headers. The solution is to forward declare the required classes using the #class directive.
A situation where you might prefer the #import directive in the header file might be if you have some common code besides just a class name that you care about in the other header - maybe C style functions or enumerated types or something.
Learning Objective-C and other c based Languages I learned that you should put the #includes and the #imports in the header file.
no - not in c based languages. you should put them in the implementation files where possible. you can't always create a zero-dependency header, but you should minimize it.
c based languages take a long time to compile, especially when the dependencies and includes are very complex, or there are unnecesary includes (introducing more dependency, coincidentally).
And the #class goes there as well. Recently looking at example code from apple and other sources around the web the #class is in the header and all the imports are in the implementation file. Which is correct?
use forward declarations (#class NAME;, #protocol NAME;, struct NAME, class NAME;`, etc.) wherever you can.
Are there reasons for both?
including in the header is the lazy way, it slows down your build times and introduces a lot of dependency. it's convenient because you don't have to write as many include/import declarations, but it's not considerate for people who must use your programs.
Also why do you need to provide the #class declaration if you are importing the header file.
if the class interface is already visible (has been included already, or another file has declared it), you do not need both . you'll need the interface visible if you intend to use the type (apart from some very trivial cases).
you certainly won't be excited to correct the mistake once your build times have grown slow -- it's best to learn and implement using the right approach. if you've not developed a complex c project, then you'd likely be very surprised to learn how much time is lost while compiling.
if you expect that your programs will never become nontrivial, and will be never shared or reused, then do whichever you prefer.
good luck!
Related
I've read that the rule is to not #import or #include anything in .h files. Is that really true, though?
Just today I've run into two separate occasions where I had to do it, one where I import a header file that contains a typedef enum because my method stubs use it as parameters and another where I have to import a header file to declare delegatation.
What's the actual rule for these types of situations? Is it sometimes okay to do so – and if not, how can I do it differently?
There's no hard rule, but sometimes you do have to do it. You will also need to do if you inherit from something or need the protocol declaration.
In general I would restate the rule as "use forward declarations of #class and #protocol whenever possible."
If you've read such a rule, that rule is wrong. You can include (and import, which is just a safer way of include) things into your header, if that's something required for the interface declaration. Otherwise save it for the implementation files.
If ClassA depends on ClassB such that a consumer of ClassA is certainly going to need to import ClassB in order to make use of ClassA, I would prefer header imports over forward declarations.
I have a baseClass1.h an d baseClass1.m
These have several public methods which are used by several base classes. What I am trying to do is to create a different implementation of same methods declarations.
After I have written baseClass2.m whose interface is baseClass1.h also.
Now in subclasses, how do I have methods do what I've defined in baseClass2.m instead of their respective definition from baseClass1.m
EDIT:
I duplicated the target in baseClass1 workspace to a new target. Both implementation files are exclusive to 2 targets. What I'm trying to do is to use different .m file with each target selection from xCode.
It is somewhat like changing the AP definitions. To explore the possibility to discard baseClass1.m for given now. Any way so that even if I delete baseClass1.m and program should still build
If you want two different implementations of the same class in two different targets then you can simply use two separate implementation files for the same class, and add each of them to one target only, e.g.
"BaseClass.h": the interface,
"BaseClassA.m": implementation of BaseClass, only in target A,
"BaseClassB.m": implementation of BaseClass, only in target B.
An implementation file need not have the same name as class, that is just a (useful) convention.
You need create #protocol for common interface.
Implement it's methods in baseClass1 and baseClass2.
And then you can subclass any base class you wish.
You can use protocol to declare common interface.
baseProtocol.h:
#protocol your_protocol <NSObject>
#optional
- (void)methodA;
#required
- (void)methodB;
#end
baseClass1.h:
#import "baseProtocol.h"
#interface baseClass1 : NSObject<your_protocol>
#end
baseClass2.h:
#import "baseProtocol.h"
#interface baseClass2 : NSObject<your_protocol>
#end
Technically this is possible: easy, in fact.
It is also a Bad Idea™.
Why is it a bad idea? Because it is unexpected. It is very unexpected. So unexpected, that some people didn't think it possible, many more didn't even understand what you where asking.
By using this anti-pattern, you are dooming future developer to waste hours trying to figure out what you did, and why you did it.
In this example, just use a protocol, fake it out by using a cluster class, or just support both implementations in a single class using a flag to switch between the two. Don't make things harder on everyone just because you can be clever with the build system.
So I am using the new #import module syntax introduced with the latest Xcode - I still wonder where the best place is to put them. Before, I would place library imports and very important categories in the .pch file, but now that's not necessary anymore (at least not for the native frameworks). My first idea was to create a modules.h file and do all the imports there, then include that modules.h file in the AppDelegate - but this doesn't seem right. Also, importing in the first place you need it doesn't make sense either, since you might use it in different places.
This is in fact a question about "best practices" which is - of course - a little subjective. But I think this affects a lot of people and the overall project structure. So please share your solution to this.
it sounds like you weren't doing it the best way before, In general you want as few symbols available at any one time. For a few different reasons:
less likely to make a mistake with symbols that have the same name but different values, or types... and for reasons that the compiler has to import less crap into each compilation unit.
I am not an expert on how #import has changed the compiler semantics of preprocessing and compiling, but I suspect you should still basically import things as close to the point that they will be used as possible.
I generally will not generally import any class's headers into another class's .h file.
in a .h I will forward declare any classes with #class SomeCLass and only include enough headers to satisfy the c/c++ types that I use as ivar/properties. The only exception to that being if I need to include a superclass's header or another .h for a protocol.
the rest of the includes go into the .m
I like to keep my pch pretty spartan, but if you have some utility categories or a widely used library you could include stuff in there, I tend not to... but in a smaller project you probably wont run into problems... you will run into indexing problems in projects with hundreds of source files, especially if you have some Objective-C++ units. That will end up hurting code completion and live syntax checking.
Baby new to Xcode, Cocoa touch and iOS development in general. And am taking the Stanford walkthrough for their iPhone class. I am a little confused at a couple of places and need to shoot my doubts to you guys:
I have two classes that I have created for my model, essentially CalculatorBrain.m and CalculatorBrain.h.
From what I gather, in Objective C, creating a class essentially consists of two functions, one is to declare the class which contains the method/messages and other variables while the other is the actual implementation for the same. From this stems two questions:
Why must I declare a class without implementing it's methods at first? (the concept seems to be borrowed from interfaces) and only then move on to implementing it .
From the above question, as I go through the walkthrough, I notice that the class declaration took place in CalculatorBrain.h whereas the methods were actually implemented in CalculatorBrain.m. I am unable to grasp the nuances of why this was done so if anybody is willing to shed some light on this, it would really help
Thanks again,
Parijat Kalia!!!
These are traditions from the C world, and they're just common practice to avoid some problems. They aren't two classes, they are the definition (in the .h file) and the implementation (in the .c or .cc file).
If you defined the class in the .c file, you couldn't refer to it elsewhere because it wouldn't be defined. You could include your .c file, but then you'd have two copies of the code. You could also use the "extern" keyword, but at this point it's kind of odd.
If you put code in the .h file, then when it's included the code gets included. This means you can get compiler errors that you have three "getMyThing" functions.
This means you can give out your headers to others without giving away your top-secret implementation (useful for making libraries), include your header without worrying about the possible multiple definitions, etc. You can also add variables and functions in the .c file which people using the header (like your other code) can't see or use, so you don't have to worry about changing it later and having compilation break.
After several months of coding in Objective-C, I completely understand when I need an #import, how import statements cascade (ripple?), and when to use forwarding classes. I do not know how to aggregate imports to get them inside of <> instead of in quotes (although maybe that's just for frameworks)...
The problem is that I'm making a huge mess. I come from Java (and the heavy-handed IDE), so I just add imports as I see fit. Sometimes I add them to the interface, but since that's usually not necessary, I just add them to the top of the .m in question.
Today I started thinking: there must be some rules of thumb on how to organize this stuff. In fact, since Objective-C is a C superset, there are rules of thumb for everything, but I don't know them. How should I organize my imports? Particularly:
When should I import in the .m?
When should I import in the .h?
Should I create .h files just for the sake of importing them (i.e., header files that just have imports in them)? If so, any hints on organizing that?
This is just a general idea of what I'm trying to figure out.
The <....> syntax is indeed just for frameworks. That doesn't mean you shouldn't create a framework to contain the core logic of your application though. Often this is a useful thing to do if you:
a) Need to provide support for loadable bundles that want to invoke aspects of your application logic (the bundle links to the framework, so does your application)
b) Write multiple apps that share the same core logic
Your question is somewhat subjective and you will get developers who argues both ways, but a convention I follow is:
Never import class definitions in the .h file, unless you are subclassing it. Use forward #class directives for everything in the .h.
Only import class definitions into a .m as you find you need to use that class in the implementation.
Generally speaking, the .h does not need access to the class definition of its ivars, method arguments or return values. It only needs to know that they are classes, which is what #class allows you to do. It does need access to the class definition of anything you're subclassing, adding a category to, or (obviously) implementing a protocol for.
Forget about whether <...> is for frameworks or what. <...> checks the system header search path, while "..." checks the current dir in addition to. One thing to remember however, is that the <CoreFoo/CoreFoo.h> declaration is handled a little differently on the apple platform, but only as it relates to apple frameworks: CoreFoo.framework/Headers/CoreFoo.h is matched to CoreFoo/CoreFoo.h
When imports are inside <> instead of quotes, all this means is that you are importing something from a framework. In fact, when doing this, the import is typically in the style
#import <Foundation/Foundation.h>
The first Foundation, before the slash, is the name of the framework in question, and the second one is just a header file in that framework. That header file is just something like
#import <Foundation/NSObjCRuntime.h>
#import <Foundation/NSArray.h>
#import <Foundation/NSAutoreleasePool.h>
...
#import <Foundation/NSURLHandle.h>
including every file from that framework. You can do this too, and isn't a bad idea for components that need multiple imports (although in that scenario, you may want a separate public interface)
For the other stuff, following the rule of thumb that you want stuff to know about as little as possible, you only want to put the import in the header file if it's necessary (like for an ivar or superclass) but really it's a matter of taste.