Tại sao các đại biểu Objective-C thường được gán thuộc tính thay vì giữ lại?

Tôi đang lướt qua blog tuyệt vời được duy trì bởi Scott Stevenson và tôi đang cố gắng hiểu một khái niệm cơ bản của Objective-C về việc giao cho các đại biểu thuộc tính 'gán' so với 'giữ lại'. Lưu ý, cả hai đều giống nhau trong một môi trường thu gom rác. Tôi chủ yếu quan tâm đến một môi trường không dựa trên GC (ví dụ: iPhone).

Trực tiếp từ blog của Scott:

"Từ khóa gán sẽ tạo ra một setter gán trực tiếp giá trị cho biến thể hiện, thay vì sao chép hoặc giữ lại nó. Điều này tốt nhất cho các kiểu nguyên thủy như NSInteger và CGFloat hoặc các đối tượng bạn không sở hữu trực tiếp, chẳng hạn như đại biểu."

Điều đó có nghĩa là bạn không trực tiếp sở hữu đối tượng đại biểu? Tôi thường giữ các đại biểu của mình, bởi vì nếu tôi không muốn họ đi xuống vực thẳm, thì giữ lại sẽ chăm sóc điều đó cho tôi. Tôi thường trừu tượng UITableViewControll khỏi dataSource tương ứng và ủy nhiệm của nó. Tôi cũng giữ lại đối tượng cụ thể đó. Tôi muốn đảm bảo rằng nó không bao giờ biến mất để UITableView của tôi luôn có đại biểu của nó.

Ai đó có thể giải thích thêm về việc tại sao / tại sao tôi sai, vì vậy tôi có thể hiểu mô hình chung này trong lập trình Objective-C 2.0 về việc sử dụng thuộc tính gán cho đại biểu thay vì giữ lại không?

Cảm ơn!

Lý do mà bạn tránh giữ lại các đại biểu là bạn cần tránh một chu kỳ giữ lại:

A tạo B A tự đặt mình là đại biểu của B, A được phát hành bởi chủ sở hữu của nó

Nếu B giữ lại A, A sẽ không được giải phóng, vì B sở hữu A, do đó, dealloc của A sẽ không bao giờ được gọi, khiến cả A và B bị rò rỉ.

Bạn không nên lo lắng về việc A sẽ biến mất vì nó sở hữu B và do đó loại bỏ nó trong dealloc.

Bởi vì đối tượng gửi tin nhắn đại biểu không sở hữu đại biểu.

Nhiều khi, đó là cách khác, khi bộ điều khiển tự đặt mình là đại biểu của chế độ xem hoặc cửa sổ: bộ điều khiển sở hữu chế độ xem / cửa sổ, vì vậy nếu chế độ xem / cửa sổ sở hữu đại biểu của nó, cả hai đối tượng sẽ sở hữu lẫn nhau. Tất nhiên, đây là một chu trình giữ lại, tương tự như rò rỉ với hậu quả tương tự (các đối tượng nên chết vẫn còn sống).

Những lần khác, các đối tượng là đồng nghiệp: không ai sở hữu người kia, có lẽ vì cả hai đều thuộc sở hữu của cùng một đối tượng thứ ba.

Dù bằng cách nào, đối tượng với đại biểu không nên giữ lại đại biểu của mình.

(Nhân tiện, có ít nhất một ngoại lệ. Tôi không nhớ nó là gì và tôi không nghĩ có lý do chính đáng cho việc đó.)

Phụ lục (đã thêm 2012-05-19): Trong ARC, bạn nên sử dụng weakthay vì assign. Tham chiếu yếu được đặt thành niltự động khi đối tượng chết, loại trừ khả năng đối tượng ủy nhiệm sẽ kết thúc việc gửi tin nhắn đến đại biểu đã chết.

Nếu bạn tránh xa ARC vì một số lý do, ít nhất hãy thay đổi assigncác thuộc tính trỏ đến các đối tượng unsafe_unretained, điều này cho thấy rõ đây là một tham chiếu không được lưu trữ nhưng không bằng không đối với một đối tượng.

assign vẫn phù hợp với các giá trị không phải đối tượng trong cả ARC và MRC.

Lưu ý rằng khi bạn có một đại biểu được chỉ định, điều rất quan trọng là luôn luôn đặt giá trị ủy nhiệm đó thành nil bất cứ khi nào đối tượng sẽ được xử lý - vì vậy một đối tượng phải luôn cẩn thận để loại bỏ các tham chiếu ủy nhiệm trong dealloc nếu nó không làm như vậy ở nơi khác

Một trong những lý do đằng sau đó là để tránh chu kỳ giữ lại. Chỉ để tránh kịch bản A và B cả hai đối tượng tham chiếu lẫn nhau và không ai trong số chúng được giải phóng khỏi bộ nhớ.

Việc gán tạm thời là tốt nhất cho các loại nguyên thủy như NSInteger và CGFloat hoặc các đối tượng bạn không trực tiếp sở hữu, chẳng hạn như đại biểu.