Tôi ban đầu là một lập trình viên Java, hiện đang làm việc với Objective-C. Tôi muốn tạo một lớp trừu tượng, nhưng điều đó dường như không thể thực hiện được trong Objective-C. Điều này có thể không?

Nếu không, tôi có thể đến gần lớp trừu tượng như thế nào trong Objective-C?

Thông thường, lớp Objective-C chỉ trừu tượng theo quy ước, nếu tác giả ghi lại một lớp là trừu tượng, chỉ không sử dụng nó mà không phân lớp nó. Tuy nhiên, không có thực thi thời gian biên dịch nào ngăn chặn việc khởi tạo một lớp trừu tượng, tuy nhiên. Trong thực tế, không có gì ngăn người dùng cung cấp việc triển khai các phương thức trừu tượng thông qua một danh mục (tức là trong thời gian chạy). Bạn có thể buộc người dùng ít nhất ghi đè các phương thức nhất định bằng cách đưa ra một ngoại lệ trong việc thực hiện các phương thức đó trong lớp trừu tượng của bạn:

[NSException raise:NSInternalInconsistencyException 
            format:@"You must override %@ in a subclass", NSStringFromSelector(_cmd)];

Nếu phương thức của bạn trả về một giá trị, nó sẽ dễ sử dụng hơn một chút

@throw [NSException exceptionWithName:NSInternalInconsistencyException
                               reason:[NSString stringWithFormat:@"You must override %@ in a subclass", NSStringFromSelector(_cmd)]
                             userInfo:nil];

vì sau đó bạn không cần thêm câu lệnh return từ phương thức.

Nếu lớp trừu tượng thực sự là một giao diện (nghĩa là không có triển khai phương thức cụ thể), sử dụng giao thức Objective-C là tùy chọn phù hợp hơn.

Không, không có cách nào để tạo một lớp trừu tượng trong Objective-C.

Bạn có thể giả định một lớp trừu tượng - bằng cách gọi các phương thức / bộ chọn gọi doesNotRecognizeSelector: và do đó đưa ra một ngoại lệ làm cho lớp không thể sử dụng được.

Ví dụ:

- (id)someMethod:(SomeObject*)blah
{
     [self doesNotRecognizeSelector:_cmd];
     return nil;
}

Bạn cũng có thể làm điều này cho init.

Chỉ cần riff về câu trả lời của @Barry Wark ở trên (và cập nhật cho iOS 4.3) và để lại cho tôi tham khảo:

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

sau đó trong phương pháp của bạn, bạn có thể sử dụng

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

Lưu ý: Không chắc việc tạo một macro trông giống như hàm C có phải là một ý tưởng tốt hay không, nhưng tôi sẽ giữ nó cho đến khi đi học ngược lại. Tôi nghĩ rằng nó đúng hơn để sử dụng NSInvalidArgumentException(chứ không phải NSInternalInconsistencyException) vì đó là những gì hệ thống thời gian chạy ném để đáp ứng với doesNotRecognizeSelectorviệc được gọi (xem NSObjecttài liệu).

Giải pháp tôi đưa ra là:

1. Tạo một giao thức cho mọi thứ bạn muốn trong lớp "trừu tượng" của bạn
2. Tạo một lớp cơ sở (hoặc có thể gọi nó là trừu tượng) thực hiện giao thức. Đối với tất cả các phương thức bạn muốn "trừu tượng" triển khai chúng trong tệp .m, nhưng không phải tệp .h.
3. Có lớp con bạn kế thừa từ lớp cơ sở VÀ thực hiện giao thức.

Bằng cách này, trình biên dịch sẽ đưa ra cảnh báo cho bất kỳ phương thức nào trong giao thức không được lớp con của bạn triển khai.

Nó không ngắn gọn như trong Java, nhưng bạn có được cảnh báo trình biên dịch mong muốn.

Từ danh sách gửi thư của Omni Group :

Objective-C không có cấu trúc trình biên dịch trừu tượng như Java tại thời điểm này.

Vì vậy, tất cả những gì bạn làm là định nghĩa lớp trừu tượng như bất kỳ lớp bình thường nào khác và triển khai các phương thức cho các phương thức trừu tượng trống hoặc báo cáo không hỗ trợ cho bộ chọn. Ví dụ...

- (id)someMethod:(SomeObject*)blah
{
     [self doesNotRecognizeSelector:_cmd];
     return nil;
}

Tôi cũng làm như sau để ngăn chặn việc khởi tạo lớp trừu tượng thông qua trình khởi tạo mặc định.

- (id)init
{
     [self doesNotRecognizeSelector:_cmd];
     [self release];
     return nil;
}

Thay vì cố gắng tạo một lớp cơ sở trừu tượng, hãy xem xét sử dụng một giao thức (tương tự như giao diện Java). Điều này cho phép bạn xác định một tập hợp các phương thức và sau đó chấp nhận tất cả các đối tượng phù hợp với giao thức và thực hiện các phương thức. Ví dụ: tôi có thể định nghĩa một giao thức Hoạt động và sau đó có một chức năng như thế này:

- (void)performOperation:(id<Operation>)op
{
   // do something with operation
}

Trong đó op có thể là bất kỳ đối tượng nào thực hiện giao thức Hoạt động.

Nếu bạn cần lớp cơ sở trừu tượng của mình để thực hiện nhiều hơn chỉ đơn giản là xác định các phương thức, bạn có thể tạo một lớp Objective-C thông thường và ngăn không cho nó được khởi tạo. Chỉ cần ghi đè hàm init (id) và làm cho nó trở về nil hoặc assert (false). Đây không phải là một giải pháp rất rõ ràng, nhưng vì Objective-C hoàn toàn năng động, nên thực sự không có tương đương trực tiếp với một lớp cơ sở trừu tượng.

Chủ đề này là loại cũ, và hầu hết những gì tôi muốn chia sẻ đã ở đây.

Tuy nhiên, phương pháp yêu thích của tôi không được đề cập và AFAIK không có hỗ trợ riêng trong Clang hiện tại, vì vậy tôi đến đây

Đầu tiên và trên hết (như những người khác đã chỉ ra) các lớp trừu tượng là một thứ rất không phổ biến trong Objective-C - chúng ta thường sử dụng bố cục (đôi khi thông qua ủy quyền) thay vào đó. Đây có lẽ là lý do tại sao một tính năng như vậy không tồn tại trong ngôn ngữ / trình biên dịch - ngoài @dynamiccác thuộc tính, IIRC đã được thêm vào ObjC 2.0 kèm theo sự ra mắt của CoreData.

Nhưng cho rằng (sau khi đánh giá cẩn thận về tình huống của bạn!) Bạn đã đi đến kết luận rằng ủy nhiệm (hoặc thành phần nói chung) không phù hợp để giải quyết vấn đề của bạn, đây là cách tôi thực hiện:

1. Thực hiện mọi phương thức trừu tượng trong lớp cơ sở.
2. Hãy thực hiện điều đó [self doesNotRecognizeSelector:_cmd];...
3. Sau đó, ông dùng __builtin_unreachable();để tắt tiếng cảnh báo bạn sẽ nhận được các phương thức không có giá trị, cho bạn biết quyền kiểm soát của bạn đã đạt đến cuối chức năng không có khoảng trống mà không cần trả lại.
4. Kết hợp các bước 2. và 3. trong một macro hoặc chú thích -[NSObject doesNotRecognizeSelector:]bằng cách sử dụng __attribute__((__noreturn__))trong một danh mục mà không thực hiện để không thay thế triển khai ban đầu của phương thức đó và bao gồm tiêu đề cho danh mục đó trong PCH của dự án của bạn.

Cá nhân tôi thích phiên bản macro hơn vì điều đó cho phép tôi giảm bản tóm tắt càng nhiều càng tốt.

Đây là:

// 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

Như bạn có thể thấy, macro cung cấp việc thực hiện đầy đủ các phương thức trừu tượng, giảm số lượng nồi hơi cần thiết đến mức tối thiểu.

Một lựa chọn thậm chí tốt hơn sẽ là vận động nhóm Clang cung cấp thuộc tính trình biên dịch cho trường hợp này, thông qua các yêu cầu tính năng. (Tốt hơn, bởi vì điều này cũng sẽ cho phép chẩn đoán thời gian biên dịch cho các tình huống trong đó bạn phân lớp, ví dụ NSIncrementalStore.)

Tại sao tôi chọn phương pháp này

1. Nó hoàn thành công việc một cách hiệu quả và có phần thuận tiện.
2. Nó khá dễ hiểu. (Được rồi, điều đó __builtin_unreachable()có thể làm mọi người ngạc nhiên, nhưng nó cũng đủ dễ hiểu.)
3. Nó không thể bị tước trong các bản dựng phát hành mà không tạo ra các cảnh báo hoặc lỗi biên dịch khác - không giống như cách tiếp cận dựa trên một trong các macro xác nhận.

Điểm cuối cùng cần một số lời giải thích, tôi đoán:

Một số (hầu hết?) Mọi người xác nhận dải trong các bản dựng phát hành. (Tôi không đồng ý với thói quen đó, nhưng đó là một câu chuyện khác ...) Không thực hiện một phương pháp cần thiết - tuy nhiên - là xấu , khủng khiếp , sai , và về cơ bản kết thúc của vũ trụ cho chương trình của bạn. Chương trình của bạn không thể hoạt động chính xác trong vấn đề này vì nó không được xác định và hành vi không xác định là điều tồi tệ nhất. Do đó, việc có thể loại bỏ các chẩn đoán đó mà không tạo ra các chẩn đoán mới sẽ là hoàn toàn không thể chấp nhận được.

Nó đủ tệ đến mức bạn không thể có được chẩn đoán thời gian biên dịch thích hợp cho các lỗi lập trình viên đó và phải dùng đến khám phá tại thời điểm đó, nhưng nếu bạn có thể khắc phục nó trong các bản dựng phát hành, tại sao lại thử có một lớp trừu tượng trong địa điểm đầu tiên?

Sử dụng @propertyvà @dynamiccũng có thể làm việc. Nếu bạn khai báo một thuộc tính động và không đưa ra cách thực hiện phương thức phù hợp, mọi thứ vẫn sẽ được biên dịch mà không có cảnh báo và bạn sẽ gặp unrecognized selectorlỗi khi chạy nếu bạn cố truy cập vào nó. Điều này về cơ bản giống như gọi [self doesNotRecognizeSelector:_cmd], nhưng với việc gõ ít hơn nhiều.

Trong Xcode (sử dụng clang, v.v.) tôi muốn sử dụng __attribute__((unavailable(...)))để gắn thẻ các lớp trừu tượng để bạn gặp lỗi / cảnh báo nếu bạn thử và sử dụng nó.

Nó cung cấp một số bảo vệ chống lại vô tình sử dụng phương pháp.

Thí dụ

Trong @interfacethẻ lớp cơ sở, các phương thức "trừu tượng":

- (void)myAbstractMethod:(id)param1 __attribute__((unavailable("You should always override this")));

Tiến lên một bước này, tôi tạo ra một macro:

#define UnavailableMacro(msg) __attribute__((unavailable(msg)))

Điều này cho phép bạn làm điều này:

- (void)myAbstractMethod:(id)param1 UnavailableMacro(@"You should always override this");

Như tôi đã nói, đây không phải là sự bảo vệ trình biên dịch thực sự nhưng nó cũng tốt như việc bạn sẽ có được một ngôn ngữ không hỗ trợ các phương thức trừu tượng.

Câu trả lời cho câu hỏi nằm rải rác trong các bình luận dưới các câu trả lời đã được đưa ra. Vì vậy, tôi chỉ tóm tắt và đơn giản hóa ở đây.

Tùy chọn1: Giao thức

Nếu bạn muốn tạo một lớp trừu tượng không có triển khai, hãy sử dụng 'Giao thức'. Các lớp kế thừa một giao thức có nghĩa vụ phải thực hiện các phương thức trong giao thức.

@protocol ProtocolName
// list of methods and properties
@end

Tùy chọn 2: Mẫu phương thức mẫu

Nếu bạn muốn tạo một lớp trừu tượng với triển khai một phần như "Mẫu phương thức mẫu" thì đây là giải pháp. Objective-C - Mẫu phương thức mẫu?

Một cách khác

Chỉ cần kiểm tra lớp trong lớp Trừu tượng và Khẳng định hoặc Ngoại lệ, bất cứ điều gì bạn thích.

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

Điều này loại bỏ sự cần thiết phải ghi đè init

(thêm một gợi ý liên quan)

Tôi muốn có một cách để cho lập trình viên biết "không gọi từ trẻ em" và ghi đè hoàn toàn (trong trường hợp của tôi vẫn cung cấp một số chức năng mặc định thay cho cha mẹ khi không được gia hạn):

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

Ưu điểm là lập trình viên sẽ XEM "ghi đè" trong khai báo và sẽ biết họ không nên gọi [super ..].

Cấp, thật xấu khi phải xác định các kiểu trả về riêng cho việc này, nhưng nó phục vụ như một gợi ý trực quan đủ tốt và bạn không thể dễ dàng sử dụng phần "override_" trong định nghĩa lớp con.

Tất nhiên một lớp vẫn có thể có một triển khai mặc định khi một phần mở rộng là tùy chọn. Nhưng giống như các câu trả lời khác, thực hiện ngoại lệ thời gian chạy khi thích hợp, như đối với các lớp trừu tượng (ảo).

Sẽ thật tuyệt nếu được xây dựng trong các gợi ý về trình biên dịch như thế này, thậm chí là gợi ý khi nào là tốt nhất để gọi trước / đăng cuộc gọi của siêu thực hiện, thay vì phải tìm hiểu các bình luận / tài liệu hoặc ... giả định.

Nếu bạn đã quen với trình biên dịch bắt các vi phạm khởi tạo trừu tượng trong các ngôn ngữ khác, thì hành vi Objective-C gây thất vọng.

Là ngôn ngữ ràng buộc muộn, rõ ràng Objective-C không thể đưa ra quyết định tĩnh về việc một lớp có thực sự trừu tượng hay không (bạn có thể thêm các hàm khi chạy ...), nhưng đối với các trường hợp sử dụng thông thường thì điều này có vẻ như là một thiếu sót. Tôi thích trình biên dịch ngăn chặn ngay lập tức các lớp trừu tượng thay vì đưa ra một lỗi trong thời gian chạy.

Dưới đây là một mẫu chúng tôi đang sử dụng để có được loại kiểm tra tĩnh này bằng cách sử dụng một vài kỹ thuật để ẩn trình khởi tạo:

//
//  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

Có lẽ loại tình huống này chỉ xảy ra ở thời điểm phát triển, vì vậy điều này có thể hoạt động:

- (id)myMethodWithVar:(id)var {
   NSAssert(NO, @"You most override myMethodWithVar:");
   return nil;
}

Bạn có thể sử dụng một phương pháp được đề xuất bởi @Yar (với một số sửa đổi):

#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()

Tại đây bạn sẽ nhận được một tin nhắn như:

<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'

Hoặc khẳng định:

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

Trong trường hợp này, bạn sẽ nhận được:

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

Ngoài ra, bạn có thể sử dụng các giao thức và các giải pháp khác - nhưng đây là một trong những giao thức đơn giản nhất.

Ca cao không cung cấp bất cứ thứ gì gọi là trừu tượng. Chúng ta có thể tạo một bản tóm tắt lớp chỉ được kiểm tra khi chạy và tại thời điểm biên dịch, điều này không được kiểm tra.

Tôi thường chỉ vô hiệu hóa phương thức init trong một lớp mà tôi muốn trừu tượng hóa:

- (instancetype)__unavailable init; // This is an abstract class.

Điều này sẽ tạo ra một lỗi tại thời gian biên dịch bất cứ khi nào bạn gọi init trên lớp đó. Sau đó tôi sử dụng các phương thức lớp cho mọi thứ khác.

Objective-C không có cách dựng sẵn để khai báo các lớp trừu tượng.

Thay đổi một chút những gì @redfood đề xuất bằng cách áp dụng nhận xét của @ dotToString, bạn thực sự có giải pháp được IGListKit của Instagram áp dụng .

1. Tạo một giao thức cho tất cả các phương thức không có nghĩa được định nghĩa trong lớp cơ sở (trừu tượng), tức là chúng cần các triển khai cụ thể ở trẻ em.
2. Tạo một lớp cơ sở (trừu tượng) không thực hiện giao thức này. Bạn có thể thêm vào lớp này bất kỳ phương thức nào khác có ý nghĩa để có một triển khai chung.
3. Ở mọi nơi trong dự án của bạn, nếu một đứa trẻ từ AbstractClassphải được nhập vào hoặc xuất ra theo một phương thức nào đó, hãy nhập nó làm AbstractClass<Protocol>thay thế.

Bởi vì AbstractClasskhông thực hiện Protocol, cách duy nhất để có một AbstractClass<Protocol>thể hiện là phân lớp. Vì AbstractClassmột mình không thể được sử dụng ở bất cứ đâu trong dự án, nó trở nên trừu tượng.

Tất nhiên, điều này không ngăn các nhà phát triển không được yêu cầu thêm các phương thức mới chỉ đơn giản là tham chiếu AbstractClass, điều này cuối cùng sẽ cho phép một thể hiện của lớp trừu tượng (không còn nữa).

Ví dụ trong thế giới thực: IGListKit có một lớp cơ sở IGListSectionControllerkhông triển khai giao thức IGListSectionType, tuy nhiên mọi phương thức yêu cầu một thể hiện của lớp đó, thực sự yêu cầu loại IGListSectionController<IGListSectionType>. Do đó, không có cách nào để sử dụng một đối tượng loại IGListSectionControllercho bất kỳ thứ gì hữu ích trong khung của chúng.

Trên thực tế, Objective-C không có các lớp trừu tượng, nhưng bạn có thể sử dụng Giao thức để đạt được hiệu quả tương tự. Đây là mẫu:

CustomProtocol.h

#import <Foundation/Foundation.h>

@protocol CustomProtocol <NSObject>
@required
- (void)methodA;
@optional
- (void)methodB;
@end

TestProtocol.h

#import <Foundation/Foundation.h>
#import "CustomProtocol.h"

@interface TestProtocol : NSObject <CustomProtocol>

@end

TestProtocol.m

#import "TestProtocol.h"

@implementation TestProtocol

- (void)methodA
{
  NSLog(@"methodA...");
}

- (void)methodB
{
  NSLog(@"methodB...");
}
@end

Một ví dụ đơn giản về việc tạo một lớp trừu tượng

// Declare a protocol
@protocol AbcProtocol <NSObject>

-(void)fnOne;
-(void)fnTwo;

@optional

-(void)fnThree;

@end

// Abstract class
@interface AbstractAbc : NSObject<AbcProtocol>

@end

@implementation AbstractAbc

-(id)init{
    self = [super init];
    if (self) {
    }
    return self;
}

-(void)fnOne{
// Code
}

-(void)fnTwo{
// Code
}

@end

// Implementation class
@interface ImpAbc : AbstractAbc

@end

@implementation ImpAbc

-(id)init{
    self = [super init];
    if (self) {
    }
    return self;
}

// You may override it    
-(void)fnOne{
// Code
}
// You may override it
-(void)fnTwo{
// Code
}

-(void)fnThree{
// Code
}

@end

Bạn không thể tạo một đại biểu?

Một đại biểu giống như một lớp cơ sở trừu tượng theo nghĩa là bạn nói những chức năng nào cần được xác định, nhưng bạn không thực sự định nghĩa chúng.

Sau đó, bất cứ khi nào bạn thực hiện ủy nhiệm của mình (tức là lớp trừu tượng), bạn sẽ được trình biên dịch cảnh báo về các hàm tùy chọn và bắt buộc mà bạn cần để xác định hành vi cho.

Điều này nghe có vẻ như một lớp cơ sở trừu tượng với tôi.