When creating a project in straight 'C' I can manage to split lengthy code into multiple h/c groups without issues. However, while I've been dabbling in Obj-C for a few years now I still can't grasp the following fundamental issue (perhaps because of my old C-style thinking and great-grandfatherly age?), which has led to the habit of writing huge, monolithic files which are hard to read/edit etc. I've tried everything I can think of and spent weeks searching the net for answers, but all to no avail.
Just suppose I create an NSObject instance called 'AppController, which contains the required h/m files. The interface file is basically laid out like so:
#import <Cocoa/Cocoa.h>
@interface AppController : NSObject
{
IBOutlets etc here...
}
method declarations here…
@end
while the implementation file looks like so:
#import "AppController.h"
@implementation AppController
actual methods here …
@end
NOW suppose I want to add two extra h/m files called 'temperature'. In other words, I'm after four files in my project, namely:
AppController.h
AppController.m
temperature.h
temperature.m
I get that I'd have to #import the temperature interface file into my main AppController implementation file of course, but would I also need to create them as NSObject classes? These templates come with their own pre-written references to super etc. which cause all kinds of compiler issues and even more confusion.
Perhaps following my super-basic code snippet examples above, how would the temperature.h, temperature.m (and AppController.m) files be laid out so they can talk to each other? Where am I going wrong?
Since
temperature
files contain free functions, there's nothing more you need to do. You can simply call C functions from within Objective-C classes. If you want to make a class out of them, you can do that, too. It doesn't have to inherit fromNSObject
, but it can be useful to do that because it allows you to call variousNSObject
methods on it, such as-respondsToSelector:
,-isKindOfClass:
or-performSelector:
.