Tại sao một mô hình miền thiếu máu được coi là xấu trong C # / OOP, nhưng lại rất quan trọng trong F # / FP?

Trong một bài đăng trên blog về F # cho vui và lợi nhuận, nó viết:

Trong một thiết kế chức năng, điều rất quan trọng là tách hành vi khỏi dữ liệu. Các kiểu dữ liệu đơn giản và "ngu ngốc". Và sau đó riêng biệt, bạn có một số hàm hoạt động trên các loại dữ liệu đó.

Điều này trái ngược hoàn toàn với thiết kế hướng đối tượng, trong đó hành vi và dữ liệu được kết hợp. Rốt cuộc, đó chính xác là những gì một lớp học. Trong một thiết kế hướng đối tượng thực sự trong thực tế, bạn không nên có gì ngoài hành vi - dữ liệu là riêng tư và chỉ có thể được truy cập thông qua các phương thức.

Trên thực tế, tại OOD, việc không có đủ hành vi xung quanh một loại dữ liệu được coi là Điều xấu và thậm chí còn có một tên: " mô hình miền thiếu máu ".

Cho rằng trong C #, chúng tôi dường như tiếp tục vay mượn từ F # và cố gắng viết mã kiểu chức năng hơn; Tại sao chúng ta không mượn ý tưởng phân tách dữ liệu / hành vi và thậm chí coi nó là xấu? Có phải chỉ đơn giản là định nghĩa không phù hợp với OOP, hoặc có một lý do cụ thể nào đó là xấu trong C # mà vì một lý do nào đó không áp dụng trong F # (và trên thực tế, bị đảo ngược)?

(Lưu ý: Tôi đặc biệt quan tâm đến sự khác biệt trong C # / F # có thể thay đổi quan điểm về điều gì là tốt / xấu, thay vì các cá nhân có thể không đồng ý với ý kiến ​​trong bài đăng trên blog).

Lý do chính mà FP nhắm đến điều này và C # OOP không phải là vì trong FP, trọng tâm là sự minh bạch tham chiếu; nghĩa là, dữ liệu đi vào một chức năng và dữ liệu đi ra, nhưng dữ liệu gốc không bị thay đổi.

Trong C # OOP có một khái niệm về ủy thác trách nhiệm trong đó bạn ủy quyền quản lý một đối tượng cho nó và do đó bạn muốn nó thay đổi nội bộ của chính nó.

Trong FP, bạn không bao giờ muốn thay đổi các giá trị trong một đối tượng, do đó, các hàm của bạn được nhúng trong đối tượng của bạn không có ý nghĩa.

Hơn nữa trong FP, bạn có tính đa hình loại cao hơn cho phép các chức năng của bạn được khái quát hơn nhiều so với C # OOP cho phép. Theo cách này, bạn có thể viết một hàm hoạt động cho bất kỳ a, và do đó, nó được nhúng trong một khối dữ liệu không có ý nghĩa gì; mà có thể chặt vài phương pháp này để nó chỉ hoạt động với điều đó đặc biệt loại của a. Hành vi như thế là hoàn toàn tốt và phổ biến trong C # OOP vì bạn không có khả năng trừu tượng hóa dù sao đi nữa, nhưng trong FP thì đó là một sự đánh đổi.

Vấn đề lớn nhất tôi gặp phải trong các mô hình miền thiếu máu trong C # OOP là bạn kết thúc với mã trùng lặp vì bạn có DTO x và 4 chức năng khác nhau thực hiện hoạt động f thành DTO x vì 4 người khác nhau không thấy triển khai khác . Khi bạn đặt phương thức trực tiếp lên DTO x, thì 4 người đó đều thấy việc thực hiện f và sử dụng lại nó.

Các mô hình dữ liệu thiếu máu trong tái sử dụng mã cản trở C # OOP, nhưng đây không phải là trường hợp trong FP vì một hàm duy nhất được khái quát qua rất nhiều loại khác nhau mà bạn có thể sử dụng lại mã lớn hơn vì hàm đó có thể sử dụng được trong nhiều tình huống hơn so với hàm bạn sẽ viết cho một DTO duy nhất trong C #.

Như đã chỉ ra trong các nhận xét , suy luận kiểu là một trong những lợi ích mà FP dựa vào để cho phép tính đa hình đáng kể như vậy, và cụ thể bạn có thể theo dõi điều này trở lại hệ thống loại Hindley Milner với suy luận loại Thuật toán W; suy luận kiểu như vậy trong hệ thống loại C # OOP đã bị tránh vì thời gian biên dịch khi suy luận dựa trên ràng buộc được thêm vào rất lâu do tìm kiếm toàn diện cần thiết, chi tiết tại đây: https://stackoverflow.com/questions/3948834/generics-why -cant-the-Trình biên dịch-infer-the-type-argument-in-this-case

Tại sao một mô hình miền thiếu máu được coi là xấu trong C # / OOP, nhưng lại rất quan trọng trong F # / FP?

Câu hỏi của bạn có một vấn đề lớn sẽ giới hạn tiện ích của các câu trả lời bạn nhận được: bạn đang ám chỉ / giả sử rằng F # và FP giống nhau. FP là một họ ngôn ngữ khổng lồ bao gồm viết lại thuật ngữ tượng trưng, ​​động và tĩnh. Ngay cả trong số các ngôn ngữ FP được nhập tĩnh, có nhiều công nghệ khác nhau để thể hiện các mô hình miền như mô-đun bậc cao trong OCaml và SML (không tồn tại trong F #). F # là một trong những ngôn ngữ chức năng này, nhưng nó đặc biệt đáng chú ý vì tinh gọn và đặc biệt, không cung cấp các mô-đun bậc cao hơn hoặc các loại loại cao hơn.

Trên thực tế, tôi không thể bắt đầu cho bạn biết các mô hình miền được thể hiện như thế nào trong FP. Câu trả lời khác ở đây nói rất cụ thể về cách nó được thực hiện trong Haskell và hoàn toàn không áp dụng với Lisp (mẹ của tất cả các ngôn ngữ FP), họ ngôn ngữ ML hoặc bất kỳ ngôn ngữ chức năng nào khác.

Tại sao chúng ta không mượn ý tưởng phân tách dữ liệu / hành vi và thậm chí coi nó là xấu?

Generics có thể được coi là một cách tách dữ liệu và hành vi. Generics đến từ gia đình ML của các ngôn ngữ lập trình chức năng không phải là một phần của OOP. C # có thuốc generic, tất nhiên. Vì vậy, người ta có thể lập luận rằng C # đang dần mượn ý tưởng phân tách dữ liệu và hành vi.

Có phải chỉ đơn giản là định nghĩa không phù hợp với OOP,

Tôi tin rằng OOP dựa trên tiền đề khác nhau cơ bản và do đó, không cung cấp cho bạn các công cụ bạn cần để phân tách dữ liệu và hành vi. Đối với tất cả các mục đích thực tế, bạn cần các kiểu dữ liệu tổng và sản phẩm và gửi qua chúng. Trong ML, điều này có nghĩa là các loại kết hợp và bản ghi và khớp mẫu.

Kiểm tra ví dụ tôi đã đưa ra ở đây .

hoặc có một lý do cụ thể rằng nó xấu trong C # mà vì một lý do nào đó không áp dụng trong F # (và trên thực tế, bị đảo ngược)?

Hãy cẩn thận về việc nhảy từ OOP sang C #. C # không ở đâu gần như thuần túy về OOP như các ngôn ngữ khác. .NET Framework hiện có đầy đủ các khái quát, phương thức tĩnh và thậm chí cả lambdas.

(Lưu ý: Tôi đặc biệt quan tâm đến sự khác biệt trong C # / F # có thể thay đổi quan điểm về điều gì là tốt / xấu, thay vì các cá nhân có thể không đồng ý với ý kiến ​​trong bài đăng trên blog).

Việc thiếu các loại kết hợp và khớp mẫu trong C # làm cho nó gần như không thể thực hiện được. Khi tất cả những gì bạn có là một cái búa, mọi thứ trông giống như một cái đinh ...

Tôi nghĩ rằng trong một ứng dụng kinh doanh, bạn thường không muốn ẩn dữ liệu vì khớp mẫu trên các giá trị bất biến là tuyệt vời để đảm bảo rằng bạn đang bao quát tất cả các trường hợp có thể. Nhưng nếu bạn đang triển khai các thuật toán hoặc cấu trúc dữ liệu phức tạp, tốt hơn bạn nên ẩn chi tiết triển khai biến ADT (kiểu dữ liệu đại số) thành ADT (kiểu dữ liệu trừu tượng).