Doh! superclass question


#1

NSObject <- Person <- Employee
The superclass of Employee is Person.

Say I have this hierarchy: NSObject <- Industry <- Company <- Employee
To access the Industry class I would use what syntax?


#2

First, let me poke a hole in the question: inheritance is designed around specialization of objects.

The employees at a company are people, and are a subset of all people, so they fit the concept: they’re a special class of people.

Arrays whose values can be changed are still arrays, a subset of all arrays, so NSMutableArray inherits from NSArray.

An employee is almost never company, a company is almost never an industry, so that inheritance chain doesn’t fit the traditional OO model. You can write your code that way, but it’s certainly not designed to work that way.

Let me get off my soapbox (sorry) and ask for clarification of what you’re trying to do, then I’d be happy to assist if I can.


#3

ahaha… my example makes no sense, but your comments help.
I’m still getting my sea legs for OOP, so I appreciate the input.

I think (hope) I have the idea now, what about:
NSObject <- Person <- Employee <- Accountant

I don’t have a problem to solve, I’m just curious about how to get further up the hierarchy.


#4

Gotcha. Yes, an Accountant is fine, although not all accountants of a company will typically be employed by the company… (ok, perhaps I’m picking at nits).

Anyway, you generally don’t have to access the superclass, but if you do, the implied object super will do the trick.

Let’s say that employees get a week of vacation per year of service (admittedly, fantasy-land), but accountants, being nose to the grindstone guys, are expected to be chained to their desks, so they get 2 days fewer per year of service.

So class Employee might define a method (this might not compile out of the box, just brainstorming here):

// Employee.m
- (NSUInteger) vacationDaysEarned
{
    return [self yearsOfService] * 5;
}

While Accountant might override that method:

// Accountant.m
- (NSUInteger) vacationDaysEarned
{
    return [self yearsOfService] * 3;
}

The problem here is that if the accountants’ time off is directly tied to employees’ time off in the employee handbook, but not the code, you leave the possibility for inconsistencies. If I bump the employees up to 8 days off per year of service, accountants are still stuck at 3 until I remember to bump them up as well.

So, to model the “real” world rules, you can defer to the Employee class for the initial time off value:

// Accountant.m
- (NSUInteger) vacationDaysEarned
{
    return [super vacationDaysEarned] - ([self yearsOfService] * 2);
}

Which says that you get as many as all other employees, except for 2 days fewer per year. Now when the Employee class is bumped to 8 days/year, Accounts jump to 6 days/year automatically.

(Note that the parentheses in the last mathematical expression are unnecessary but useful to convey the fact that I definitely intended for the multiplication to take precedence over the subtraction.)


#5

Forgot to mention: the super object will reach as far into the hierarchy as it needs to. If Employee didn’t define the method, but Person did, the Person method would be invoked.

Also, I apologize if none of the above answered what you were actually asking, so feel free to tell me I’m an idiot and what you really wanted me to answer.