Question

Not too sure how to explain this one, but here goes…

I’m building an object structure for my data (in Objective-C) to have the following:

• A Companies collection class
  • which contains many Company objects
    • each one of these has a Users collection class
      • which contains many User objects

The aim is to have data on the objects (i.e. companyID, companyName), and methods on the collection classes (addCompany:, deleteCompany:).

What I really want to do is to structure the classes so that I can make the following call:

[[companies getCompanyWithID:1] addUserWithName:@"Duncan"];

But to do that, I would need to put the method addUserWithName: on the companies collection class.

To me that doesn’t make sense – the methods to add/amend/delete/get users should be on the Users collection class, not on the Companies collection class.

If I put those function on their relevant collection classes, I then have to write the same statement like this:

[[companies getCompanyWithID:1].users addUserWithName:@"Duncan"];

But then it doesn’t read as nicely – because it has a nasty .users lurking in the middle.

Am I being really dumb and missing something obvious (I never went to techie school, so it’s likely I missed something fundamental which you guys all know about).

Any help, much appreciated guys. Thanks a lot.

Answer 1

I may be misunderstanding your concern, but I don’t think this is an issue. Your user management methods would be on Company, not Companies, and that’s generally an acceptable pattern.

Let’s go with the assumption that you have four classes: Companies/Company and Users/User. Now we can define a method:

@interface Companies
- (Company *)companyWithID:(NSUInteger)id;
@end

This says that the Companies class can get you back a Company by its ID. (Side note: in Objective-C, we rarely use the get... prefix for accessor methods – just start the method with the thing that you want, in this case company....)

The traditional thing to do from here would be to have your Company class expose a good chunk of public API for managing users. You might do something like:

@interface Company
- (void)addUserWithName:(NSString *)name;
@end

In turn, the Company class will be responsible for knowing about the inner workings of the Users collection, including modifying it as necessary. With that in mind, you could write:

@implementation Company
- (void)addUserWithName:(NSString *)name {
    [self.users addObject:name]; // self.users is of type `Users *`
}
@end

This way, you avoid exposing the .users to external clients of the Company class – you just pass the add... message forward.

You could even take this strategy further and say that the Users collection class is an implementation detail and never needs to be exposed to clients of the Company class. Instead, you could provide accessors to your Users collection in terms of a more standard system collection object:

@interface Company
- (NSSet *)users;
- (void)addUserWithName:(NSString *)name;
- (void)removeUserWithName:(NSString *)name;
// and so on...
@end

The absolute extreme of this thought process would lead you to get rid of your Users class altogether and just use system classes to manage the collection of users directly on your Company class. On one hand, this would let Xcode infer and suggest (through autocompletion) certain methods that fit this pattern well – take a look at the KVC compliance section of the Key-Value Coding Programming Guide for such methods. On the other hand, you may have more complexity that doesn’t show up in your question, so the Users class may be necessary for your use case.