也许这种情况只会发生在开发阶段，所以这是可行的:

- (id)myMethodWithVar:(id)var {
   NSAssert(NO, @"You most override myMethodWithVar:");
   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的实现，而不是不得不挖掘注释/文档或…假设。

这个帖子有点老了，我想分享的大部分内容已经在这里了。

然而，我最喜欢的方法没有被提及，而且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()可能会让人感到惊讶，但它也很容易理解。) 在发布版本中，如果不生成其他编译器警告或错误，就无法剥离它——这与基于断言宏之一的方法不同。

我想最后一点需要解释一下:

一些(大多数?)人在发布版本中剥离断言。(我不同意这种习惯，但那是另一个故事了……)然而，未能实现所需的方法是糟糕的、可怕的、错误的，基本上是你的程序的宇宙末日。在这方面，您的程序不能正确工作，因为它是未定义的，而未定义的行为是最糟糕的事情。因此，在不生成新的诊断的情况下剥离这些诊断是完全不可接受的。

对于这样的程序员错误，您无法获得适当的编译时诊断，并且不得不求助于运行时发现，这已经够糟糕的了，但是如果您可以在发布版本中掩盖它，为什么要首先尝试使用抽象类呢?

你可以使用@Yar提出的方法(做了一些修改):

#define mustOverride() @throw [NSException exceptionWithName:NSInvalidArgumentException reason:[NSString stringWithFormat:@"%s must be overridden in a subclass/category", __PRETTY_FUNCTION__] userInfo:nil]
#define setMustOverride() NSLog(@"%@ - method not implemented", NSStringFromClass([self class])); mustOverride()

在这里你会得到这样的消息:

<Date> ProjectName[7921:1967092] <Class where method not implemented> - method not implemented
<Date> ProjectName[7921:1967092] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[<Base class (if inherited or same if not> <Method name>] must be overridden in a subclass/category'

或断言:

NSAssert(![self respondsToSelector:@selector(<MethodName>)], @"Not implemented");

在这种情况下，你会得到:

<Date> ProjectName[7926:1967491] *** Assertion failure in -[<Class Name> <Method name>], /Users/kirill/Documents/Projects/root/<ProjectName> Services/Classes/ViewControllers/YourClass:53

您也可以使用协议和其他解决方案-但这是最简单的解决方案之一。

只是重复了上面@Barry Wark的回答(并更新到iOS 4.3)，并把这个留给我自己参考:

#define mustOverride() @throw [NSException exceptionWithName:NSInvalidArgumentException reason:[NSString stringWithFormat:@"%s must be overridden in a subclass/category", __PRETTY_FUNCTION__] userInfo:nil]
#define methodNotImplemented() mustOverride()

在你的方法中你可以使用这个

- (void) someMethod {
     mustOverride(); // or methodNotImplemented(), same thing
}

注意:不确定是否使宏看起来像一个C函数是一个好主意，但我会保持它直到学校相反。我认为使用NSInvalidArgumentException(而不是NSInternalInconsistencyException)更正确，因为这是运行时系统在响应doesNotRecognizeSelector被调用时抛出的(参见NSObject文档)。

另一种替代方法

只要在抽象类和断言或异常中检查类，无论你喜欢什么。

@implementation Orange
- (instancetype)init
{
    self = [super init];
    NSAssert([self class] != [Orange class], @"This is an abstract class");
    if (self) {
    }
    return self;
}
@end

这消除了重写init的必要性