我最初是一名Java程序员,现在使用Objective-C。我想创建一个抽象类,但这在Objective-C中似乎不可能。这可能吗?
如果不是,在Objective-C中,我能有多接近抽象类?
我最初是一名Java程序员,现在使用Objective-C。我想创建一个抽象类,但这在Objective-C中似乎不可能。这可能吗?
如果不是,在Objective-C中,我能有多接近抽象类?
当前回答
从Omni组邮件列表:
Objective-C没有像Java那样的抽象编译器结构 这一次。
因此,您所要做的就是将抽象类定义为任何其他正常类 并为抽象方法实现方法存根 空或报告不支持选择器。例如……
- (id)someMethod:(SomeObject*)blah
{
[self doesNotRecognizeSelector:_cmd];
return nil;
}
我还执行以下操作来防止抽象的初始化 通过默认初始化式初始化。
- (id)init
{
[self doesNotRecognizeSelector:_cmd];
[self release];
return nil;
}
其他回答
(更多相关的建议)
我想有一种方法让程序员知道“不要从子调用”,并完全覆盖(在我的情况下,仍然提供了一些默认功能,代表父时,未扩展):
typedef void override_void;
typedef id override_id;
@implementation myBaseClass
// some limited default behavior (undesired by subclasses)
- (override_void) doSomething;
- (override_id) makeSomeObject;
// some internally required default behavior
- (void) doesSomethingImportant;
@end
这样做的好处是程序员会看到声明中的“override”,并且知道他们不应该调用[super ..]。
当然,必须为此定义单独的返回类型是很难看的,但它可以作为一个足够好的视觉提示,并且您可以很容易地在子类定义中不使用“overrides”部分。
当然,当扩展是可选的时,类仍然可以有默认实现。但是,就像其他答案所说的那样,在适当的时候实现一个运行时异常,比如对于抽象(虚拟)类。
如果有像这样的内置编译器提示就好了,甚至提示什么时候最好预/后调用super的实现,而不是不得不挖掘注释/文档或…假设。
我想出的解决办法是:
为“抽象”类中需要的所有内容创建一个协议 创建一个实现协议的基类(也可以称之为抽象类)。对于所有你想要“抽象”的方法,在.m文件中实现它们,而不是在.h文件中实现。 让你的子类继承基类并实现协议。
这样,编译器就会对协议中没有由你的子类实现的任何方法发出警告。
它不像Java中那样简洁,但您确实会得到所需的编译器警告。
这个帖子有点老了,我想分享的大部分内容已经在这里了。
然而,我最喜欢的方法没有被提及,而且AFAIK在当前的Clang中没有原生支持,所以我在这里…
首先,也是最重要的(正如其他人已经指出的),抽象类在Objective-C中是非常不常见的——我们通常使用组合(有时通过委托)来代替。这可能就是为什么语言/编译器中还没有这样的特性的原因——除了@dynamic属性,IIRC在ObjC 2.0中随着CoreData的引入而添加了@dynamic属性。
但考虑到(在仔细评估你的情况后!)你已经得出结论,委托(或一般的组合)并不适合解决你的问题,以下是我是如何做的:
Implement every abstract method in the base class. Make that implementation [self doesNotRecognizeSelector:_cmd];… …followed by __builtin_unreachable(); to silence the warning you’ll get for non-void methods, telling you “control reached end of non-void function without a return”. Either combine steps 2. and 3. in a macro, or annotate -[NSObject doesNotRecognizeSelector:] using __attribute__((__noreturn__)) in a category without implementation so as not to replace the original implementation of that method, and include the header for that category in your project’s PCH.
我个人更喜欢宏版本,因为它可以让我尽可能减少样板文件。
下面就是:
// Definition:
#define D12_ABSTRACT_METHOD {\
[self doesNotRecognizeSelector:_cmd]; \
__builtin_unreachable(); \
}
// Usage (assuming we were Apple, implementing the abstract base class NSString):
@implementation NSString
#pragma mark - Abstract Primitives
- (unichar)characterAtIndex:(NSUInteger)index D12_ABSTRACT_METHOD
- (NSUInteger)length D12_ABSTRACT_METHOD
- (void)getCharacters:(unichar *)buffer range:(NSRange)aRange D12_ABSTRACT_METHOD
#pragma mark - Concrete Methods
- (NSString *)substringWithRange:(NSRange)aRange
{
if (aRange.location + aRange.length >= [self length])
[NSException raise:NSInvalidArgumentException format:@"Range %@ exceeds the length of %@ (%lu)", NSStringFromRange(aRange), [super description], (unsigned long)[self length]];
unichar *buffer = (unichar *)malloc(aRange.length * sizeof(unichar));
[self getCharacters:buffer range:aRange];
return [[[NSString alloc] initWithCharactersNoCopy:buffer length:aRange.length freeWhenDone:YES] autorelease];
}
// and so forth…
@end
如您所见,宏提供了抽象方法的完整实现,将必要的样板文件数量减少到绝对最小。
更好的选择是游说Clang团队通过特性请求为这种情况提供一个编译器属性。(更好,因为这也将为那些你子类化NSIncrementalStore的场景启用编译时诊断。)
为什么选择这种方法
它能有效地完成工作,而且有点方便。 这很容易理解。(好吧,__builtin_unreachable()可能会让人感到惊讶,但它也很容易理解。) 在发布版本中,如果不生成其他编译器警告或错误,就无法剥离它——这与基于断言宏之一的方法不同。
我想最后一点需要解释一下:
一些(大多数?)人在发布版本中剥离断言。(我不同意这种习惯,但那是另一个故事了……)然而,未能实现所需的方法是糟糕的、可怕的、错误的,基本上是你的程序的宇宙末日。在这方面,您的程序不能正确工作,因为它是未定义的,而未定义的行为是最糟糕的事情。因此,在不生成新的诊断的情况下剥离这些诊断是完全不可接受的。
对于这样的程序员错误,您无法获得适当的编译时诊断,并且不得不求助于运行时发现,这已经够糟糕的了,但是如果您可以在发布版本中掩盖它,为什么要首先尝试使用抽象类呢?
我通常只在我想要抽象的类中禁用init方法:
- (instancetype)__unavailable init; // This is an abstract class.
这将在编译时在该类上调用init时生成一个错误。然后我用类方法来处理其他事情。
Objective-C没有内置的方法来声明抽象类。
如果你习惯了编译器在其他语言中捕捉抽象实例化的冲突,那么Objective-C的行为是令人失望的。
作为一种后期绑定语言,Objective-C显然不能对一个类是否真的是抽象的做出静态决定(你可能在运行时添加函数……),但对于典型的用例来说,这似乎是一个缺点。我更喜欢编译器直接阻止抽象类的实例化,而不是在运行时抛出错误。
下面是我们使用的一个模式,使用一些技术来隐藏初始化式来获得这种类型的静态检查:
//
// Base.h
#define UNAVAILABLE __attribute__((unavailable("Default initializer not available.")));
@protocol MyProtocol <NSObject>
-(void) dependentFunction;
@end
@interface Base : NSObject {
@protected
__weak id<MyProtocol> _protocolHelper; // Weak to prevent retain cycles!
}
- (instancetype) init UNAVAILABLE; // Prevent the user from calling this
- (void) doStuffUsingDependentFunction;
@end
//
// Base.m
#import "Base.h"
// We know that Base has a hidden initializer method.
// Declare it here for readability.
@interface Base (Private)
- (instancetype)initFromDerived;
@end
@implementation Base
- (instancetype)initFromDerived {
// It is unlikely that this becomes incorrect, but assert
// just in case.
NSAssert(![self isMemberOfClass:[Base class]],
@"To be called only from derived classes!");
self = [super init];
return self;
}
- (void) doStuffUsingDependentFunction {
[_protocolHelper dependentFunction]; // Use it
}
@end
//
// Derived.h
#import "Base.h"
@interface Derived : Base
-(instancetype) initDerived; // We cannot use init here :(
@end
//
// Derived.m
#import "Derived.h"
// We know that Base has a hidden initializer method.
// Declare it here.
@interface Base (Private)
- (instancetype) initFromDerived;
@end
// Privately inherit protocol
@interface Derived () <MyProtocol>
@end
@implementation Derived
-(instancetype) initDerived {
self= [super initFromDerived];
if (self) {
self->_protocolHelper= self;
}
return self;
}
// Implement the missing function
-(void)dependentFunction {
}
@end