Tại sao liên kết chặt chẽ giữa các chức năng và dữ liệu xấu?

Tôi tìm thấy trích dẫn này trong " Niềm vui của Clojure " trên trang. 32, nhưng ai đó đã nói điều tương tự với tôi trong bữa tối tuần trước và tôi cũng đã nghe thấy nó ở những nơi khác:

Nhược điểm của lập trình hướng đối tượng là sự kết hợp chặt chẽ giữa chức năng và dữ liệu.

Tôi hiểu tại sao khớp nối không cần thiết là xấu trong một ứng dụng. Ngoài ra, tôi rất thoải mái khi nói rằng nên tránh trạng thái đột biến và kế thừa, ngay cả trong Lập trình hướng đối tượng. Nhưng tôi không thấy lý do tại sao việc dán các chức năng trên các lớp vốn đã xấu.

Ý tôi là, việc thêm một chức năng vào một lớp có vẻ như gắn thẻ thư trong Gmail hoặc dán tệp vào thư mục. Đây là một kỹ thuật tổ chức giúp bạn tìm lại. Bạn chọn một số tiêu chí, sau đó đặt những thứ như nhau. Trước OOP, các chương trình của chúng tôi có khá nhiều phương thức trong tệp. Ý tôi là, bạn phải đặt các chức năng ở đâu đó. Tại sao không tổ chức chúng?

Nếu đây là một cuộc tấn công che giấu các loại, tại sao họ không nói rằng việc hạn chế loại đầu vào và đầu ra cho một chức năng là sai? Tôi không chắc liệu tôi có thể đồng ý với điều đó không, nhưng ít nhất tôi đã quen thuộc với các đối số an toàn và loại đối số. Điều này nghe với tôi như một mối quan tâm chủ yếu riêng biệt.

Chắc chắn, đôi khi mọi người hiểu sai và đưa chức năng vào lớp sai. Nhưng so với những sai lầm khác, điều này có vẻ như là một bất tiện rất nhỏ.

Vì vậy, Clojure có không gian tên. Việc gắn một hàm trên một lớp trong OOP khác với việc gắn một hàm trong một không gian tên trong Clojure như thế nào và tại sao nó lại tệ đến vậy? Hãy nhớ rằng, các chức năng trong một lớp không nhất thiết chỉ hoạt động đối với các thành viên của lớp đó. Nhìn vào java.lang.StringBuilder - nó hoạt động trên bất kỳ loại tham chiếu nào, hoặc thông qua tự động đấm bốc, trên bất kỳ loại nào.

PS Trích dẫn này tham khảo một cuốn sách mà tôi chưa đọc: Lập trình đa hướng trong Leda: Timothy Budd, 1995 .

Về lý thuyết, khớp nối dữ liệu chức năng lỏng lẻo giúp dễ dàng thêm nhiều chức năng hơn để làm việc trên cùng một dữ liệu. Mặt trái của nó là làm cho việc thay đổi cấu trúc dữ liệu trở nên khó khăn hơn, đó là lý do tại sao trong thực tế, mã chức năng được thiết kế tốt và mã OOP được thiết kế tốt có mức độ khớp rất giống nhau.

Lấy một biểu đồ chu kỳ có hướng (DAG) làm cấu trúc dữ liệu mẫu. Trong lập trình chức năng, bạn vẫn cần một số trừu tượng để tránh lặp lại chính mình, vì vậy bạn sẽ tạo một mô-đun với các chức năng để thêm và xóa các nút và cạnh, tìm các nút có thể truy cập từ một nút nhất định, tạo sắp xếp tôpô, v.v. được kết hợp chặt chẽ với dữ liệu, mặc dù trình biên dịch không thực thi nó. Bạn có thể thêm một nút một cách khó khăn, nhưng tại sao bạn lại muốn? Sự gắn kết trong một mô-đun ngăn chặn khớp nối chặt chẽ trong toàn hệ thống.

Ngược lại, về phía OOP, bất kỳ chức năng nào ngoài các hoạt động DAG cơ bản sẽ được thực hiện trong các lớp "xem" riêng biệt, với đối tượng DAG được truyền vào dưới dạng tham số. Thật dễ dàng để thêm nhiều chế độ xem như bạn muốn hoạt động trên dữ liệu DAG, tạo ra cùng một mức phân tách dữ liệu chức năng như bạn thấy trong chương trình chức năng. Trình biên dịch sẽ không ngăn bạn nhồi nhét mọi thứ vào một lớp, nhưng các đồng nghiệp của bạn thì sẽ.

Thay đổi mô hình lập trình không thay đổi các thực hành trừu tượng, gắn kết và khớp nối tốt nhất, nó chỉ thay đổi các thực hành mà trình biên dịch giúp bạn thực thi. Trong lập trình chức năng, khi bạn muốn khớp dữ liệu chức năng, nó được thi hành theo thỏa thuận của quý ông hơn là trình biên dịch. Trong OOP, phân tách chế độ xem mô hình được thi hành theo thỏa thuận của quý ông thay vì trình biên dịch.

Trong trường hợp bạn không biết nó đã hiểu rõ điều này: Các khái niệm về hướng đối tượng và sự đóng cửa là hai mặt của cùng một đồng tiền. Điều đó nói rằng, đóng cửa là gì? Nó lấy (các) biến hoặc dữ liệu từ phạm vi xung quanh và liên kết với nó bên trong hàm hoặc từ phối cảnh OO, bạn thực hiện điều tương tự khi bạn chuyển một cái gì đó vào hàm tạo để sau này bạn có thể sử dụng phần dữ liệu trong một chức năng thành viên của trường hợp đó. Nhưng lấy những thứ từ phạm vi xung quanh không phải là một điều tốt đẹp để làm - phạm vi xung quanh càng lớn thì càng phải làm điều này (mặc dù thực tế, một số điều xấu thường là cần thiết để hoàn thành công việc). Việc sử dụng các biến toàn cục đang đưa điều này đến mức cực đoan, trong đó các hàm trong một chương trình đang sử dụng các biến ở phạm vi chương trình - thực sự rất xấu. Cómô tả tốt ở nơi khác về lý do tại sao các biến toàn cầu là xấu.

Nếu bạn làm theo các kỹ thuật OO, về cơ bản bạn đã chấp nhận rằng mọi mô-đun trong chương trình của bạn sẽ có một mức độ xấu tối thiểu nhất định. Nếu bạn thực hiện một cách tiếp cận chức năng để lập trình, bạn đang hướng đến một lý tưởng trong đó không có mô-đun nào trong chương trình của bạn sẽ chứa ác đóng cửa, mặc dù bạn vẫn có thể có một số, nhưng nó sẽ ít hơn nhiều so với OO.

Đó là nhược điểm của OO - nó khuyến khích loại dữ liệu này, khớp dữ liệu để hoạt động thông qua việc đóng tiêu chuẩn (một loại lý thuyết lập trình cửa sổ bị phá vỡ ).

Điểm cộng duy nhất là, nếu bạn biết rằng bạn sẽ sử dụng nhiều lần đóng để bắt đầu, OO ít nhất cung cấp cho bạn một khung ý tưởng để giúp tổ chức cách tiếp cận đó để lập trình viên trung bình có thể hiểu được. Cụ thể, các biến được đóng lại là rõ ràng trong hàm tạo chứ không chỉ được thực hiện trong một hàm đóng. Các chương trình chức năng sử dụng nhiều lần đóng thường khó hiểu hơn chương trình OO tương đương, mặc dù không nhất thiết phải kém thanh lịch :)

Đó là về khớp nối kiểu :

Một hàm được xây dựng trong một đối tượng để làm việc trên đối tượng đó không thể được sử dụng trên các loại đối tượng khác.

Trong Haskell, bạn viết các hàm để làm việc với các lớp loại - vì vậy có nhiều loại đối tượng khác nhau mà bất kỳ hàm đã cho nào cũng có thể hoạt động, miễn là nó là một loại của lớp đã cho hoạt động.

Các chức năng độc lập cho phép tách rời như vậy mà bạn không nhận được khi bạn tập trung viết các chức năng của mình để hoạt động bên trong loại A vì sau đó bạn không thể sử dụng chúng nếu bạn không có phiên bản loại A, mặc dù chức năng có thể mặt khác, đủ chung để được sử dụng trên một thể hiện loại B hoặc thể hiện loại C.

Trong Java và các hóa thân tương tự của OOP, các phương thức cá thể (không giống như các hàm miễn phí hoặc phương thức mở rộng) không thể được thêm vào từ các mô-đun khác.

Điều này trở nên hạn chế hơn khi bạn xem xét các giao diện chỉ có thể được thực hiện bằng các phương thức thể hiện. Bạn không thể định nghĩa một giao diện và một lớp trong các mô-đun khác nhau và sau đó sử dụng mã từ mô-đun thứ ba để liên kết chúng lại với nhau. Một cách tiếp cận linh hoạt hơn, như các lớp loại của Haskell sẽ có thể làm điều đó.

Định hướng đối tượng về cơ bản là về Trừu tượng dữ liệu thủ tục (hoặc Trừu tượng dữ liệu chức năng nếu bạn loại bỏ các tác dụng phụ là một vấn đề trực giao). Theo một nghĩa nào đó, Lambda Tính là ngôn ngữ hướng đối tượng thuần túy và lâu đời nhất, vì nó chỉ cung cấp Trừu tượng dữ liệu chức năng (vì nó không có bất kỳ cấu trúc nào ngoài các chức năng).

Chỉ hoạt động của một đơn đối tượng có thể kiểm tra biểu diễn dữ liệu của đối tượng đó. Thậm chí không các đối tượng khác cùng loại có thể làm điều đó. (Đây là sự khác biệt chính giữa Object-Oriented dữ liệu trừu tượng và trừu tượng dữ liệu loại: với ADTs, các đối tượng cùng loại có thể kiểm tra biểu diễn dữ liệu của nhau, chỉ có các đại diện của các đối tượng khác loại được ẩn.)

Điều này có nghĩa là một số đối tượng cùng loại có thể có các biểu diễn dữ liệu khác nhau. Ngay cả cùng một đối tượng có thể có các biểu diễn dữ liệu khác nhau tại các thời điểm khác nhau. (Ví dụ, trong Scala, Maps và Sets chuyển đổi giữa một mảng và một Trie băm tùy thuộc vào số lượng các yếu tố bởi vì đối với số lượng rất nhỏ tuyến tính tìm kiếm trong một mảng là nhanh hơn so với tìm kiếm logarit trong một cây tìm kiếm bởi vì trong những yếu tố không đổi rất nhỏ .)

Từ bên ngoài một đối tượng, bạn không nên, bạn không thể biết biểu diễn dữ liệu của nó. Điều đó trái ngược với khớp nối chặt chẽ.

Khớp nối chặt chẽ giữa dữ liệu và chức năng là không tốt vì bạn muốn có thể thay đổi độc lập với nhau và khớp nối chặt chẽ khiến việc này trở nên khó khăn vì bạn không thể thay đổi cái này mà không biết và có thể thay đổi cái khác.

Bạn muốn các dữ liệu khác nhau được trình bày cho hàm không yêu cầu bất kỳ thay đổi nào trong chức năng và tương tự bạn muốn có thể thay đổi chức năng mà không cần bất kỳ thay đổi nào đối với dữ liệu mà nó đang hoạt động để hỗ trợ các thay đổi chức năng đó.