Yêu cầu của tôi là thế này. Khi nào một người sử dụng #import và khi nào một người sử dụng @ class?
Câu trả lời đơn giản: Bạn #importhoặc #includekhi có một sự phụ thuộc vật lý. Nếu không, bạn sử dụng tờ khai chuyển tiếp ( @class MONClass, struct MONStruct, @protocol MONProtocol).
Dưới đây là một số ví dụ phổ biến về sự phụ thuộc vật lý:
- Bất kỳ giá trị C hoặc C ++ (một con trỏ hoặc tham chiếu không phải là một phụ thuộc vật lý). Nếu bạn có một
CGPointivar hoặc thuộc tính, trình biên dịch sẽ cần phải xem khai báo CGPoint.
- Siêu lớp của bạn.
- Một phương pháp bạn sử dụng.
Đôi khi, nếu tôi sử dụng khai báo @ class, tôi thấy một cảnh báo trình biên dịch phổ biến như sau: "warning: receive 'FooContoder' là lớp chuyển tiếp và @interface tương ứng có thể không tồn tại."
Các nhà soạn nhạc thực sự rất khoan dung trong vấn đề này. Nó sẽ bỏ các gợi ý (chẳng hạn như ở trên), nhưng bạn có thể bỏ rác ngăn xếp của mình một cách dễ dàng nếu bạn bỏ qua chúng và không #importđúng cách. Mặc dù nó nên (IMO), trình biên dịch không thực thi điều này. Trong ARC, trình biên dịch chặt chẽ hơn vì nó chịu trách nhiệm đếm tham chiếu. Điều gì xảy ra là trình biên dịch rơi vào mặc định khi nó gặp một phương thức không xác định mà bạn gọi. Mỗi giá trị trả về và tham số được giả định là id. Do đó, bạn nên xóa mọi cảnh báo khỏi cơ sở mã của mình vì điều này nên được coi là sự phụ thuộc vật lý. Điều này tương tự với việc gọi một hàm C không được khai báo. Với C, các tham số được giả định là int.
Lý do bạn muốn ưu tiên khai báo là bạn có thể giảm thời gian xây dựng của mình theo các yếu tố vì có sự phụ thuộc tối thiểu. Với các khai báo chuyển tiếp, trình biên dịch thấy có một tên, và có thể phân tích và biên dịch chính xác chương trình mà không cần xem khai báo lớp hoặc tất cả các phụ thuộc của nó khi không có phụ thuộc vật lý. Xây dựng sạch mất ít thời gian hơn. Xây dựng gia tăng mất ít thời gian hơn. Chắc chắn, cuối cùng bạn sẽ dành thêm một chút thời gian để đảm bảo rằng tất cả các tiêu đề bạn cần đều hiển thị cho mọi bản dịch, nhưng điều này sẽ giúp giảm thời gian xây dựng một cách nhanh chóng (giả sử dự án của bạn không nhỏ).
Nếu bạn sử dụng #importhoặc #includethay vào đó, bạn đang ném nhiều công việc vào trình biên dịch hơn mức cần thiết. Bạn cũng đang giới thiệu các phụ thuộc tiêu đề phức tạp. Bạn có thể ví nó như một thuật toán brute-force. Khi bạn #import, bạn đang kéo hàng tấn thông tin không cần thiết, đòi hỏi nhiều bộ nhớ, I / O đĩa và CPU để phân tích và biên dịch các nguồn.
ObjC khá gần với lý tưởng cho ngôn ngữ dựa trên C liên quan đến sự phụ thuộc vì NSObjectcác loại không bao giờ là giá trị - NSObjectcác loại luôn được tham chiếu con trỏ đếm. Vì vậy, bạn có thể thoát khỏi thời gian biên dịch cực kỳ nhanh nếu bạn cấu trúc các phần phụ thuộc của chương trình một cách phù hợp và chuyển tiếp nếu có thể vì có rất ít sự phụ thuộc vật lý cần thiết. Bạn cũng có thể khai báo các thuộc tính trong phần mở rộng lớp để giảm thiểu sự phụ thuộc hơn nữa. Đó là một phần thưởng lớn cho các hệ thống lớn - bạn sẽ biết sự khác biệt mà nó tạo ra nếu bạn đã từng phát triển một cơ sở mã C ++ lớn.
Do đó, khuyến nghị của tôi là sử dụng chuyển tiếp khi có thể, và sau đó đến #importnơi có sự phụ thuộc vật lý. Nếu bạn thấy cảnh báo hoặc cảnh báo khác ngụ ý sự phụ thuộc vật lý - hãy khắc phục tất cả. Cách khắc phục là #importtrong tập tin thực hiện của bạn.
Khi bạn xây dựng thư viện, bạn có thể sẽ phân loại một số giao diện thành một nhóm, trong trường hợp đó bạn sẽ #importthư viện đó nơi giới thiệu sự phụ thuộc vật lý (ví dụ #import <AppKit/AppKit.h>). Điều này có thể giới thiệu sự phụ thuộc, nhưng những người bảo trì thư viện thường có thể xử lý các phụ thuộc vật lý cho bạn khi cần - nếu họ giới thiệu một tính năng, họ có thể giảm thiểu tác động của nó đối với các bản dựng của bạn.