2011/2/16 Ivan Vučica <[email protected]> > > > 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.
_______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
