Có một phương pháp kỹ thuật phần mềm cho lập trình chức năng? [đóng cửa]

Kỹ thuật phần mềm như được dạy ngày nay hoàn toàn tập trung vào lập trình hướng đối tượng và quan điểm hướng đối tượng 'tự nhiên' về thế giới. Có một phương pháp chi tiết mô tả cách chuyển đổi mô hình miền thành mô hình lớp với một số bước và rất nhiều tạo tác (UML) như sơ đồ trường hợp sử dụng hoặc sơ đồ lớp. Nhiều lập trình viên đã tiếp thu phương pháp này và có một ý tưởng tốt về cách thiết kế một ứng dụng hướng đối tượng từ đầu.

Sự cường điệu mới là lập trình chức năng, được dạy trong nhiều sách và hướng dẫn. Nhưng những gì về kỹ thuật phần mềm chức năng? Trong khi đọc về Lisp và Clojure, tôi đã nói về hai câu thú vị:

1. Các chương trình chức năng thường được phát triển từ dưới lên thay vì từ trên xuống ('On Lisp', Paul Graham)

2. Các lập trình viên chức năng sử dụng Bản đồ nơi các lập trình viên OO sử dụng các đối tượng / lớp ('Clojure cho lập trình viên Java', nói chuyện bởi Rich Hickley).

Vậy phương pháp nào cho một thiết kế có hệ thống (dựa trên mô hình?) Của một ứng dụng chức năng, tức là trong Lisp hoặc Clojure? Các bước phổ biến là gì, tôi sử dụng các tạo phẩm nào, làm cách nào để ánh xạ chúng từ không gian vấn đề sang không gian giải pháp?

Cảm ơn Chúa vì những người làm công nghệ phần mềm chưa phát hiện ra lập trình chức năng. Dưới đây là một số điểm tương đồng:

• Nhiều "mẫu thiết kế" OO được ghi lại dưới dạng các hàm bậc cao hơn. Ví dụ, mẫu Khách truy cập được biết đến trong thế giới chức năng là "nếp gấp" (hoặc nếu bạn là một nhà lý thuyết có đầu nhọn, thì "dị hình"). Trong các ngôn ngữ chức năng, các kiểu dữ liệu chủ yếu là cây hoặc bộ dữ liệu và mọi loại cây đều có sự biến đổi tự nhiên liên quan đến nó.

  Các hàm bậc cao hơn này thường đi kèm với một số định luật lập trình nhất định, còn gọi là "định lý tự do".

• Các lập trình viên chức năng sử dụng sơ đồ ít hơn nhiều so với lập trình viên OO. Thay vào đó, phần lớn những gì được thể hiện trong sơ đồ OO được thể hiện bằng các loại hoặc "chữ ký", mà bạn nên nghĩ là "các loại mô-đun". Haskell cũng có "các loại lớp", hơi giống với một loại giao diện.

  Những lập trình viên chức năng sử dụng các loại thường nghĩ rằng "một khi bạn hiểu đúng về các loại; mã thực tế sẽ tự viết."

  Không phải tất cả các ngôn ngữ chức năng đều sử dụng các loại rõ ràng, nhưng cuốn sách Cách thiết kế chương trình , một cuốn sách tuyệt vời để học Scheme / Lisp / Clojure, phụ thuộc rất nhiều vào "mô tả dữ liệu", liên quan chặt chẽ đến các loại.

Vậy phương pháp nào cho một thiết kế có hệ thống (dựa trên mô hình?) Của một ứng dụng chức năng, tức là trong Lisp hoặc Clojure?

Bất kỳ phương pháp thiết kế dựa trên trừu tượng dữ liệu đều hoạt động tốt. Tôi tình cờ nghĩ rằng điều này dễ dàng hơn khi ngôn ngữ có các loại rõ ràng, nhưng nó hoạt động ngay cả khi không có. Một cuốn sách hay về phương pháp thiết kế cho các loại dữ liệu trừu tượng, dễ dàng thích nghi với lập trình chức năng, là Trừu tượng và Đặc tả trong Phát triển Chương trình của Barbara Liskov và John Guttag, phiên bản đầu tiên . Liskov đã giành giải thưởng Turing một phần cho tác phẩm đó.

Một phương pháp thiết kế khác chỉ có ở Lisp là quyết định phần mở rộng ngôn ngữ nào sẽ hữu ích trong miền vấn đề mà bạn đang làm việc, sau đó sử dụng macro vệ sinh để thêm các cấu trúc này vào ngôn ngữ của bạn. Một nơi tốt để đọc về loại thiết kế này là bài viết của Matthew Flatt Tạo ngôn ngữ trong vợt . Bài viết có thể đứng sau một bức tường. Bạn cũng có thể tìm thấy nhiều tài liệu chung hơn về loại thiết kế này bằng cách tìm kiếm cụm từ "ngôn ngữ nhúng dành riêng cho tên miền"; để có lời khuyên và ví dụ cụ thể ngoài những gì Matthew Flatt trình bày, có lẽ tôi sẽ bắt đầu với On Lisp của Graham hoặc có lẽ là ANSI Common Lisp .

Các bước phổ biến, những gì tạo tác tôi sử dụng là gì?

Các bước phổ biến:

1. Xác định dữ liệu trong chương trình của bạn và các hoạt động trên đó và xác định loại dữ liệu trừu tượng đại diện cho dữ liệu này.

2. Xác định các hành động hoặc mô hình tính toán phổ biến và biểu thị chúng dưới dạng các hàm hoặc macro bậc cao hơn. Hy vọng sẽ thực hiện bước này như là một phần của tái cấu trúc.

3. Nếu bạn đang sử dụng ngôn ngữ chức năng đã nhập, hãy sử dụng trình kiểm tra loại sớm và thường xuyên. Nếu bạn đang sử dụng Lisp hoặc Clojure, cách tốt nhất là viết hợp đồng chức năng trước tiên bao gồm kiểm tra đơn vị, đó là sự phát triển dựa trên thử nghiệm đến mức tối đa. Và bạn sẽ muốn sử dụng bất kỳ phiên bản QuickCheck nào đã được chuyển sang nền tảng của bạn, trong trường hợp của bạn có vẻ như nó được gọi là ClojureCheck . Đây là một thư viện cực kỳ mạnh mẽ để xây dựng các bài kiểm tra ngẫu nhiên về mã sử dụng các hàm bậc cao hơn.

Đối với Clojure, tôi khuyên bạn nên quay lại mô hình quan hệ cũ tốt. Out of the Tarpit là một bài đọc đầy cảm hứng.

Cá nhân tôi thấy rằng tất cả các thực tiễn tốt thông thường từ phát triển OO cũng áp dụng trong lập trình chức năng - chỉ với một vài điều chỉnh nhỏ để tính đến thế giới quan chức năng. Từ góc độ phương pháp luận, bạn không thực sự cần phải làm bất cứ điều gì khác biệt cơ bản.

Kinh nghiệm của tôi đến từ việc chuyển từ Java sang Clojure trong những năm gần đây.

Vài ví dụ:

• Hiểu mô hình dữ liệu / miền doanh nghiệp của bạn - quan trọng không kém cho dù bạn sẽ thiết kế mô hình đối tượng hay tạo cấu trúc dữ liệu chức năng với các bản đồ lồng nhau. Theo một số cách, FP có thể dễ dàng hơn vì nó khuyến khích bạn suy nghĩ về mô hình dữ liệu tách biệt với các chức năng / quy trình nhưng bạn vẫn phải thực hiện cả hai.

• Định hướng dịch vụ trong thiết kế - thực sự hoạt động rất tốt từ góc độ FP, vì một dịch vụ thông thường thực sự chỉ là một chức năng với một số tác dụng phụ. Tôi nghĩ rằng quan điểm "từ dưới lên" về phát triển phần mềm đôi khi được tán thành trong thế giới Lisp thực ra chỉ là các nguyên tắc thiết kế API hướng dịch vụ tốt trong một chiêu bài khác.

• Test Driven Development - hoạt động tốt trong các ngôn ngữ FP, trên thực tế đôi khi còn tốt hơn bởi vì các hàm thuần cho vay rất tốt để viết các bài kiểm tra lặp lại rõ ràng mà không cần thiết lập môi trường trạng thái. Bạn cũng có thể muốn xây dựng các thử nghiệm riêng biệt để kiểm tra tính toàn vẹn dữ liệu (ví dụ: bản đồ này có tất cả các khóa trong đó mà tôi mong đợi, để cân bằng thực tế rằng trong ngôn ngữ OO, định nghĩa lớp sẽ thực thi điều này cho bạn trong thời gian biên dịch).

• Prototying / iteration - cũng hoạt động tốt với FP. Bạn thậm chí có thể tạo nguyên mẫu trực tiếp với người dùng nếu bạn cực kỳ giỏi trong việc xây dựng các công cụ / DSL và sử dụng chúng tại REPL.

Lập trình OO kết hợp chặt chẽ dữ liệu với hành vi. Lập trình chức năng tách hai. Vì vậy, bạn không có sơ đồ lớp, nhưng bạn có cấu trúc dữ liệu và bạn đặc biệt có các kiểu dữ liệu đại số. Những loại đó có thể được viết để khớp rất chặt chẽ với miền của bạn, bao gồm loại bỏ các giá trị không thể bằng cách xây dựng.

Vì vậy, không có sách và sách về nó, nhưng có một cách tiếp cận được thiết lập tốt, như đã nói, làm cho các giá trị không thể không thể diễn tả được.

Để làm như vậy, bạn có thể đưa ra một loạt các lựa chọn về việc đại diện cho một số loại dữ liệu nhất định dưới dạng hàm, và ngược lại, đại diện cho các chức năng nhất định dưới dạng liên kết các loại dữ liệu để bạn có thể nhận được, ví dụ: tuần tự hóa, đặc tả kỹ thuật chặt chẽ hơn, tối ưu hóa, v.v. .

Sau đó, cho rằng, bạn viết các hàm trên quảng cáo của mình để bạn thiết lập một số loại đại số - tức là có các luật cố định giữ cho các hàm này. Một số có thể là idempotent - giống nhau sau nhiều ứng dụng. Một số là liên kết. Một số là bắc cầu, vv

Bây giờ bạn có một miền mà bạn có các chức năng soạn thảo theo luật được xử lý tốt. Một DSL nhúng đơn giản!

Ồ, và các thuộc tính đã cho, tất nhiên bạn có thể viết các bài kiểm tra ngẫu nhiên tự động về chúng (ala QuickCheck) .. và đó mới chỉ là khởi đầu.

Thiết kế hướng đối tượng không giống với kỹ thuật phần mềm. Công nghệ phần mềm phải thực hiện với toàn bộ quá trình chúng ta đi từ yêu cầu đến hệ thống làm việc đúng thời gian và với tỷ lệ lỗi thấp. Lập trình chức năng có thể khác với OO, nhưng nó không làm mất đi các yêu cầu, mức độ cao và thiết kế chi tiết, xác minh và thử nghiệm, số liệu phần mềm, ước tính và tất cả các "công cụ kỹ thuật phần mềm" khác.

Hơn nữa, các chương trình chức năng thể hiện tính mô đun và cấu trúc khác. Thiết kế chi tiết của bạn phải được thể hiện dưới dạng các khái niệm trong cấu trúc đó.

Một cách tiếp cận là tạo DSL bên trong theo ngôn ngữ lập trình chức năng được lựa chọn. "Mô hình" sau đó là một tập hợp các quy tắc kinh doanh được thể hiện trong DSL.

Xem câu trả lời của tôi cho bài viết khác:

Làm thế nào để Clojure aproach Tách các mối quan tâm?

Tôi đồng ý nhiều nhu cầu hơn phải được viết về chủ đề này về cách cấu trúc các ứng dụng lớn sử dụng phương pháp tiếp cận FP (Thêm nhiều nhu cầu cần thực hiện để ghi lại các giao diện người dùng điều khiển FP)

Mặc dù điều này có thể được coi là ngây thơ và đơn giản, tôi nghĩ rằng "công thức thiết kế" (một cách tiếp cận có hệ thống để giải quyết vấn đề được áp dụng cho lập trình như Felleisen và cộng sự trong cuốn sách HtDP của họ ) sẽ gần với những gì bạn dường như đang tìm kiếm.

Ở đây, một vài liên kết:

http://www.northeastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371

Gần đây tôi đã tìm thấy cuốn sách này: Mô hình hóa miền chức năng và phản ứng

Tôi nghĩ là hoàn toàn phù hợp với câu hỏi của bạn.

Từ mô tả cuốn sách:

Mô hình hóa miền chức năng và phản ứng dạy cho bạn cách nghĩ về mô hình miền theo các hàm thuần túy và cách kết hợp chúng để xây dựng các khái niệm trừu tượng lớn hơn. Bạn sẽ bắt đầu với những điều cơ bản về lập trình chức năng và dần dần tiến tới các khái niệm và mẫu nâng cao mà bạn cần biết để thực hiện các mô hình miền phức tạp. Cuốn sách cho thấy các mẫu FP tiên tiến như kiểu dữ liệu đại số, thiết kế dựa trên kiểu chữ và cách ly các hiệu ứng phụ có thể làm cho mô hình của bạn sáng tác để dễ đọc và kiểm chứng.

Có kiểu "tính toán chương trình" / "thiết kế theo tính toán" liên quan đến Giáo sư Richard Bird và nhóm Đại số lập trình tại Đại học Oxford (Anh), tôi không nghĩ rằng nó quá xa vời để coi đây là một phương pháp.

Cá nhân tôi thích tác phẩm do nhóm AoP sản xuất, tôi không có kỷ luật để tự mình thiết kế theo cách này. Tuy nhiên đó là thiếu sót của tôi, và không phải là một tính toán của chương trình.

Tôi đã thấy Phát triển hướng hành vi là phù hợp tự nhiên để phát triển nhanh mã trong cả Clojure và SBCL. Mặt trái thực sự của việc thúc đẩy BDD với một ngôn ngữ chức năng là tôi có xu hướng viết các bài kiểm tra đơn vị hạt mịn hơn nhiều so với khi tôi sử dụng các ngôn ngữ thủ tục vì tôi thực hiện công việc phân tách vấn đề thành các phần nhỏ hơn của chức năng.

Thành thật nếu bạn muốn thiết kế công thức nấu ăn cho các chương trình chức năng, hãy xem các thư viện chức năng tiêu chuẩn như Haskell's Prelude. Trong FP, các mẫu thường được nắm bắt bởi các thủ tục bậc cao hơn (các hàm hoạt động trên các hàm). Vì vậy, nếu một mẫu được nhìn thấy, thường thì một hàm bậc cao hơn được tạo ra đơn giản để chụp mẫu đó.

Một ví dụ điển hình là fmap. Hàm này lấy một hàm làm đối số và áp dụng nó cho tất cả các "phần tử" của đối số thứ hai. Vì nó là một phần của lớp loại Functor, bất kỳ trường hợp nào của Functor (chẳng hạn như danh sách, biểu đồ, v.v.) có thể được chuyển qua làm đối số thứ hai cho hàm này. Nó nắm bắt hành vi chung của việc áp dụng một hàm cho mọi phần tử của đối số thứ hai của nó.

Tốt,

Nói chung, nhiều ngôn ngữ lập trình chức năng được sử dụng tại các trường đại học trong một thời gian dài cho "các vấn đề đồ chơi nhỏ".

Hiện tại chúng đang trở nên phổ biến hơn vì OOP gặp khó khăn với "lập trình paralel" vì "trạng thái". Và đôi khi phong cách chức năng tốt hơn cho vấn đề trong tay như Google MapReduce.

Tôi chắc chắn rằng, khi những người funcioanl chạm tường [cố gắng thực hiện các hệ thống lớn hơn 1.000.000 dòng mã], một số trong số họ sẽ đi kèm với các phương pháp kỹ thuật phần mềm mới với các từ buzz :-). Họ nên trả lời câu hỏi cũ: Làm thế nào để chia hệ thống thành từng mảnh để chúng ta có thể "cắn" từng mảnh một? [làm việc lặp đi lặp lại, theo cách tiến hóa en bằng cách sử dụng Phong cách chức năng.

Chắc chắn rằng Phong cách chức năng sẽ ảnh hưởng đến Phong cách hướng đối tượng của chúng tôi. Chúng tôi "vẫn" nhiều khái niệm từ Hệ thống chức năng và thích nghi với các ngôn ngữ OOP của chúng tôi.

Nhưng liệu các chương trình chức năng sẽ được sử dụng cho một hệ thống lớn như vậy? Chúng sẽ trở thành luồng chính? Đó là câu hỏi .

Và Không ai có thể đi kèm với phương pháp luận thực tế mà không thực hiện một hệ thống lớn như vậy, làm cho bàn tay của cô ấy trở nên bẩn thỉu. Trước tiên, bạn nên làm cho bàn tay của bạn bẩn sau đó đề xuất giải pháp. Giải pháp-Gợi ý mà không có "nỗi đau và bụi bẩn thực sự" sẽ là "tưởng tượng".