mikeash.com pyblog/friday-qa-2010-03-12-subclassing-class-clusters.html comments

mikeash - 2010-04-30 01:20:53

Fri, 30 Apr 2010 01:20:53 GMT

I don't think I've ever created one or seen a reason to. Class clusters are usually most useful for an API provider, since they make it easy to change the implementation of something behind the scenes without breaking client code, and provide specialized implementations for different uses. When you're writing both sides, you can just access stuff more directly, or use a more explicit factory pattern.

For the implementation, I'd probably do something like:



    + (id)allocWithZone: (NSZone *)zone

    {

        if(self == [MyAbstractClass class])

            return [MyAbstractClassInitFactory allocWithZone: zone];

        else

            return [super allocWithZone: zone];

    }

    

    @implementation MyAbstractClassInitFactory

    

    - (id)init

    {

        [self release];

        return [[MyConcreteClassThatHandlesInit alloc] init];

    }

    

    - (id)initWithSomeObject: (id)

    {

        [self release];

        return [[MyConcreteClassThatHandlesSomeObject alloc] init];

    }

    

    // etc.

Anonymous - 2010-04-29 14:57:58

Thu, 29 Apr 2010 14:57:58 GMT

Great write-up as usual. I'm more curious though about your take on creating class clusters; specifically, when it's appropriate or not, how to safely patch the init chain when instantiating a subclass, etc.

mikeash - 2010-03-15 02:32:00

Mon, 15 Mar 2010 02:32:00 GMT

Alex J: I don't think your plan is as simple as you think. What if I want to subclass an abstract class to create another abstract class by not overriding all of the necessary methods, like NSMutableString does? You could allow that with extra keywords and such, but it adds complication.

Worse, I think, is the fact that method implementations cannot all be seen by the compiler at compile time. What if your class is concrete by virtue of a category that the compiler doesn't know about? What if it's concrete because you add the necessary methods at runtime? Again, you can fix this with more extra keywords, but that's more complication. Although ObjC 2.0 is getting away from it to some extent, ObjC's underlying philosophy is to be a minimal set of extensions to C, so I think a complicated system of abstract class keywords wouldn't be worth it.

Alex J - 2010-03-14 18:05:38

Sun, 14 Mar 2010 18:05:38 GMT

There are two things that a compiler can enforce with abstract classes: definition and instantiation. While I agree that detecting instantiation of abstract classes wouldn't make a lot of sense in Obj C, it would be possible to treat an incomplete implementation as an error. It would b fairly easy to tag abstract classes and methods (e.g. @abstract) and then refuse to compile if a concrete subclass does not implement all of the abstract methods from its superclasses. Personally, I am a fan of lettin the compiler do this kind of work fir me, rather than scouring the documentation or blowing up at runtime.

mikeash - 2010-03-13 18:48:27

Sat, 13 Mar 2010 18:48:27 GMT

From what I can tell, "class cluster" describes much more than Abstract Factory, although it involves an Abstract Factory. Abstract Factory is simply a class which instantiates objects of other, hidden classes. Class clusters involve that, but also have the notion of explicitly allowing subclasses, with required primitive methods and a great deal of concrete functionality implemented in the base class that's built on top of the primitives. I don't see any of those aspects in the descriptions of Abstract Factory that I've found.

Jens Ayton - 2010-03-13 12:09:45

Sat, 13 Mar 2010 12:09:45 GMT

Trevor: for the simple reason that Cocoa’s usage predates the GoF book and the habit of Patterns With Names in Capital Letters.

Incidentally, there’s another problem with compiler checking of virtual classes: it’s normal and correct to use the standard allocation pattern with a class cluster, as in [[NSArray alloc] initWithSomething]. In this case, a subclass (or proxy) could validly be returned by +alloc, -initWithSomething, or both, and this could change between system versions.

Trevor - 2010-03-13 05:06:15

Sat, 13 Mar 2010 05:06:15 GMT

For those wondering... Class clusters are more commonly known as the Abstract Factory design pattern. Not sure why Cocoa has to use different terminology.

Jens Ayton - 2010-03-13 00:18:55

Sat, 13 Mar 2010 00:18:55 GMT

There’s not much compiler-enforced anything in Objective-C, and the idea doesn’t fit the nature of the language. How would you go about doing this in the compiler? Object creation doesn’t involve a special operator, and you need to be able to refer to the class object for things like isKindOfClass: checks.

If you really wanted, you could override +alloc to refuse to allocate instances of an abstract class, but there’s little advantage to having a runtime failure in +alloc rather than slightly later when you try to actually use the object (or in the initializer).

mikeash - 2010-03-12 23:44:35

Fri, 12 Mar 2010 23:44:35 GMT

There aren't. I've never found it to be a problem. The typical pattern is to call out the necessary overrides in the docs/header, and implement the methods to log an error so it's easy to find at runtime:



- (void)somePrimitiveMethod

{

    NSLog(@"-[AbstractClass somePrimitiveMethod] called, this should never happen. Did you forget to implement -[%@ somePrimitiveMethod]?", [self class]);

    [self doesNotUnderstand: _cmd];

}

This works well enough.

Mike V - 2010-03-12 23:00:43

Fri, 12 Mar 2010 23:00:43 GMT

Is it true that there are no compiler-enforced abstract classes in Obj-C? That's a shame if so.

mikeash - 2010-03-12 21:14:41

Fri, 12 Mar 2010 21:14:41 GMT

No, because I'm not implementing init, so I don't need super. In this particular case, both are equivalent, because I don't override init, but if I did, I would want it to be called.

See http://www.mikeash.com/pyblog/the-how-and-why-of-cocoa-initializers.html

Dave DeLong - 2010-03-12 20:59:57

Fri, 12 Mar 2010 20:59:57 GMT

Are you sure you meant to do:

if ((self = [self init])) { ... }

Shouldn't it be [super init]?