Là hợp đồng ngữ nghĩa của một giao diện (OOP) có nhiều thông tin hơn chữ ký hàm (FP)?

Một số người nói rằng nếu bạn đưa các nguyên tắc RẮN đến cực đoan của họ, bạn sẽ kết thúc chương trình chức năng . Tôi đồng ý với bài viết này nhưng tôi nghĩ rằng một số ngữ nghĩa bị mất trong quá trình chuyển đổi từ giao diện / đối tượng sang chức năng / đóng cửa và tôi muốn biết làm thế nào Lập trình chức năng có thể giảm thiểu tổn thất.

Từ bài viết:

Hơn nữa, nếu bạn áp dụng nghiêm ngặt Nguyên tắc phân chia giao diện (ISP), bạn sẽ hiểu rằng bạn nên ưu tiên Giao diện vai trò trên Giao diện tiêu đề.

Nếu bạn tiếp tục hướng thiết kế của mình tới các giao diện nhỏ hơn và nhỏ hơn, cuối cùng bạn sẽ đến Giao diện vai trò cuối cùng: một giao diện với một phương thức duy nhất. Điều này xảy ra với tôi rất nhiều. Đây là một ví dụ:

public interface IMessageQuery
{
    string Read(int id);
}

Nếu tôi phụ thuộc vào một IMessageQuery, một phần của hợp đồng ngầm là việc gọi điện Read(id)sẽ tìm kiếm và trả lại một tin nhắn với ID đã cho.

So sánh điều này với việc phụ thuộc vào chữ ký chức năng tương đương của nó , int -> string. Không có bất kỳ tín hiệu bổ sung, chức năng này có thể là một đơn giản ToString(). Nếu bạn thực hiện IMessageQuery.Read(int id)với một ToString()tôi có thể buộc tội bạn đã cố tình lật đổ!

Vì vậy, các lập trình viên chức năng có thể làm gì để bảo tồn ngữ nghĩa của một giao diện có tên? Có phải thông thường, ví dụ, tạo một loại bản ghi với một thành viên không?

type MessageQuery = {
    Read: int -> string
}

Như Telastyn nói, so sánh các định nghĩa tĩnh của các hàm:

public string Read(int id) { /*...*/ }

đến

let read (id:int) = //...

Bạn chưa thực sự mất bất cứ thứ gì từ OOP đến FP.

Tuy nhiên, đây chỉ là một phần của câu chuyện, bởi vì các chức năng và giao diện không chỉ được đề cập trong các định nghĩa tĩnh của chúng. Họ cũng đi qua xung quanh . Vì vậy, hãy nói rằng chúng tôi MessageQueryđã được đọc bởi một đoạn mã khác, a MessageProcessor. Sau đó chúng tôi có:

public void ProcessMessage(int messageId, IMessageQuery messageReader) { /*...*/ }

Bây giờ chúng ta không thể trực tiếp nhìn thấy tên phương thức IMessageQuery.Readhoặc tham số của nó int id, nhưng chúng ta có thể đến đó rất dễ dàng thông qua IDE của chúng ta. Tổng quát hơn, thực tế là chúng ta chuyển một IMessageQuerygiao diện chứ không phải bất kỳ giao diện nào có phương thức một hàm từ int sang chuỗi có nghĩa là chúng ta giữ idsiêu dữ liệu tên tham số đó được liên kết với hàm này.

Mặt khác, đối với phiên bản chức năng của chúng tôi, chúng tôi có:

let read (id:int) (messageReader : int -> string) = // ...

Vì vậy, những gì chúng ta đã giữ và mất? Chà, chúng ta vẫn có tên tham số messageReader, có thể làm cho tên loại (tương đương IMessageQuery) không cần thiết. Nhưng bây giờ chúng tôi đã mất tên tham số idtrong chức năng của chúng tôi.

Có hai cách chính xung quanh điều này:

• Đầu tiên, từ việc đọc chữ ký đó, bạn đã có thể đoán khá chính xác những gì sẽ xảy ra. Bằng cách giữ các chức năng ngắn, đơn giản và gắn kết và sử dụng cách đặt tên tốt, bạn sẽ dễ dàng hơn trong việc tìm kiếm hoặc tìm thông tin này. Khi chúng ta đã đọc được chức năng thực tế, nó sẽ còn đơn giản hơn nữa.

• Thứ hai, nó được coi là thiết kế thành ngữ trong nhiều ngôn ngữ chức năng để tạo ra các loại nhỏ để bọc nguyên thủy. Trong trường hợp này, điều ngược lại đang xảy ra - thay vì thay thế tên loại bằng tên tham số ( IMessageQueryđến messageReader), chúng ta có thể thay thế tên tham số bằng tên loại. Ví dụ, intcó thể được bọc trong một loại được gọi là Id:

  type Id = Id of int
  

  Bây giờ readchữ ký của chúng tôi trở thành:

  let read (id:int) (messageReader : Id -> string) = // ...
  

  Đó chỉ là thông tin như những gì chúng ta đã có trước đây.

  Là một lưu ý phụ, điều này cũng cung cấp cho chúng tôi một số bảo vệ trình biên dịch mà chúng tôi có trong OOP. Trong khi phiên bản OOP đảm bảo chúng tôi thực hiện một cách cụ thể IMessageQuerychứ không phải bất kỳ int -> stringchức năng cũ nào , thì ở đây chúng tôi có một sự bảo vệ tương tự (nhưng khác biệt) mà chúng tôi đang thực hiện Id -> stringthay vì bất kỳ chức năng cũ nào int -> string.

Tôi miễn cưỡng nói 100% rằng các kỹ thuật này sẽ luôn tốt và có nhiều thông tin như có đầy đủ thông tin có sẵn trên một giao diện, nhưng tôi nghĩ từ các ví dụ trên, bạn có thể nói rằng hầu hết thời gian, chúng tôi có lẽ có thể làm tốt như một công việc

Khi làm FP tôi có xu hướng sử dụng các loại ngữ nghĩa cụ thể hơn.

Ví dụ, phương pháp của bạn đối với tôi sẽ trở thành một cái gì đó như:

read: MessageId -> Message

Này liên lạc khá nhiều hơn so với OO (/ java) kiểu ThingDoer.doThing()phong cách

Vì vậy, các lập trình viên chức năng có thể làm gì để bảo tồn ngữ nghĩa của một giao diện có tên?

Sử dụng các chức năng được đặt tên tốt.

IMessageQuery::Read: int -> stringchỉ đơn giản là trở thành ReadMessageQuery: int -> stringhoặc một cái gì đó tương tự.

Điều quan trọng cần lưu ý là tên chỉ là hợp đồng theo nghĩa lỏng lẻo nhất của từ này. Chúng chỉ hoạt động nếu bạn và một lập trình viên khác suy ra cùng một hàm ý từ tên và tuân theo chúng. Bởi vì điều này, bạn thực sự có thể sử dụng bất kỳ tên nào truyền đạt hành vi ngụ ý đó. OO và lập trình chức năng có tên của chúng ở những nơi hơi khác nhau và có hình dạng hơi khác nhau, nhưng chức năng của chúng là như nhau.

Là hợp đồng ngữ nghĩa của một giao diện (OOP) có nhiều thông tin hơn chữ ký hàm (FP)?

Không phải trong ví dụ này. Như tôi đã giải thích ở trên, một lớp / giao diện duy nhất với một chức năng duy nhất không có nhiều thông tin hơn một chức năng độc lập có tên tương tự.

Khi bạn nhận được nhiều hơn một chức năng / trường / thuộc tính trong một lớp, bạn có thể suy luận thêm thông tin về chúng vì bạn có thể thấy mối quan hệ của chúng. Không thể tranh cãi nếu đó là nhiều thông tin hơn các hàm độc lập có cùng tham số / tương tự hoặc các hàm độc lập được tổ chức bởi không gian tên hoặc mô-đun.

Cá nhân, tôi không nghĩ rằng OO có nhiều thông tin hơn đáng kể, ngay cả trong các ví dụ phức tạp hơn.

Tôi không đồng ý rằng một chức năng duy nhất không thể có "hợp đồng ngữ nghĩa". Hãy xem xét các luật này cho foldr:

foldr f z nil = z
foldr f z (singleton x) = f x z
foldr f z (xn <> ys) = foldr f (foldr f z ys) xn

Theo nghĩa nào đó không phải là ngữ nghĩa, hoặc không phải là một hợp đồng? Bạn không cần phải xác định loại cho 'thư mục', đặc biệt vì foldrđược xác định duy nhất bởi các luật đó. Bạn biết chính xác những gì nó sẽ làm.

Nếu bạn muốn thực hiện một chức năng của một số loại, bạn có thể làm điều tương tự:

-- The first argument `f` must satisfy for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
sort :: forall 'a. (a -> a -> bool.t) -> list.t a -> list.t a;

Bạn chỉ cần đặt tên và nắm bắt loại đó nếu bạn cần cùng một hợp đồng nhiều lần:

-- Type of functions `f` satisfying, for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
type comparison.t 'a = a -> a -> bool.t;

Trình kiểm tra loại sẽ không thực thi bất kỳ ngữ nghĩa nào mà bạn gán cho một loại, do đó, việc tạo một loại mới cho mọi hợp đồng chỉ là bản tóm tắt.

Khá nhiều tất cả các ngôn ngữ chức năng được gõ tĩnh có một cách để bí danh các loại cơ bản theo cách yêu cầu bạn khai báo rõ ràng ý định ngữ nghĩa của bạn. Một số câu trả lời khác đã đưa ra ví dụ. Trong thực tế, các lập trình viên chức năng có kinh nghiệm cần những lý do rất chính đáng để sử dụng các loại trình bao bọc đó, bởi vì chúng làm tổn thương khả năng kết hợp và tái sử dụng.

Ví dụ: giả sử khách hàng muốn triển khai truy vấn thư được hỗ trợ bởi danh sách. Trong Haskell, việc thực hiện có thể đơn giản như sau:

messages = ["Message 0", "Message 1", "Message 2"]
messageQuery = (messages !!)

Sử dụng newtype Message = Message Stringđiều này sẽ ít đơn giản hơn nhiều, khiến cho việc thực hiện này trông giống như:

messages = map Message ["Message 0", "Message 1", "Message 2"]
messageQuery (Id index) = messages !! index

Điều đó có vẻ không phải là một vấn đề lớn, nhưng bạn hoặc phải thực hiện chuyển đổi kiểu đó qua lại ở mọi nơi hoặc thiết lập một lớp ranh giới trong mã của bạn, nơi mọi thứ ở trên là Int -> Stringsau đó bạn chuyển đổi nó Id -> Messageđể chuyển sang lớp bên dưới. Nói rằng tôi muốn thêm quốc tế hóa, hoặc định dạng nó trong tất cả các mũ, hoặc thêm bối cảnh đăng nhập, hoặc bất cứ điều gì. Những thao tác này đều đơn giản để kết hợp với một Int -> Stringvà gây khó chịu với một Id -> Message. Không phải là không bao giờ có trường hợp hạn chế loại tăng là mong muốn, nhưng sự phiền toái tốt hơn đáng để đánh đổi.

Bạn có thể sử dụng từ đồng nghĩa loại thay vì trình bao bọc (trong Haskell typethay vì newtype), điều này phổ biến hơn nhiều và không yêu cầu chuyển đổi ở mọi nơi, nhưng nó không cung cấp đảm bảo loại tĩnh như phiên bản OOP của bạn, chỉ là một chút của sự bao bọc. Kiểu bao bọc hầu hết được sử dụng trong trường hợp khách hàng không mong muốn thao túng giá trị, chỉ cần lưu trữ và chuyển lại. Ví dụ, một tập tin xử lý.

Không có gì có thể ngăn khách hàng bị "lật đổ". Bạn chỉ đang tạo ra các vòng để nhảy qua, cho mỗi khách hàng. Một giả đơn giản cho một bài kiểm tra đơn vị thông thường thường yêu cầu hành vi kỳ lạ không có ý nghĩa trong sản xuất. Giao diện của bạn nên được viết để họ không quan tâm, nếu có thể.