Objective-C Lesson in Class Design

I have the following classes:

   Teacher
   Student
   Class (like a school class)

They all extend from KObject that has the following code:

- initWithKey
- send
- processKey

Teacher, Student Class all use the functions processKey and initWithKey from KObject parent class. They implement their own version of send. The problem I have is that KObject should not be instantiated ever. It is more like an abstract class, but there is no abstract class concept in objective-c. It is only useful for allowing subclasses to have access to one property and two functions.

What can I do so that KObject cannot be instantiated but still allow subclasses to have access to the functions and properties of KObject?

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.

Filed under: softwareengineering - @ 04:28

Thẻ: ios, objective-c

Thiết kế website giá rẻ

Danh mục

Objective-C Lesson in Class Design