Objective-C Lesson in Class Design

Using a Protocol is probably the cleanest way to achieve your desired behavior. Bryan Chen's comment reminded me of a pattern I saw while going through some legacy analytics code. An abstract class was created which raised exceptions if called directly:

- (void)startAnalyticsSession { [NSException raise:NSInternalInconsistencyException format:@"You must override %@ in a subclass", NSStringFromSelector(_cmd)]; } - (void)stopAnalyticsSession { [NSException raise:NSInternalInconsistencyException format:@"You must override %@ in a subclass", NSStringFromSelector(_cmd)]; } 

This is a rough example of the adapter pattern. In your case, you could create an abstract class with these stubbed out methods which all other classes inherit from.

KObject could have a single init method init:secret In this way, only callers with the shared secret would be instantiated. One downside, however, is that the subclasses would have to know this code to pass.

The abstract concept does not exist in Objective-C, but what may help you are Protocols.

Other workaround is to set the default implementation to raise an exception. But there is a problem with this solution, you can only see if something is wrong during the runtime, but will not get errors during compilation, like you would in Java or C#, for example.

However, before developing any further, I think there is a bigger problem with your application, the design itself. Your inheritance may be broken.

Unless the only methods the Teacher, Student and Class classes use aren't the methods initWithKey, send and processKey, your are inherently breaking the LSP, and should probably go with composition instead.

You can use a protocol, like so:

@protocol kObject - (instancetype) initWithKey: (NSString *) key; // I'm assuming the key is a string. - (void) send; - (void) processKey; @end 

However, it's uncommon in Objective-C for initializers to be declared in a protocol, and to enforce the LSP you would need to type any method or function that used one of these classes as id<kObject>, which is atypical given the use case.

Generally, there isn't really anything in Objective-C that can prevent a base class from being implemented or invoked. What I've done in the past is left comments in the header, and had the default implementation throw an exception. You won't get compile-time errors, but the code will still stop and you can enforce the constraints of your design that way.

I think of the Python motto, "We're all consenting adults" whenever dealing with abstract classes in Objective-C - it's on the programmer to enforce this given the highly dynamic and (practically) entirely public nature of Objective-C. I trust that if I say it shouldn't be done, it will be adhered to. Exceptions enforce this, even if a bit heavy handed. Alternatively, you can just have the methods return immediately too - making the class useless.

As an aside, you may have luck declaring the property as a protected instance variable, should you not need other classes, methods, or functions to directly access the kObject property.