Large Cocoa Projects

Rainer Brockerhoff, the man without version control, has posted a nice collection of links to posts responding to Brent Simmons' thoughts on large Cocoa projects, plus his own comments on the matter.

Interesting reading altogether. I generally work the same way, and though I never formulated it in my brain, I found that I rarely send notifications either (only in library classes that are, conceptually, part of Cocoa). The only point where I'm noticeably different is that I'm more of a mouse person. Sorry little kittens.

I also do a little folder structure on disk: I have one honkin' huge folder, the UliKit, containing all kinds of utility classes, and of course most of those categories. Also, in projects that have some sort of plugins, I generally put the "built-in plugins" in their own folder, like the custom field types in AngelTemplate.

I also have some bigger reusable code modules that I don't have in the UliKit, most notably UKDistributedView and UKProgressPanel, and a few others. But generally, I have a one-folder-per-project structure on disk, everything littered around the project, with a README.txt part of the project and the only other folders generally being for resources.

Another feature that's very helpful to get around a project is the filter field in Xcode's toolbar, to quickly find the particular source file you're looking for among those 600. Particularly useful when you only know a word in the middle of the file name, and it almost works like type selection, in that it narrows down the searches, and then you can tab into the Detail View and pick the file you want, or use the contextual menu to reveal it in Groups and Files and operate some more on it. The only trouble is, it doesn't work in "Condensed" mode, which I generally prefer.

Though there's some comments by readers I don't agree with as much (No, I'm not talking about the guy bashing liquid layouts -- I hate fixed-width web sites that would force me to scroll even on a cinema display):

I generally try to use categories for two purposes only: To add general-purpose code to a system object that ends up in my UliKit, to more strictly separate the public and private interface of a class, or to split up a class across several files (well, and for informal protocols, but that's a hack ObjC 2.0 will make unnecessary in a few years). In particular, I try not to have any project-specific categories on system classes, because that generally only is a lazy attempt at re-purposing an object that should be subclassed or wrapped.

I say try, because there's a few cases that are so ugly to solve, that suddenly this becomes the cleanest solution.

Reader Comments: (RSS Feed)

No comments yet

Or E-Mail Uli privately.