Trong Objective-C tại sao tôi phải kiểm tra xem self = [super init] có phải không không?

Tôi có một câu hỏi chung về việc viết các phương thức init trong Objective-C.

Tôi thấy nó ở khắp mọi nơi (mã của Apple, sách, mã nguồn mở, v.v.) rằng một phương thức init sẽ kiểm tra xem self = [super init] có phải không trước khi tiếp tục khởi tạo.

Mẫu Apple mặc định cho phương thức init là:

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

    if (self != nil)
    {
        // your code here
    }

    return self;
}

Tại sao?

Ý tôi là khi nào init sẽ trở về nil? Nếu tôi gọi init trên NSObject và nhận được con số không, thì một cái gì đó phải thực sự sai lầm, phải không? Và trong trường hợp đó, bạn thậm chí có thể không viết một chương trình ...

Có thực sự phổ biến rằng phương thức init của lớp có thể trả về không? Nếu vậy, trong trường hợp nào, và tại sao?

Ví dụ:

[[NSData alloc] initWithContentsOfFile:@"this/path/doesn't/exist/"];
[[NSImage alloc] initWithContentsOfFile:@"unsupportedFormat.sjt"];
[NSImage imageNamed:@"AnImageThatIsntInTheImageCache"];

... và như thế. (Lưu ý: NSData có thể ném ngoại lệ nếu tệp không tồn tại). Có khá nhiều lĩnh vực mà việc trả lại con số không là hành vi dự kiến ​​khi xảy ra sự cố và vì đây là cách thực hành tiêu chuẩn để kiểm tra số lượng khá nhiều, vì sự nhất quán.

Thành ngữ đặc biệt này là tiêu chuẩn vì nó hoạt động trong mọi trường hợp.

Trong khi không phổ biến, sẽ có trường hợp ...

[super init];

... Trả về một thể hiện khác, do đó yêu cầu tự gán.

Và sẽ có trường hợp nó sẽ trả về nil, do đó yêu cầu kiểm tra nil để mã của bạn không cố khởi tạo một khe biến thể hiện không còn tồn tại.

Điểm mấu chốt là nó là mẫu chính xác được sử dụng và nếu bạn không sử dụng nó, bạn đang làm sai.

Tôi nghĩ, trong hầu hết các lớp, nếu giá trị trả về từ [super init] là không và bạn kiểm tra nó, theo khuyến nghị của các thông lệ tiêu chuẩn, và sau đó trả về sớm nếu không, về cơ bản, ứng dụng của bạn vẫn không hoạt động chính xác. Nếu bạn nghĩ về nó, mặc dù rằng nếu (tự! = Nil) kiểm tra là có, cho các hoạt động thích hợp của lớp học của bạn, 99,99% thời gian bạn thực sự làm cần tự là phi nil. Bây giờ, giả sử, vì bất kỳ lý do gì, [super init] đã trả về con số không, về cơ bản, séc của bạn đối với con số không về cơ bản là chuyển giao cho người gọi của lớp bạn, nơi nó có thể sẽ thất bại, vì nó sẽ tự nhiên cho rằng cuộc gọi là thành công

Về cơ bản, những gì tôi nhận được là 99,99% thời gian, nếu (tự! = Nil) không mua cho bạn bất cứ điều gì về độ mạnh mẽ hơn, vì bạn chỉ chuyển giao cho kẻ xâm lược. Để thực sự có thể xử lý việc này một cách mạnh mẽ, bạn thực sự sẽ cần phải kiểm tra trong toàn bộ hệ thống phân cấp cuộc gọi của bạn. Và thậm chí sau đó, điều duy nhất nó sẽ mua cho bạn là ứng dụng của bạn sẽ thất bại một cách sạch sẽ / mạnh mẽ hơn một chút. Nhưng nó vẫn sẽ thất bại.

Nếu một lớp thư viện tự ý quyết định trả lại con số không phải là kết quả của [super init], thì dù sao đi nữa, đó là một dấu hiệu cho thấy người viết của lớp thư viện đã phạm sai lầm khi thực hiện.

Tôi nghĩ rằng đây là một gợi ý mã hóa cũ, khi các ứng dụng chạy trong bộ nhớ hạn chế hơn nhiều.

Nhưng đối với mã cấp C, tôi vẫn thường kiểm tra giá trị trả về của malloc () so với con trỏ NULL. Trong khi đó, đối với Objective-C, cho đến khi tôi tìm thấy bằng chứng ngược lại, tôi nghĩ rằng tôi thường bỏ qua việc kiểm tra if (self! = Nil). Tại sao có sự khác biệt?

Bởi vì, ở cấp độ C và malloc, trong một số trường hợp bạn thực sự có thể phục hồi một phần. Trong khi tôi nghĩ trong Objective-C, trong 99,99% trường hợp, nếu [super init] không trả về con số nào, thì về cơ bản bạn vẫn đang xử lý nó, ngay cả khi bạn cố gắng xử lý nó. Bạn cũng có thể chỉ để ứng dụng bị sập và giải quyết hậu quả.

Đây là loại tóm tắt của các ý kiến ​​trên.

Hãy nói rằng siêu lớp trở lại nil. Điều gì sẽ xảy ra?

Nếu bạn không tuân theo các quy ước

Mã của bạn sẽ bị sập ở giữa initphương thức của bạn . (trừ khi initkhông có gì quan trọng)

Nếu bạn tuân theo các quy ước, không biết rằng siêu lớp có thể trở về con số không (hầu hết mọi người kết thúc ở đây)

Mã của bạn là probalby sẽ bị sập vào một lúc nào đó, bởi vì ví dụ của bạn là nil, nơi bạn mong đợi một cái gì đó khác biệt. Hoặc chương trình của bạn sẽ hoạt động bất ngờ mà không gặp sự cố. Trời ơi! Bạn có muốn cái này không? Tôi không biết...

Nếu bạn tuân theo các quy ước, sẵn sàng cho phép lớp con của bạn trở về con số không

Tài liệu mã của bạn (!) Phải ghi rõ: "trả về ... hoặc không" và phần còn lại của mã của bạn cần được chuẩn bị để xử lý việc này. Bây giờ nó có ý nghĩa.

Thông thường, nếu lớp của bạn xuất phát trực tiếp từ NSObject, bạn sẽ không cần. Tuy nhiên, đó là một thói quen tốt để tham gia, vì nếu lớp của bạn xuất phát từ các lớp khác, trình khởi tạo của chúng có thể quay lại nilvà nếu vậy, trình khởi tạo của bạn có thể nắm bắt điều đó và hành xử chính xác.

Và vâng, đối với hồ sơ, tôi tuân theo thực tiễn tốt nhất và viết nó trên tất cả các lớp học của tôi, ngay cả những người xuất phát trực tiếp từ đó NSObject.

Bạn nói đúng, bạn thường có thể viết [super init], nhưng điều đó sẽ không hiệu quả đối với một lớp con của bất cứ thứ gì. Mọi người chỉ thích ghi nhớ một dòng mã tiêu chuẩn và sử dụng nó mọi lúc, ngay cả khi đôi khi chỉ cần thiết, và do đó chúng tôi có được tiêu chuẩn if (self = [super init]), trong đó có cả khả năng không được trả lại và khả năng của một đối tượng khác hơn selflà được trả lại vào tài khoản.

Một lỗi phổ biến là viết

self = [[super alloc] init];

trong đó trả về một thể hiện của siêu lớp, đó không phải là thứ bạn muốn trong hàm tạo / init của lớp con. Bạn nhận lại một đối tượng không đáp ứng với các phương thức của lớp con, điều này có thể gây nhầm lẫn và tạo ra các lỗi khó hiểu về việc không sửa chữa lại các phương thức hoặc mã định danh không tìm thấy, v.v.

self = [super init]; 

là cần thiết nếu lớp siêu có các thành viên (các biến hoặc các đối tượng khác) để khởi tạo đầu tiên trước khi thiết lập các thành viên của lớp con. Nếu thời gian chạy objc khởi cho họ tất cả để 0 hoặc bằng không . ( không giống như ANSI C, thường phân bổ các khối bộ nhớ mà không xóa chúng )

Và đúng vậy, khởi tạo lớp cơ sở có thể thất bại do lỗi hết bộ nhớ, thiếu thành phần, lỗi thu nhận tài nguyên, v.v. vì vậy việc kiểm tra nil là khôn ngoan và mất ít hơn vài mili giây.

Điều này là để kiểm tra xem intialazation có hoạt động không, câu lệnh if trả về true nếu phương thức init không trả về nil, vì vậy đây là cách để kiểm tra việc tạo đối tượng hoạt động chính xác. Vài lý do tôi có thể nghĩ về init đó có thể thất bại có lẽ là một phương thức init quá mức mà siêu hạng không biết hoặc một cái gì đó thuộc loại này, tôi sẽ không nghĩ rằng đó là phổ biến mặc dù. Nhưng nếu nó xảy ra, tốt hơn là không có gì xảy ra khi tôi gặp sự cố nên nó luôn được kiểm tra ...

Trong OS X, nó không có khả năng -[NSObject init]bị lỗi do lý do bộ nhớ. Điều tương tự không thể nói cho iOS.

Ngoài ra, đó là cách thực hành tốt để viết khi phân lớp một lớp có thể trở lại nilvì bất kỳ lý do gì.