[objective-c] Objective-C에서 추상 클래스 작성

이 스레드는 오래되었으며 공유하고 싶은 대부분은 이미 여기에 있습니다.

그러나 내가 가장 좋아하는 방법은 언급되어 있지 않으며 AFAIK는 현재 Clang에서 기본 지원이 없으므로 여기로 이동하십시오.

첫째, 다른 사람들이 이미 지적했듯이 추상 클래스는 Objective-C에서 매우 드문 일입니다. 우리는 대개 컴포지션 (때로는 위임을 통해)을 사용합니다. 이것은 아마도 이러한 기능이 언어 / 컴파일러에 존재하지 않는 이유 일 것입니다. @dynamic속성 과는 별도로 IIRC가 CoreData의 도입과 함께 ObjC 2.0에 추가되었습니다.

그러나 위임 (또는 일반적으로 조성물) 당신의 문제를 해결하는 데 적합하지 않습니다 있다는 결론에 도달했다 (! 상황의주의 깊은 평가 후) 여기 방법은 주어진 나는 그것을 할 :

1. 기본 클래스에서 모든 추상 메소드를 구현하십시오.
2. 구현하십시오 [self doesNotRecognizeSelector:_cmd];…
3. … __builtin_unreachable();공백하지 않은 방법에 대해 경고 메시지를 끄면“반환없이 비 공백 기능의 끝에 도달했다는 제어”를 알려줍니다.
4. 매크로에서 2 단계와 3 단계를 결합하거나 구현없이 카테고리에서 -[NSObject doesNotRecognizeSelector:]사용하여 주석 을 달아 해당 메소드의 원래 구현을 대체하지 말고 해당 카테고리의 헤더를 프로젝트 PCH에 포함 시키십시오.__attribute__((__noreturn__))

필자는 개인적으로 상용구를 최대한 줄일 수있는 매크로 버전을 선호합니다.

여기있어:

// 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와 같은 서브 클래스 시나리오에서 컴파일 타임 진단을 가능하게하기 때문에 더 좋습니다.)

이 방법을 선택하는 이유

1. 효율적이고 다소 편리하게 작업이 완료됩니다.
2. 이해하기 쉽습니다. (좋아요, __builtin_unreachable()사람들을 놀라게 할 수도 있지만 이해하기도 쉽습니다.)
3. 어설 션 매크로 중 하나를 기반으로하는 접근 방식과 달리 다른 컴파일러 경고 나 오류를 생성하지 않으면 릴리스 빌드에서 제거 할 수 없습니다.

마지막 요점은 약간의 설명이 필요합니다.

릴리스 빌드에서 일부 (가장?) 사람들이 어설 션을 제거합니다. (나는 그 습관에 동의하지 않지만, 그것은 또 다른 이야기이다 …) 그러나 필요한 방법을 구현하지 못하는 것은 – 나쁜 , 끔찍한 , 잘못된 , 그리고 기본적으로 당신의 프로그램을위한 우주의 끝이다 . 프로그램이 정의되지 않았기 때문에 프로그램이 이와 관련하여 올바르게 작동 할 수 없으며 정의되지 않은 동작이 최악입니다. 따라서 새로운 진단을 생성하지 않고 해당 진단을 제거 할 수 있으면 완전히 수용 할 수 없습니다.

그러한 프로그래머 오류에 대해 적절한 컴파일 타임 진단을 얻을 수 없으며 런타임 오류 발견에 의존해야하지만 릴리스 빌드에서 오류를 해결할 수 있다면 왜 추상 클래스를 사용해보십시오. 처음?

---