Split Obj-C classes into multiple files

Member
Posts: 73
Joined: 2009.03
Post: #1
Is it possible to split the implementation of an Obj-C class into multiple files for organizational purposes? My main class has so many methods that it is becoming very hard to jump straight to what I'm looking for without doing a search.

If not, any other organizational techniques for lots of code is appreciated.
Quote this message in a reply
⌘-R in Chief
Posts: 1,260
Joined: 2002.05
Post: #2
Look up categories in the Obj-C documentation.

http://developer.apple.com/mac/library/d...tiveC.html

Each file would have it's own category.


You could do some nastiness with #include too, but.... *shudder*
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #3
I tried #include but the compiler wouldn't even allow it. I'll look into the category thing.

[Edit] Categories sounds like exactly what I needed. Thanks!
Quote this message in a reply
⌘-R in Chief
Posts: 1,260
Joined: 2002.05
Post: #4
If the compiler didn't allow it, then you didn't do something right. Smile
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #5
I have finally gotten around to splitting my class into categories, which works but the compiler gives me warning about missing method definitions in the main class. Of course they're not in the main file anymore, but they are in another category file and work just fine. Is it normal to have these warnings when doing categories? Seems sloppy on the compiler's end.
Quote this message in a reply
⌘-R in Chief
Posts: 1,260
Joined: 2002.05
Post: #6
You need to import the header file for the category in the classes' main header file or implementation file. Same as anywhere else.
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #7
That doesn't really make sense, since the category file imports the main class's header file. They import each other? Ugh. Lots more imports I guess.
Quote this message in a reply
⌘-R in Chief
Posts: 1,260
Joined: 2002.05
Post: #8
Err... Come to think of it, yes. You shouldn't have category headers in the first place. All of those methods should be defined in the one and only main header. The category files should just be implementations.

If you were doing class additions this'd be different.
Quote this message in a reply
Member
Posts: 254
Joined: 2005.10
Post: #9
If the interface of your class is that big, you should probably start thinking about how to break it up, you've given it too many responsibilities.
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #10
FreakSoftware,

The documentation says to create a header and implementation file for each category, then have the implemenation file include its own header file, and the header file include the main class file. I've done that, but it does mean a lot more includes in other files since I can't just include the main header if the methods I need are in a category.

Blacktiger,

This "class" is actually my main program, which is why it has so many methods. I'm doing everything in Objective C, so everything has to be in a class as far as I understand.
Quote this message in a reply
Member
Posts: 254
Joined: 2005.10
Post: #11
Gillissie Wrote:This "class" is actually my main program, which is why it has so many methods. I'm doing everything in Objective C, so everything has to be in a class as far as I understand.

Technically, since Objective-C is just a superset of C, you could write a bunch of C functions to run your program. Not that I would recommend that. Wink

Without knowing more about your program it's impossible to give you advice for breaking up your main class. The best thing to do if your class is getting that large is to try to determine areas of your program that are separate from the other areas of your program. For example, in a fairly typical game setup you probably have a loop that checks user input, updates the game world, then renders to the screen. One way of breaking that up would be to move the code that checks user input into an Input class, one for updating the game world, etc. You may have several methods for dealing with input but if you contain them in the input class your main class will be much smaller.
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #12
Thanks for the tips. I have a good deal of experience with breaking up code like that, but not a lot of experience with Obj-C. For reference, my overall program already has 27 classes, including the app delegate and the EAGLView classes.

I'm starting to think it's just a nature of the beast.

[Edit] oh, I just realized that you might be interested in knowing what my program is...
"Stranded Without A Phone"
Quote this message in a reply
⌘-R in Chief
Posts: 1,260
Joined: 2002.05
Post: #13
Gillissie Wrote:FreakSoftware,

The documentation says to create a header and implementation file for each category, then have the implemenation file include its own header file, and the header file include the main class file. I've done that, but it does mean a lot more includes in other files since I can't just include the main header if the methods I need are in a category.

There's more than one way to skin a cat, but that's not what I'd do.


Two uses for categories are:
1) Additions to classes
2) Splitting up large classes into multiple files.

For #1, the main class implementation knows nothing about the other categories. The categories are purely extensions to the main class, they do not implement critical or standard methods. What you describe above is the usage for additions categories.

For #2, there should only be one header to import anywhere, and that's the header for the class. That header should contain all of the method declarations in whatever standard categories there are. The implementation of the categories is split across multiple files. You can do what you describe above, but for the main class to use anything defined in the categories, then it has to include every standard category header and then you have circular imports and they're all just unnecessary to begin with.
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #14
That's what I originally thought and tried, but something didn't work so I looked at the instructions and did it that way. I'd rather do what you described, so I'll probably go back and revisit that now that I have my code organized into separate files. It's easy enough to cut & paste the declarations into the main file.
Quote this message in a reply
Member
Posts: 73
Joined: 2009.03
Post: #15
FreakSoftware Wrote:There's more than one way to skin a cat, but that's not what I'd do.

FreakSoftware, can you show me a working example of what you'd do? I have tried (again) to put all declarations in the main @interface, with only methods in the .m files that import the main header and no .h file for the categories, but the compiler isn't recognizing all the category methods so it shows a ton of warnings.

I'm doing this:

Code:
// MyClass.h

@interface MyClass : NSObject
{    
  members;
}

@properties;

-(void) methods; (including category methods)

@end

Code:
// MyClass.m

#import "MyClass.h"
#import "MyClass+Category.m"  // I have tried with and without this

@implementation MyClass

@synthesize properties;

// methods

@end

Code:
// MyClass+Category.m

#import "MyClass.h"

@implementation MyClass (Category)

// methods

@end
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Cocos2d enemy classes NialG 4 6,302 Dec 31, 2008 05:07 AM
Last Post: NialG