Từ sự tiếp xúc (hạn chế) của tôi đối với các ngôn ngữ lập trình chức năng, như Clojure, dường như việc đóng gói dữ liệu có vai trò ít quan trọng hơn. Thông thường các loại bản địa khác nhau như bản đồ hoặc bộ là loại tiền được ưu tiên đại diện cho dữ liệu, trên các đối tượng. Hơn nữa, dữ liệu đó nói chung là bất biến.
Ví dụ, đây là một trong những trích dẫn nổi tiếng từ Rich Hickey of Clojure nổi tiếng, trong một cuộc phỏng vấn về vấn đề này :
Fogus: Theo ý tưởng đó, một số người ngạc nhiên về việc Clojure không tham gia vào việc đóng gói ẩn dữ liệu trên các loại của nó. Tại sao bạn quyết định từ bỏ ẩn dữ liệu?
Hickey: Chúng ta hãy rõ ràng rằng Clojure nhấn mạnh mạnh vào lập trình để trừu tượng hóa. Tại một số điểm, ai đó sẽ cần phải có quyền truy cập vào dữ liệu. Và nếu bạn có một khái niệm về riêng tư, bạn cần có những khái niệm tương ứng về đặc quyền và sự tin tưởng. Và điều đó thêm vào cả tấn sự phức tạp và ít giá trị, tạo ra sự cứng nhắc trong một hệ thống và thường buộc mọi thứ phải sống ở những nơi họ không nên đến. Điều này là thêm vào sự mất mát khác xảy ra khi thông tin đơn giản được đưa vào các lớp. Trong phạm vi dữ liệu là bất biến, có rất ít tác hại có thể đến từ việc cung cấp quyền truy cập, ngoài việc ai đó có thể phụ thuộc vào thứ gì đó có thể thay đổi. Chà, được thôi, mọi người làm điều đó mọi lúc trong cuộc sống thực, và khi mọi thứ thay đổi, họ thích nghi. Và nếu chúng hợp lý, họ biết khi nào họ đưa ra quyết định dựa trên điều gì đó có thể thay đổi mà họ có thể cần phải thích nghi trong tương lai. Vì vậy, đó là một quyết định quản lý rủi ro, tôi nghĩ các lập trình viên nên tự do thực hiện. Nếu mọi người không có sự nhạy cảm với mong muốn lập trình trừu tượng và cảnh giác với việc kết hôn với các chi tiết thực hiện, thì họ sẽ không bao giờ trở thành lập trình viên giỏi.
Đến từ thế giới OO, điều này dường như làm phức tạp một số nguyên tắc được bảo tồn mà tôi đã học được trong nhiều năm. Chúng bao gồm Ẩn thông tin, Luật Demeter và Nguyên tắc truy cập thống nhất, để nêu tên một số. Chủ đề chung là đóng gói cho phép chúng ta xác định API để người khác biết họ nên và không nên chạm vào cái gì. Về bản chất, tạo một hợp đồng cho phép người duy trì một số mã tự do thực hiện các thay đổi và tái cấu trúc mà không cần lo lắng về cách nó có thể đưa lỗi vào mã của người tiêu dùng (nguyên tắc Mở / Đóng). Nó cũng cung cấp một giao diện sạch, được quản lý để các lập trình viên khác biết họ có thể sử dụng công cụ nào để sử dụng hoặc xây dựng dữ liệu đó.
Khi dữ liệu được phép truy cập trực tiếp, hợp đồng API đó đã bị hỏng và tất cả những lợi ích đóng gói đó dường như biến mất. Ngoài ra, dữ liệu bất biến nghiêm ngặt dường như khiến việc chuyển qua các cấu trúc cụ thể của miền (đối tượng, cấu trúc, bản ghi) ít hữu ích hơn theo nghĩa đại diện cho một trạng thái và tập hợp các hành động có thể được thực hiện trên trạng thái đó.
Làm thế nào để các cơ sở mã chức năng giải quyết các vấn đề dường như xuất hiện khi kích thước của một cơ sở mã phát triển lớn đến mức cần phải xác định API và rất nhiều nhà phát triển có liên quan đến việc làm việc với các phần cụ thể của hệ thống? Có ví dụ nào về tình huống này có sẵn để chứng minh cách xử lý này trong các loại cơ sở mã này không?
Also, strictly immutable data seems to make passing around domain-specific structures (objects, structs, records) much less useful in the sense of representing a state and the set of actions that can be performed on that state.Không hẳn vậy. Điều duy nhất thay đổi là những thay đổi kết thúc trên một đối tượng mới. Đây là một chiến thắng lớn khi nói về lý luận về mã; vượt qua các đối tượng có thể thay đổi xung quanh có nghĩa là phải theo dõi xem ai có thể đột biến chúng, một vấn đề mở rộng với kích thước của mã.