4

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?

3
  • 5
    // THIS IS ABSTRACT CLASS, YOU WILL BE FIRED IF YOU INSTANTIATE IT
    – Bryan Chen
    Oct 20, 2013 at 22:16
  • 2
    Never call a class Class. This will most definitely get you into trouble.
    – gnasher729
    Jan 11, 2016 at 15:50
  • Course, Division, and Section are some useful alternatives to Class.
    – Andrew
    Aug 8, 2016 at 17:55

4 Answers 4

2

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.

1
  • 1
    This is also used in a handful of places in Cocoa: NSCoder, for one.
    – jscs
    Aug 8, 2016 at 18:38
0

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.

0

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.

0

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.

2
  • 1
    You can also annotate methods so that the compiler doesn't allow you to call them directly in your source code. But that's mostly useful if for example you decide that an "init" method cannot give a useful result, and some other initialiser with parameters must be called.
    – gnasher729
    Jan 11, 2016 at 15:55
  • Are you referring to attributes? Jan 12, 2016 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.