|
The Philosophy of Cocoa
Small is Beautiful and Lazy is Good
©2002 Andrew C. Stone All Rights Reserved
I believe a programming renaissance is upon us—and Cocoa, Apple’s high level object-oriented framework is at the heart of it. By wrapping complexity inside easy-to-use objects, Cocoa frees application developers from the burden of the minutiae that so often drives developers crazy. Instead, they can focus on what’s special about their applications, and in a few lines of code, create a complete OS X application that seamlessly interoperates with all other OS X applications. And, for very little additional effort, they get AppleScriptability as well.
I’ve been living and breathing Cocoa and its various previous incarnations for 14 years now, and have noticed that my applications are getting more features with smaller amounts of code each year. This article will explore some of the truisms and gems hard earned by hanging in the trenches lo these many years.
Small is Beautiful
It’s no coincidence that we use the term “architecture” for the overarching structure of an application. I received my baccalaureate in classical Architecture in the ‘70’s when the visionaries of the time were rebelling against the huge concrete boxes that crushed the human scale and spirit. E. F. Schumacher, in Small is Beautiful - A Study of Economics as if People Mattered:
“What I wish to emphasise is the duality of the human requirement when it comes to the question of size: there is no single answer. For his different purposes man needs many different structures, both small ones and large ones, some exclusive and some comprehensive. Yet people find it most difficult to keep two seemingly opposite necessities of truth in their minds at the same time. They always tend to clamour for a final solution, as if in actual life there could ever be a final solution other than death. For constructive work, the principal task is always the restoration of some kind of balance. Today, we suffer from an almost universal idolatry of giantism. It is therefore necessary to insist on the virtues of smallness - where this applies. ...” (p. 54)
I believe this thinking still rings true 30 years later in cyber-architecture.
From the programming classic The Mythical Man Month by Frederick P. Brooks, Jr., we learned that the more programmers you throw at a project, the less likely the project will ever be finished! From this follows that a project should have one central architect, with rather fascist control over feature set and implementation, especially if you want it to ship in a timely fashion. Cocoa gives you the tools needed to build full-featured, world-class applications with just a handful of programmers. For best effect, these programmers should be lazy...
Lazy is Good
Laziness is a virtue, believe it or not! I often describe my style of a computer scientist as someone who is so lazy that they’ll spend days writing software to save a minute each time the task is performed from then on. There are two forms of laziness that Cocoa embraces: lazy loading of objects and just plain lazy programming.
Bundle it Up
Lazy loading lets full-featured applications like Stone Design’s Create®, a three-in-one illustration, page layout and web authoring app, launch in just a few seconds. Compare that to a legacy Carbon application with half the features which takes minutes to launch! By using dynamically loaded bundles, you do not use memory or resources until the end user actually needs that particular feature and its related resources. Moreover, you can update and distribute just the tiny bundle instead of the whole application should, heaven forbid, a bug be found!
To use dynamically loaded bundles, you need to be able to compile your application without actually referencing the loadable object directly. We do this runtime magic by only referring to the dynamically loaded class, the principal class of the bundle, by its name as a string.
Typically, the types of objects that do well being loaded dynamically are the numerous special editors and interfaces in a program, such as an arrow or pattern editor and the classes it needs to provide the interface. The following conditions make up a good candidate for a loadable bundle:
• Has resources that are not always used each session
• Doesn’t contain core data model classes (these should be linked)
A typical example might have an NSWindowController subclass and perhaps some custom views and images in the bundle. We load this type of bundle by having it respond to the class method “+sharedInstance”, since you usually only need one of these objects per application:
- (void)loadAUniqueInterfaceObjectAction:(id)sender {
// we only use the name of the bundle, not its class
// which would cause an undefined symbol when linking:
[[[NSApp delegate] sharedInstanceOfClassName:@”MyUniqueController”] showWindow:self];
}
But, with the introduction of sheets, two or more documents may want to load the same bundle (for example, a custom zoom sheet) at the same time. In this case, you’ll want a unique instance, which will be released after use. These principal classes of bundles need only respond to -(id)init, which all objects do anyway since they inherit from NSObject which implements -(id)init;
- (void)loadAPerDocumentInterfaceObjectAction:(id)sender {
[[[NSApp delegate] instanceOfClassName:@”MyPerDocumentController”] showWindow:self];
}
And, because we are lazy and more importantly, good programmers, we filter both of these methods through one factored method, -(id)instanceOfClassName:(NSString *)name shared:(BOOL)shared like this:
- (id)sharedInstanceOfClassName:(NSString *)name
{
return [self instanceOfClassName:name shared:YES];
}
- (id)instanceOfClassName:(NSString *)name {
return [self instanceOfClassName:name shared:NO];
}
And here’s the non-linked bundle loading code for both of them, which we place for convenience in the globally available [NSApp delegate] class:
- (id)instanceOfClassName:(NSString *)name shared:(BOOL)shared
{
id obj = nil;
NSString *path = [[NSBundle mainBundle] pathForResource:name ofType:@”bundle”];
if (path) {
// we found the bundle, now load it:
NSBundle *b = [[NSBundle allocWithZone:NULL] initWithPath:path];
// if it loads, see if it has a valid principalClass - this is set in PB’s target inspector
if ((b != nil) && ([b principalClass] !=NULL)) {
// here is the only difference between a single shared instance
// and a new one every time:
if (shared) obj = [[b principalClass] sharedInstance];
else obj = [[[b principalClass] allocWithZone:NULL] init];
} else {
// This is for debugging in case it can’t be loaded:
NSLog(@”Can’t Load %@!\n”, path);
}
} else NSLog(@”Couldn’t find %@ bundle!\n”,name);
return obj;
}
Code Lazily
Lazy programming means “Use the ‘Kit, Luke!” Every standard data structure and a complete set of API’s are already available to you, so there is rarely a need to reinvent your own. Therefore, this lazy programming axiom has a corollary:
If it’s hard to do or understand, it’s wrong
By this I mean any coding solution that involves convoluted logic or going beneath the API (using undocumented methods) is probably not the right approach. Taking the time to understand what’s already offered to you is well worth the effort, because Cocoa, and its underlying frameworks, Foundation and AppKit, have evolved over 16 years to provide the basic building blocks of an object oriented solution. Many times when I’m adding a new feature, I’ll try one brute force approach, notice how cumbersome it is, re-read the AppKit or Foundation API and find a much a better solution involving much less code.
For example, I recently added a “Clone Client” feature to TimeEqualsMoney™ - take the current document’s data, remove the individual time entries, create a new document with all the same settings except no time entries. It was six lines of code and it worked the first time:
- (void)cloneDocumentAction:(id)sender {
// make a new untitled - have it read our document:
NSMutableDictionary *doc = [self workDocumentDictionary];
MyDocument *newDoc = [[NSDocumentController sharedDocumentController]
openUntitledDocumentOfType:DocumentType display:NO];
[doc removeObjectForKey:WorkKey];
[newDoc loadDataRepresentation:[[doc description] dataUsingEncoding:NSASCIIStringEncoding] ofType:DocumentType];
[newDoc makeWindowControllers];
[[[newDoc windowControllers] objectAtIndex:0] showWindow:self];
}
Instead of hiring programmers, why not let the entire Cocoa team at Apple be your engineers? When you use the Kit and Apple puts in new functionality and bug fixes, your application automatically gains these features and fixes. Your efforts should be focused on creating a mapping between the real world problems you are solving and the objects that represent them. Which brings me to my next point:
Put The Code Where It Belongs
One of the biggest challenges facing newcomers to Object Oriented Programming is placing code in the right object. Because many of us grew up with “procedural” languages like Basic, Pascal, and C, and because old habits die hard, we need to let go of trying to tell things what do to do, and instead, let them figure it out for themselves. Let’s say we have a document which is a list of pages, which contains a list of graphics, which are simple graphics or groups, which contain a list of graphics, which are graphics or groups which contain, etc... And let’s say we want to set the “isVisible” state of all the graphics in the document.
The procedural approach would be to assume absolute knowledge over this hierarchy, and you’d blithely code something like this:
@implementation MyDocument
// please don’t do this!
- (void)setAllObjectsVisible:(BOOL)isVisible {
unsigned int i, pageCount = [_pages count];
for (i = 0; i < pageCount; i++) {
Page *p = [_pages objectAtIndex:i];
NSArray *graphics = [p graphics];
unsigned int j, graphicsCount = [graphics count];
for (j = 0; j < graphicsCount; j++) {
Graphic *g = [graphics objectAtIndex:j];
if ([g isKindOfClass:[Group class]) {
NSArray *groupGraphics = [g graphics];
unsigned k,groupGraphicsCount = [groupGraphics count];
for (k = 0; k < groupGraphicsCount; k++) {
// since this only recurses one level, this code is wrong as
// well as very hard to read and maintain!!!
Graphic *groupedGraphic = [groupGraphics objectAtIndex:k];
[k setVisible:isVisible];
}
else [g setVisible:isVisible];
}
}
)
// the OO way:
@implementation MyDocument
- (void)setAllObjectsVisible:(BOOL)isVisible {
[_pages makeObjectsPerformSelector:@selector(setAllObjectsVisible:) withObject:(id)isVisible];
}
...
@implementation Page
- (void)setAllObjectsVisible:(BOOL)isVisible {
[_graphics makeObjectsPerformSelector:@selector(setVisible:) withObject:(id)isVisible];
}
....
// groups need to recurse down the hierarchy until individual graphics
// are found...
@implementation Group
- (void)setVisible:(BOOL)isVisible {
[_graphics makeObjectsPerformSelector:@selector(setVisible:) withObject:(id)isVisible];
}
@implementation Graphic
- (void)setVisible:(BOOL)isVisible {
// only do work if you absolutely have to - remember LAZY!
if (_isVisible != isVisible) {
// you’d probably do undo manager stuff here
_isVisible = isVisible;
// alert page we need to be redrawn
[self tellMyPageToInvalidateMyBounds];
}
}
...
Conclusion
The more you understand object oriented programming and Cocoa, the smaller and more reusable your applications will become. And they will load with lightning speed! But more importantly, you’ll have less code to maintain which means less bugs, less headaches and more time to enjoy life.
Andrew Stone, CEO of Stone Design, www.stone.com, has been the principal architect of several solar houses and over a dozen Cocoa applications shipping for Mac OS X. |
