Kiểu mã hóa F # - phương thức tĩnh so với ví dụ

Question

Tôi đã nhận thấy rằng các phương thức tĩnh dường như phổ biến hơn trong F # so với C#. Trong C#, bạn luôn luôn muốn thêm một yếu tố để một bộ sưu tập bằng cách gọi một phương pháp dụ:

mySet.Add(elem); 

Nhưng trong F # thường có một phương pháp tĩnh tương đương:

mySet.Add(elem) 
// OR 
Set.Add elem mySet 

Và tôi đã nhìn thấy dạng sau khá thường xuyên trong các mẫu. Cả hai xuất hiện với tôi hoàn toàn giống hệt nhau về mặt ngữ nghĩa và chức năng, nhưng đến từ một nền C#, sử dụng phương pháp thể hiện cảm thấy tự nhiên hơn. Đó là phong cách tốt hơn trong F # và tại sao?

Answer 1

Ngoài những lý do được đề cập trong câu trả lời đó có liên quan đến suy luận kiểu, trong kiểu hàm là tự nhiên hơn khi gửi một hàm làm tham số. Nếu nó là một phương pháp dụ bạn sẽ phải viết một cái gì đó như thế này:

myHigherOrderFunction (fun (x:MyType) -> x.myFunctionAsMethod) 

Nhưng nếu nó được định nghĩa là một phương pháp tĩnh bạn có thể viết:

myHigherOrderFunction MyType.myFunctionAsMethod 

đó là thanh lịch hơn, dễ viết (để đọc là tốt) và gần như là cú pháp giống như khi gửi một hàm ràng buộc cho phép thường xuyên.

Một phương pháp thể hiện yêu cầu một thể hiện kiểu để truy cập hàm (phương thức), trong OOP, đây không phải là vấn đề vì bạn cho rằng gửi thư đến đối tượng nhưng trong FP, các hàm đơn thuần (không có cá thể) là công dân hạng nhất.

Để truy cập phương pháp tĩnh, bạn cần chỉ định Lớp, bạn có thể xem Lớp như một loại vùng chứa (như mô-đun hoặc không gian tên) với các hàm.

Answer 2

Trong f # là ngôn ngữ hàm có nhiều biến riêng biệt hơn là không thay đổi và các hàm hoạt động. Chức năng này tương tự như các phương thức tĩnh trong C#, nhưng có một lợi thế của các hàm cho các phương thức C#. Nó là một phần ứng dụng. Bạn có thể truyền cho một số tham số (không phải tất cả) và chức năng này với một phần tham số sẽ là hàm mới cần các tham số khác.

Answer 3

Hầu hết các loại F # tiêu chuẩn đều không thay đổi. Khi làm việc với các đối tượng bất biến, phương pháp tĩnh tốt hơn miêu tả những gì đang xảy ra, ví dụ:

mySet.Add(elem); 

Hình như mySet bị đột biến bao gồm elem, khi một chiếc F # thiết lập sẽ trở lại một mới mySet. May mắn thay F # không biên dịch được để chắc chắn rằng bạn không phạm phải sai lầm này, nó vẫn dẫn đến việc gây nhầm lẫn mã. Ngược lại:

mySet |> Set.Add elm 

Khác biệt ở dạng và có vẻ như nó sẽ trả lại một cái gì đó mới, không quá xa bản gốc.

Answer 4

Trong khi các phương pháp tĩnh trong F # rất phổ biến, tôi thấy rằng các phương thức thể hiện tạo ra nhiều ý nghĩa cho phát triển thành phần.

Lý do? F # module hệ thống thiếu functors. Trong các hương vị khác của ML như SML hoặc OCaml, bạn phát triển các thành phần như các mô-đun đơn giản. Nếu sau đó bạn quyết định tham số hóa mô-đun, bạn có thể quảng bá mô-đun đó đến một hàm mà không cần viết lại quá nhiều mã nguồn của bạn. Trong F # bạn không thể.

Để tạo một tham số "mô-đun" trong F #, bạn phải sử dụng một lớp và chuyển phương thức của bạn thành các phương thức thể hiện, truyền tham số trong suốt quá trình tạo ví dụ. Thật không may, đi từ một mô-đun đến một lớp học liên quan đến khá nhiều thay đổi mã nguồn cơ học nhưng gây phiền nhiễu. Do đó, một lập trình viên thành phần lõi cứng có thể chọn làm việc với các lớp và các phương thức cá thể theo mặc định, giống như trong C#. Điều này gợi nhớ đến phong cách "functor-only" đôi khi được sử dụng trong SML.