Lớp cơ sở gốc Swift hoặc NSObject

Tôi đã thử nghiệm một số isa swizzing với Swift và thấy rằng nó chỉ hoạt động khi NSObject là một siêu cấp (trực tiếp hoặc cao hơn) hoặc bằng cách sử dụng trang trí '@objc'. Nếu không, nó sẽ tuân theo kiểu điều phối tĩnh và vtable-như C ++.

Có bình thường để xác định một lớp Swift không có lớp cơ sở Cocoa / NSObject không? Nếu tôi lo ngại, điều này có nghĩa là đã đề cập nhiều đến tính năng động của Objective-C, chẳng hạn như phương pháp đánh chặn và xem xét nội tâm trong thời gian chạy.

Hành vi thời gian chạy động là trọng tâm của các tính năng như quan sát thuộc tính, Dữ liệu cốt lõi, Lập trình hướng theo khía cạnh , Nhắn tin thứ tự cao hơn , khung phân tích & ghi nhật ký, v.v.

Sử dụng kiểu gọi phương thức của Objective-C thêm khoảng 20 toán hạng mã máy vào một lệnh gọi phương thức, vì vậy trong một số tình huống nhất định ( nhiều lệnh gọi chặt chẽ đến các phương thức có phần thân nhỏ ) C ++ kiểu tĩnh và vtable có thể hoạt động tốt hơn.

Nhưng với quy tắc chung 95-5 ( 95% hiệu suất tăng đến từ việc điều chỉnh 5% mã ), không hợp lý khi bắt đầu với các tính năng động mạnh mẽ và tăng cường ở những nơi cần thiết?

Các lớp Swift là lớp con của NSObject:

• chính là các lớp Objective-C
• sử dụng objc_msgSend()cho các cuộc gọi đến (hầu hết) các phương thức của họ
• cung cấp siêu dữ liệu thời gian chạy Objective-C cho (hầu hết) việc triển khai phương pháp của họ

Các lớp Swift không phải là các lớp con của NSObject:

• là các lớp Objective-C, nhưng chỉ triển khai một số phương pháp để tương thích với NSObject
• không sử dụng objc_msgSend()cho các cuộc gọi đến phương thức của họ (theo mặc định)
• không cung cấp siêu dữ liệu thời gian chạy Objective-C để triển khai phương thức của chúng (theo mặc định)

Phân lớp NSObject trong Swift giúp bạn linh hoạt trong thời gian chạy Objective-C mà còn cả hiệu suất Objective-C. Tránh NSObject có thể cải thiện hiệu suất nếu bạn không cần tính linh hoạt của Objective-C.

Biên tập:

Với Xcode 6 beta 6, thuộc tính động sẽ xuất hiện. Điều này cho phép chúng tôi hướng dẫn Swift rằng một phương thức nên sử dụng điều phối động và do đó sẽ hỗ trợ việc đánh chặn.

public dynamic func foobar() -> AnyObject {
}

Tôi cũng nhận thấy rằng nếu dựa trên một lớp Swift trên NSObject, tôi đã thấy một số hành vi thời gian chạy không mong muốn có thể ẩn các lỗi mã hóa. Đây là một ví dụ.

Trong ví dụ này, nơi chúng tôi không dựa trên NSObject, trình biên dịch phát hiện chính xác lỗi trong testIncorrect_CompilerShouldSpot, báo cáo "... 'MyClass' không thể chuyển đổi thành 'MirrorDisposition'"

class MyClass {
  let mString = "Test"

  func getAsString() -> String {
    return mString
  }

  func testIncorrect_CompilerShouldSpot() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject == myString) {
        // Do something
      }
  }

  func testCorrect_CorrectlyWritten() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject.getAsString() == myString) {
        // Do something
      }
  }
}

Trong ví dụ này, khi chúng tôi dựa trên NSObject , trình biên dịch không phát hiện ra lỗi trong testIncorrect_CompilerShouldSpot:

class myClass : NSObject {
  let mString = "Test"

  func getAsString() -> String {
    return mString
  }

  func testIncorrect_CompilerShouldSpot() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject == myString) {
        // Do something
      }
  }

  func testCorrect_CorrectlyWritten() {
    var myString = "Compare to me"
      var myObject = MyClass()
      if (myObject.getAsString() == myString) {
        // Do something
      }
  }
}

Tôi đoán đạo đức là, chỉ dựa trên NSObject nơi bạn thực sự phải làm!

Theo tham chiếu ngôn ngữ, không có yêu cầu đối với các lớp phải phân lớp bất kỳ lớp gốc tiêu chuẩn nào, vì vậy bạn có thể bao gồm hoặc bỏ qua một lớp cha nếu cần.

Lưu ý rằng việc bỏ qua một lớp cha khỏi khai báo lớp, sẽ không gán một lớp cha cơ sở ngầm định của bất kỳ loại nào. Nó định nghĩa một lớp cơ sở, lớp này sẽ trở thành gốc cho một hệ thống phân cấp lớp độc lập.

Từ tham chiếu ngôn ngữ:

Các lớp Swift không kế thừa từ một lớp cơ sở phổ quát. Các lớp bạn xác định mà không chỉ định lớp cha sẽ tự động trở thành lớp cơ sở để bạn xây dựng.

Cố gắng tham chiếu supertừ một lớp không có siêu lớp (tức là lớp cơ sở) sẽ dẫn đến lỗi thời gian biên dịch

'super' members cannot be referenced in a root class

Tôi tin rằng phần lớn dữ liệu Swift sẽ không như vậy objc. Chỉ những phần cần giao tiếp với cơ sở hạ tầng Mục tiêu C mới được đánh dấu rõ ràng như vậy.

Tôi không biết nội quan thời gian chạy sẽ được thêm vào ngôn ngữ ở mức độ nào. Việc đánh chặn phương thức có thể chỉ trở nên khả thi nếu phương thức đó cho phép một cách rõ ràng. Đây là suy đoán của tôi, nhưng chỉ những nhà thiết kế ngôn ngữ của Apple mới thực sự biết họ đang thực sự hướng tới đâu.

Phần sau được sao chép từ Swift-eBook của Apple và đưa ra câu trả lời thích hợp cho câu hỏi của bạn:

Xác định Lớp cơ sở

Bất kỳ lớp nào không kế thừa từ lớp khác được gọi là lớp cơ sở.

Các lớp Swift không kế thừa từ một lớp cơ sở phổ quát. Các lớp bạn xác định mà không chỉ định lớp cha sẽ tự động trở thành lớp cơ sở để bạn xây dựng.

Tài liệu tham khảo

Thật là bình thường. Nhìn vào mục tiêu thiết kế của Swift: Mục tiêu là làm biến mất các lớp lập trình khổng lồ. Thay đổi phương thức có lẽ không phải là một trong những điều bạn muốn làm với Swift.