2011/2/16 Ivan Vučica
<ivucica@gmail.com>
> The other thing is that declarations of interfaces, protocols, and implementations in Objective-C very much look like statements rather than beginnings-of-constructs and ends-of-constructs. In C and C++, I can scan a header file and go, "there's two classes in there, and they interact thusly". In Objective-C it just seems like an amorphous blob of @foo directives and method declarations and I often miss that there's more than one object in a header. Is this just my brain? Xcode's and Vim's syntax highlighting?
I found it a good practice to avoid putting multiple classes in a single file in C++, too. In ObjC, that's even easier, and I do it as rarely as possible.
The problem here is that the bulkiness of separate files for each class, along with the bulkiness of separate @interface and @implementation, (along with lack of lexical scope for class names and/or namespaces) discourages really small classes when they would otherwise logically improve design.
Also, I find that it's a pain to create everything I need for one view or controller class:
1. The class's .h
2. The class's .m
3. The class's Kiwi *Spec.m or unit test file.
4. The class's delegate's *Protocol.h (assuming this class is a view and has a back reference to it's data source or delegate).
I usually put the delegate's protocol in the class's .h.
Also, if there are some classes which can be declared within a .m because they by design have a single client (for example, a strategy pattern which just encapsulates how to load something from a file or an NSData), I do that rather than expose them.