Làm thế nào để lựa chọn giữa thành viên tư nhân và để ràng buộc?

Question

Khi viết một phương thức riêng không cần truy cập các thành viên khác trong cùng một lớp, bạn chọn giữa thành viên riêng tư như thế nào và để ràng buộc?

• Tôi có xu hướng sử dụng thành viên riêng vì dễ thay đổi trợ năng hơn nếu cần, nhưng có các khía cạnh khác cần lưu ý khi lựa chọn không?
• Có để cho các ràng buộc được biên dịch thành các thành viên riêng tư không (chỉ chọn lựa kiểu này)?

Answer 1

Phần có liên quan của thông số là phần 8.6.2. Nó nói:

Các đại diện biên soạn sử dụng cho các giá trị khai báo trong “chúng ta hãy” bindings trong lớp học là một trong hai:

• Một giá trị đó là địa phương để các nhà xây dựng đối tượng (nếu giá trị là không một hàm cú pháp, không thể thay đổi và không được sử dụng trong bất kỳ hàm hoặc thành viên nào).

• Trường thể hiện trong loại CLI tương ứng (nếu giá trị là không phải là hàm cú pháp, nhưng được sử dụng trong một số hàm hoặc thành viên).

• Thành viên của loại CLI tương ứng (nếu giá trị là hàm cú pháp).

Ngoài ra:

phi chức năng let-bindings không được sử dụng trong một trong hai thành viên của một loại hoặc một hàm ràng buộc được tối ưu hóa đi và trở thành giá trị mà là cục bộ đối kết quả là hàm tạo CLI. Tương tự, hàm các ràng buộc được biểu diễn như các thành viên cá thể.

Tôi thích let ràng buộc với các thành viên riêng vì chúng có nhiều chức năng hơn, tức là họ nhấn mạnh "cái gì" trên "cách". Trình biên dịch sẽ xử lý hình thức biên dịch tối ưu.

Answer 2

let liên kết trong một lớp là riêng tư. Sự khác biệt chính mà tôi nghĩ đến giữa let và số member riêng là let các liên kết không thể bị quá tải và được gọi với name() thay vì this.Name(). Như vậy, tôi nghĩ rằng đó là một sự lựa chọn chủ yếu là phong cách.

Answer 3

let không thể truy cập liên kết thông qua thể hiện của lớp nhưng private method có thể. Ví dụ:

type A() = 
    let someUtil() = "util code" 

    member private this.AnotherUtil() = "anotherUtil" 

    member private this.DoSomething() = 
     let anotherA = A() 
     A.someUtil() // compilation failed 
     A.AnotherUtil() // ok