Re: Objects not being added to array
Re: Objects not being added to array
- Subject: Re: Objects not being added to array
- From: Chris Hanson <email@hidden>
- Date: Sun, 17 Dec 2006 21:32:57 -0800
In addition to the other suggestions folks have made (e.g. to re-read,
understand, and apply the Cocoa memory management documentation) I
have a few stylistic suggestions of my own that I hope will help lead
you to a solution. Oh, it also looks like you're using == to compare
NSString instances (search for @"flac"). Don't do that, it won't
work; Objective-C isn't C++, so all == will do in this case is compare
pointers, not contents.
*** Use the most appropriate class for the job
Though I've only skimmed your code, it looks like you're using an
NSArrayController as a form of mutable ordered collection. Don't.
Use an NSMutableArray for this instead. An NSArrayController is
specifically intended to act as a mediator between your data model and
your views in a model-view-controller architecture. An
NSArrayController is not a data model object in and of itself.
*** Use Cocoa-standard naming conventions
You have a lot of variables with names like cur_artist; in writing
Cocoa code, you should use a name like currentArtist instead. This
will make your code more comfortable to other Cocoa developers and
will make it much easier for whoever else works on your project --
even if that's yourself, six months from now -- to pick it up and
start working with it. (This is part of why understanding the memory
management conventions is important too; not following them, even if
you wind up eliminating leaks and double-frees, will make your code
harder to work with.)
*** Create classes for your model objects
Your code is using a lot of collections as model objects. Most code
is a lot better off in the long term using real model objects instead
of collections. If you do this, instead of a mass of -objectAtIndex:
and -addObject: messages, or -objectForKey: and -setObject:forKey:
messages, your code will have messages that are much more intention-
revealing.
For example, you have code like this:
[tapeBunch addObject:cur_artist];
[tapeBunch addObject:cur_venue];
[tapeBunch addObject:cur_location];
where tapeBunch is an NSMutableArray. It should be an instance of a
TapeBunch object, with appropriate accessor methods or a multi-
argument initializer:
[tapeBunch setArtist:currentArtist];
[tapeBunch setVenue:currentVenue];
[tapeBunch setLocation:currentLocation];
Isn't this a whole lot clearer? It also makes your code easier to
refactor. For example, lets say in a future refactoring you add
Artist, Venue, and Location classes rather than representing them as
NSString instances. If you change the signatures of your TapeBunch
accessor methods to take and return instances of these new classes,
you'll get warnings elsewhere in the code where you still pass these
methods NSString objects, directing you to the places you need to fix
up to complete the refactoring.
*** Write short methods and leverage method composition.
You could probably slice and dice your code into a few methods, each
of which does one thing well. This will make it easier to smoke out
errors in the code, and it will also make the code a lot easier to
write unit tests for. It will also improve the readability of your
code, since -- assuming you use intention-revealing method names --
your code itself will be a fairly clear expression of what it's
supposed to do at any particular granularity. (One good guideline
I've seen in this area is to try to extract the bodies of loops into
their own methods, and possibly also the loops themselves.)
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden