Có bất kỳ quy trình công việc cụ thể hoặc các mẫu thiết kế thường được sử dụng để tạo các ứng dụng lập trình chức năng lớn không? [đóng cửa]


13

Tôi đã khám phá Clojure được một thời gian rồi, mặc dù tôi chưa sử dụng nó cho bất kỳ dự án không cần thiết nào. Về cơ bản, tôi vừa cảm thấy thoải mái với cú pháp và một số thành ngữ. Đến từ nền tảng OOP, với Clojure là ngôn ngữ chức năng đầu tiên mà tôi đã tìm hiểu rất nhiều, tôi tự nhiên không thoải mái với cách làm việc chức năng.

Điều đó nói rằng, có bất kỳ quy trình công việc cụ thể hoặc các mẫu thiết kế phổ biến với việc tạo các ứng dụng chức năng lớn? Tôi thực sự muốn bắt đầu sử dụng lập trình chức năng "thực sự", nhưng tôi sợ rằng với sự thiếu chuyên môn hiện tại của mình, nó sẽ dẫn đến một thất bại sử thi.

"Gang of Four" là một tiêu chuẩn như vậy đối với các lập trình viên OO, nhưng có điều gì tương tự được hướng nhiều hơn vào mô hình chức năng không? Hầu hết các tài nguyên mà tôi đã tìm thấy đều có các chương trình cố định tuyệt vời, nhưng chúng không lùi lại để mang lại cái nhìn rộng hơn, kiến ​​trúc hơn.


6
Một số mẫu GOF thực sự chỉ là cách giải quyết trong các ngôn ngữ OO cho những thứ mà Lập trình hàm đã cung cấp. Xem stackoverflow.com/q / 327955
Robert Harvey

2
có liên quan: stackoverflow.com/q/89212
kéo


Tôi nghĩ rằng có quá nhiều sự tập trung vào các mẫu cụ thể của GoF / OOP trong cuộc thảo luận này. Bất cứ ai cũng có thể đăng một số mẫu cụ thể lập trình chức năng thực tế (không cố gắng chứng minh tính tầm thường của GoF trong các ngôn ngữ chức năng)?
Daniel B

Câu trả lời:


3

Các mô hình loại này thường là triệu chứng của một mô hình cơ bản bị hỏng, không phù hợp.

OOP bị phá vỡ bởi thiết kế, không phù hợp với hầu hết các ứng dụng của nó, do đó, nó bùng nổ với tất cả cái gọi là "mẫu". Mô hình chức năng linh hoạt hơn (chỉ một chút) và nhu cầu về "mẫu" không rõ ràng ở đó.

Khi bạn bắt đầu áp dụng cách tiếp cận hướng ngôn ngữ (tự nhiên cho các lập trình viên chức năng), sử dụng hoặc tạo DSL cho từng miền vấn đề cụ thể, bạn sẽ thấy rằng không có mẫu nào hiển thị cả, bởi vì bạn luôn sử dụng một mô hình thích hợp cho mô tả một vấn đề.

Tất nhiên một số "mẫu" hoặc "công thức" cấp cao định kỳ là không thể tránh khỏi ngay cả trong toán học rất trừu tượng, sạch sẽ và thuần túy, nhưng chúng thuộc loại khác và có mức độ trừu tượng khác với mẫu GoF. Bạn sẽ tìm thấy các đơn vị hữu ích, ví dụ.


+1 cho 2 đoạn cuối, tôi nghĩ đó là điểm. Về OOP, tôi tò mò về lý do đằng sau việc gọi nó bị hỏng, ngoài thực tế đó là một công cụ chung thường được áp dụng cho các vấn đề cụ thể (do đó các mô hình cấp thấp như các GoF tồn tại). Bạn có thể giải thích ngắn gọn, hoặc đăng một liên kết tóm tắt ý kiến ​​của bạn?
Daniel B

@DanielB, không có gì sai với OOP per se, nhưng cách nó thường được áp dụng là hoàn toàn bị phá vỡ. Mô hình này chỉ phù hợp với một vài vấn đề trong thế giới thực (và nó thực sự tỏa sáng ở đó, khi được áp dụng một cách thích hợp), nhưng đối với phần còn lại, nó cần tất cả các nạng và băng keo để phù hợp. Xem câu trả lời của tôi tại lập trình viên.stackexchange.com/questions / 52608 / ví dụ.
SK-logic

OK, tôi nghĩ rằng tôi đang ở trên cùng một trang. Trên thực tế, tôi có thể đã hỏi câu hỏi chính xác này một lần trước đây, xin lỗi về điều đó - cách bạn diễn đạt câu đó giống như bạn đang ám chỉ nhiều hơn.
Daniel B

-3

Theo ý kiến ​​cá nhân của tôi, các mẫu thiết kế là ngữ nghĩa. Tôi nhớ việc viết lại một số ứng dụng cũ của tôi bằng cách sử dụng MVC chỉ để đảm bảo rằng tôi hiểu mô hình cũng như tôi nghĩ tôi đã làm. Nhưng, cuối cùng, tôi đã không đạt được bất cứ điều gì từ MVC qua mã gốc của mình.

Tuy nhiên, nếu tôi áp dụng mã gốc của mình cho môi trường phát triển lớn hơn và nói với ai đó rằng có vấn đề với phương pháp này ... thì thật khó để nhà phát triển đó có thể theo dõi vấn đề. TUY NHIÊN, nếu tôi nói rằng hợp đồng được kiểm soát vì một số lý do, anh ấy sẽ biết chính xác nên bắt đầu từ đâu.

Các mẫu thiết kế rất tuyệt ... nhưng như tôi đã nói, tôi nghĩ chúng có ngữ nghĩa!

EDIT: Bạn truyền giáo các loại crack tôi lên. Làm thế nào mọi thứ được phát triển mà không có MVC (hoặc một số mẫu thiết kế khác)!


2
semantic (sɪˈmæntɪk) - adj 1. của hoặc liên quan đến ý nghĩa hoặc phát sinh từ sự phân biệt giữa nghĩa của các từ hoặc ký hiệu khác nhau 2. của hoặc liên quan đến ngữ nghĩa (nghiên cứu về ý nghĩa) 3. logic liên quan đến việc giải thích một lý thuyết chính thức, như khi các bảng chân lý được đưa ra như một tài khoản của các kết nối cảm tính
Robert Harvey

+1 - quan điểm của tôi là các mẫu thiết kế chỉ đơn giản là một phương tiện giao tiếp!
aserwin

Các mẫu thiết kế không chỉ là một cách để giao tiếp; chúng là những công thức cụ thể, được hiểu rõ có thể được thực hiện trong phần mềm để giải quyết một số vấn đề thường gặp phải.
Robert Harvey

Đó là những gì những cuốn sách nói. Nhưng tôi chưa bao giờ thực sự giải quyết vấn đề thông qua một mẫu thiết kế mà tôi không thể giải quyết mà không có nó. Ưu điểm duy nhất tôi nhận thấy theo kinh nghiệm của bản thân là khả năng nói chuyện với nhau về mã! ;)
aserwin

1
Về chỉnh sửa của bạn: Vì vậy, bạn muốn phát minh lại bánh xe mỗi khi bạn viết một đoạn mã mới?
Robert Harvey
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.