I develop CHDataStructures, a library of Cocoa data structures to supplement those in Foundation. It includes a fair number of classes (stacks, queues, and dequeues) that share common implementation details, so it makes sense to design them with a common parent class which I treat as abstract (Objective-C doesn't natively enforce this concept). For example, CHAbstractCircularBufferCollection encapsulates nearly all the logic for structures that utilize a circular buffer under the covers. Its child classes inherit the core behaviors, and conform to the appropriate protocol so only the methods that pertain to that protocol are added. (So a queue doesn't expose stack methods, etc.)
This has been working just fine, and correctness and coverage are verifiable via unit tests. However, the downside to the current approach is that each concrete subclass has a #import
to include the header for the abstract parent class (see this header and implementation) — this means I have to export the parent class headers so client code will compile. It would be ideal if there is a way to use @class
in the header rather than #import
, so that calling code doesn't have to know or care about the abstract parent class. (It would also simplify and marginally shrink the size of the framework.) However, when I try this:
// CHCircularBufferQueue.h
#import "CHQueue.h"
@class CHAbstractCircularBufferCollection;
@interface CHCircularBufferQueue : CHAbstractCircularBufferCollection <CHQueue>
@end
I get this error, even if I #import CHAbstractCircularBufferCollection.h
in the .m file:
Cannot find interface declaration for 'CHAbstractCircularBufferCollection', superclass of 'CHCircularBufferQueue'
I want the compiler to know about the parent class I'm extending, but not require clients to. Is there a way to accomplish what I want to do, and eliminate irrelevant headers from my distribution?
PS - This framework arose mostly from academic curiosity, but I'm considering making changes to make it more like Foundation collections by using class clusters and private subclasses. That would also solve this problem, but I'm curious whether there is a feasible way to do what I'm asking.