Vì ngôn ngữ máy (ví dụ 0110101000110101:) ngôn ngữ máy tính thường phát triển thành các hình thức trừu tượng cao hơn, nói chung giúp dễ hiểu mã hơn khi áp dụng cho một vấn đề. Trình biên dịch là một bản tóm tắt về mã máy, C là phần trừu tượng so với trình biên dịch, v.v.
Thiết kế hướng đối tượng dường như rất tốt trong việc cho phép chúng ta mô hình hóa một vấn đề về các đối tượng, ví dụ, vấn đề của hệ thống đăng ký khóa học đại học có thể được mô hình hóa với một Courselớp, một Studentlớp, v.v. Sau đó, khi chúng ta viết giải pháp trong ngôn ngữ OO, chúng tôi có các lớp tương tự nhận trách nhiệm và thường hữu ích cho thiết kế, đặc biệt là để mô đun hóa mã. Nếu tôi đưa ra vấn đề này cho 10 nhóm độc lập giải quyết nó bằng phương pháp OO, thông thường, 10 giải pháp sẽ có các lớp liên quan đến vấn đề chung. Có thể có nhiều sự khác biệt khi bạn bắt đầu tham gia vào khớp nối và tương tác của các lớp đó, vì vậy không có thứ gọi là "khoảng cách biểu diễn bằng không".
Trải nghiệm của tôi với Lập trình chức năng rất hạn chế (không sử dụng trong thế giới thực, chỉ có các chương trình loại Hello World). Tôi không thấy các ngôn ngữ như vậy cho phép dễ dàng ánh xạ các giải pháp FP đến các vấn đề (với khoảng cách biểu diễn thấp) theo cách mà các ngôn ngữ OO làm.
Tôi hiểu những lợi thế của FP liên quan đến lập trình đồng thời. Nhưng tôi có thiếu một cái gì đó không, hay là FP không phải là về việc thu hẹp khoảng cách đại diện (làm cho các giải pháp dễ hiểu hơn)?
Một cách khác để hỏi điều này: liệu mã FP của 10 đội khác nhau giải quyết cùng một vấn đề trong thế giới thực có nhiều điểm chung không?
Từ Wikipedia về Trừu tượng (khoa học máy tính) (nhấn mạnh của tôi):
Các ngôn ngữ lập trình hàm thường thể hiện sự trừu tượng liên quan đến các hàm , chẳng hạn như trừu tượng lambda (biến một thuật ngữ thành hàm của một số biến), các hàm bậc cao hơn (tham số là hàm), trừu tượng khung (biến thuật ngữ thành hàm của biến).
Khoảng cách về đại diện có thể có khả năng gia tăng, bởi vì [một số] các vấn đề trong thế giới thực không được mô hình hóa dễ dàng với sự trừu tượng như vậy.
Một cách khác tôi thấy giảm khoảng cách biểu diễn là trong việc truy tìm các yếu tố giải pháp trở lại vấn đề. Các 0's và 1s trong mã máy là rất khó theo dõi trở lại, trong khi các Studentlớp học rất dễ dàng để dấu vết lại. Không phải tất cả các lớp OO dễ dàng theo dõi không gian vấn đề, nhưng nhiều người làm.
Không trừu tượng FP luôn cần giải thích để tìm ra phần nào của không gian vấn đề mà họ đang giải quyết (ngoài các vấn đề toán học )?OK - Tôi tốt về phần này. Sau khi xem xét nhiều ví dụ khác, tôi thấy cách trừu tượng của FP rất rõ ràng đối với các phần của vấn đề được thể hiện trong xử lý dữ liệu.
Câu trả lời được chấp nhận cho một câu hỏi liên quan Có thể sử dụng UML để mô hình hóa chương trình Chức năng không? - cho biết "Các lập trình viên chức năng không có nhiều sử dụng cho sơ đồ." Tôi thực sự không quan tâm nếu đó là UML, nhưng nó khiến tôi băn khoăn về việc tóm tắt FP dễ hiểu / giao tiếp, nếu không có sơ đồ nào được sử dụng rộng rãi (giả sử câu trả lời này là chính xác). Một lần nữa, mức độ sử dụng / hiểu biết về FP của tôi là không đáng kể, vì vậy tôi hiểu rằng không cần sơ đồ trên các chương trình FP đơn giản.
Thiết kế OO có mức độ trừu tượng của chức năng / lớp / gói, với sự đóng gói (kiểm soát truy cập, ẩn thông tin) ở mỗi cấp độ, giúp cho việc quản lý phức tạp dễ dàng hơn. Đây là những yếu tố cho phép đi từ vấn đề đến giải pháp và trở lại dễ dàng hơn.
Nhiều câu trả lời nói về cách phân tích và thiết kế được thực hiện trong FP theo cách tương tự như OO, nhưng không ai trích dẫn bất cứ điều gì ở cấp độ cao cho đến nay (paul đã trích dẫn một số nội dung thú vị, nhưng ở mức độ thấp). Tôi đã làm rất nhiều Googling ngày hôm qua và tìm thấy một số cuộc thảo luận thú vị. Sau đây là từ Tái cấu trúc các chương trình chức năng của Simon Thompson (2004) (nhấn mạnh của tôi)
Trong việc thiết kế một hệ thống hướng đối tượng, phải thừa nhận rằng thiết kế sẽ đi trước lập trình. Các thiết kế sẽ được viết bằng một hệ thống như UML, được hỗ trợ trong các công cụ như Eclipse. Các lập trình viên mới bắt đầu cũng có thể học một phương pháp thiết kế trực quan bằng cách sử dụng các hệ thống như BlueJ. Làm việc trên một phương pháp tương tự để lập trình chức năng được báo cáo trong FAD: Phân tích và thiết kế chức năng , nhưng có rất ít công việc khác tồn tại. Có thể có một số lý do cho việc này.
Các chương trình chức năng hiện có có quy mô không yêu cầu thiết kế. Nhiều chương trình chức năng là nhỏ, nhưng những chương trình khác, chẳng hạn như Trình biên dịch Haskell của Glasgow, là đáng kể.
Các chương trình chức năng trực tiếp mô hình hóa miền ứng dụng, do đó kết xuất thiết kế không liên quan. Trong khi các ngôn ngữ chức năng cung cấp nhiều loại trừu tượng mạnh mẽ, thật khó để tranh luận rằng những ngôn ngữ này cung cấp tất cả và chỉ những trừu tượng cần thiết để mô hình hóa thế giới thực.
Các chương trình chức năng được xây dựng như một loạt các nguyên mẫu đang phát triển.
Trong luận án tiến sĩ được trích dẫn ở trên , lợi ích của việc sử dụng phương pháp phân tích và thiết kế (ADM) được phác thảo độc lập với mô hình. Nhưng một lập luận được đưa ra là các ADM phải phù hợp với mô hình triển khai. Đó là, OOADM hoạt động tốt nhất cho lập trình OO và không được áp dụng tốt cho một mô hình khác như FP. Đây là một trích dẫn tuyệt vời mà tôi nghĩ rằng diễn giải những gì tôi gọi là khoảng cách đại diện:
người ta có thể tranh luận về việc mô hình nào cung cấp sự hỗ trợ tốt nhất cho phát triển phần mềm, nhưng người ta đạt được gói phát triển tự nhiên, hiệu quả và hiệu quả nhất khi một mô hình duy nhất từ mô tả vấn đề cho đến thực hiện và phân phối.
Dưới đây là bộ sơ đồ được đề xuất bởi FAD:
- sơ đồ phụ thuộc chức năng trình bày một chức năng với những chức năng mà nó sử dụng trong quá trình thực hiện;
- biểu đồ phụ thuộc loại cung cấp cùng một dịch vụ cho các loại; và,
- sơ đồ phụ thuộc mô-đun trình bày quan điểm của kiến trúc mô-đun của hệ thống.
Có một nghiên cứu trường hợp trong phần 5.1 của luận án FAD, đây là một hệ thống để tự động hóa việc sản xuất dữ liệu liên quan đến một giải đấu bóng đá (bóng đá). Các yêu cầu là 100% chức năng, ví dụ: kết quả bóng đá đầu vào, tạo bảng giải đấu, bảng ghi bàn, bảng tham dự, chuyển cầu thủ giữa các đội, cập nhật dữ liệu sau kết quả mới, v.v. Không đề cập đến cách FAD hoạt động để giải quyết các yêu cầu phi chức năng được ghi lại , ngoài việc nói rằng "chức năng mới nên được cho phép với chi phí tối thiểu", một điều gần như không thể kiểm tra.
Đáng buồn thay, ngoài FAD, tôi không thấy bất kỳ tài liệu tham khảo hiện đại nào cho các ngôn ngữ mô hình hóa (trực quan) được đề xuất cho FP. UML là một mô hình khác, vì vậy chúng ta nên quên điều đó.