関数型プログラミングのソフトウェアエンジニアリング手法はありますか？[閉まっている]

今日教えられているソフトウェア工学は、完全にオブジェクト指向プログラミングと「自然な」オブジェクト指向の世界観に焦点を当てています。ドメインモデルをいくつかのステップとユースケース図やクラス図のような多くの（UML）アーティファクトを持つクラスモデルに変換する方法を説明する詳細な方法があります。多くのプログラマーがこのアプローチを取り入れており、オブジェクト指向アプリケーションをゼロから設計する方法について優れたアイデアを持っています。

新しい誇大広告は関数型プログラミングであり、多くの本やチュートリアルで教えられています。しかし、機能的なソフトウェア工学についてはどうでしょうか？LispとClojureについて読んでいるとき、私は2つの興味深いステートメントについて思いつきました。

1. 関数型プログラムは、多くの場合、トップダウンではなくボトムアップで開発されます（「On Lisp」、Paul Graham）

2. 関数型プログラマーはマップを使用し、オブジェクト指向プログラマーはオブジェクト/クラスを使用します（「Clojure for Java Programmers」、Rich Hickleyによる講演）。

では、LispやClojureなどの機能的アプリケーションの体系的な（モデルベースの）設計の方法論とは何でしょうか。一般的な手順は何ですか、どのアーティファクトを使用しますか、それらを問​​題空間からソリューション空間にどのようにマッピングしますか？

ソフトウェアエンジニアが関数型プログラミングをまだ発見していないことを神に感謝します。ここにいくつかの類似点があります：

• 多くのオブジェクト指向の「設計パターン」は、高次関数として取り込まれます。たとえば、Visitorパターンは機能的な世界では「フォールド」（または先のとがった頭の理論家であれば「カタモルフィズム」）として知られています。関数型言語では、データ型は主にツリーまたはタプルであり、すべてのツリー型にはそれに関連する自然な異型があります。

  これらの高階関数には、しばしば「自由定理」とも呼ばれるプログラミングの特定の法則が付属しています。

• 関数型プログラマーは、OOプログラマーよりもダイアグラムをあまり使用しません。OOダイアグラムで表現されるものの多くは、代わりにタイプまたは「シグニチャー」で表現されます。これらは「モジュールタイプ」と考える必要があります。Haskellには「型クラス」もあり、これはインターフェース型に少し似ています。

  型を使用する関数型プログラマーは、一般に、「型を正しく設定すると、コードは実際には自分で書き込む」と考えます。

  すべての関数型言語が明示的な型を使用するわけではありませんが、Scheme / Lisp / Clojureを学習するための優れた本である「How To Design Programs」は、型に密接に関連する「データ記述」に大きく依存しています。

では、LispやClojureなどの機能的アプリケーションの体系的な（モデルベースの）設計の方法論とは何でしょうか。

データの抽象化に基づく設計方法はどれもうまく機能します。言語に明示的な型があると、これは簡単だと思いますが、それがなくても機能します。簡単に関数型プログラミングに適合された抽象データ型の設計方法に関する良い本、あるプログラム開発における抽象化と仕様バーバラ・リスコフとジョン・ガタッグによる最初の版は。リスコフはその仕事の一部でチューリング賞を受賞しました。

Lispに固有のもう1つの設計方法は、作業している問題領域で役立つ言語拡張を決定し、衛生的なマクロを使用してこれらの構成を言語に追加することです。この種のデザインについて読むのに適した場所は、Matthew Flattの記事「言語をラケットで作成する」です。記事がペイウォールの背後にある可能性があります。また、「ドメイン固有の組み込み言語」という用語を検索することにより、この種の設計に関するより一般的な資料を見つけることができます。Matthew Flattがカバーする範囲を超える特定のアドバイスと例については、おそらくGrahamのOn LispまたはおそらくANSI Common Lispから始めます。

一般的な手順は何ですか、どのアーティファクトを使用しますか？

一般的な手順：

1. プログラム内のデータとその操作を識別し、このデータを表す抽象データ型を定義します。

2. 計算の一般的なアクションまたはパターンを識別し、それらを高次関数またはマクロとして表現します。リファクタリングの一部としてこのステップを踏むことを期待してください。

3. 型付き関数型言語を使用している場合は、型チェッカーを早期かつ頻繁に使用してください。LispまたはClojureを使用している場合、ベストプラクティスは、最初に単体テストを含む関数コントラクトを記述することです。これは、テスト駆動開発を最大限に活用することです。また、プラットフォームに移植されたQuickCheck のどのバージョンも使用する必要があります。この場合、それはClojureCheckと呼ばれるように見えます。これは、高次関数を使用するコードのランダムテストを構築するための非常に強力なライブラリです。

Clojureについては、古き良きリレーショナルモデリングに戻ることをお勧めします。Out of the Tarpitは感動的な読み物です。

個人的には、OO開発の通常のすべての優れた実践が関数型プログラミングにも当てはまることを発見しました-関数型の世界観を考慮に入れるためのいくつかのマイナーな調整だけです。方法論の観点からは、根本的に異なることを実際に行う必要はありません。

私の経験は、近年JavaからClojureに移行したことから来ています。

いくつかの例：

• ビジネスドメイン/データモデルを理解する -オブジェクトモデルを設計する場合でも、ネストされたマップを使用して機能データ構造を作成する場合でも、同様に重要です。FPは、関数/プロセスとは別にデータモデルについて考えることを奨励しますが、両方を実行する必要があるため、いくつかの点でより簡単になる場合があります。

• 設計におけるサービス指向 -実際には、FPの観点からは非常にうまく機能します。これは、典型的なサービスは、実際にはいくつかの副作用を伴う単なる関数であるためです。Lispの世界で時々採用されているソフトウェア開発の「ボトムアップ」の見方は、実際には別の見方をすれば、サービス指向のAPI設計原則に過ぎないと思います。

• テスト駆動開発 -FP言語でうまく機能します。純粋な関数は、ステートフルな環境をセットアップする必要がなく、明確で反復可能なテストを書くのに非常に適しているため、実際にはさらに優れています。また、データの整合性をチェックする個別のテストを作成することもできます（たとえば、このマップには、OO言語では、クラス定義がコンパイル時にこれを強制するという事実のバランスをとるために、私が期待するすべてのキーがあります）。

• プロトタイピング/反復-FPでも同様に機能します。ツールやDSLの構築とREPLでの使用に非常に長けていれば、ユーザーと一緒にライブでプロトタイプを作成できるかもしれません。

オブジェクト指向プログラミングは、データと動作を密接に結び付けます。関数型プログラミングは2つを分離します。したがって、クラス図はありませんが、データ構造はあり、特に代数的データ型があります。これらのタイプは、構成によって不可能な値を排除することを含め、ドメインに非常に厳密に一致するように書き込むことができます。

だから本や本はありませんが、ことわざにあるように、不可能な価値を表現できないものにするための確立されたアプローチがあります。

そうすることで、特定のタイプのデータを代わりに関数として表現すること、および逆に特定の関数を代わりにデータタイプの和集合として表現することで、シリアル化、より厳密な仕様、最適化などを得られるように、幅広い選択を行うことができます。 。

次に、ある種の代数を確立するようにadtsの上に関数を記述します。つまり、これらの関数に適用される固定則があります。一部はおそらくべき等です-複数のアプリケーションの後でも同じです。いくつかは連想です。一部は推移的です。

これで、適切に動作する法則に従って構成する関数を持つドメインができました。シンプルな組み込みDSL！

もちろん、指定されたプロパティがあれば、それらの自動ランダム化テストを作成することもできます（QuickCheckとして）。これはほんの始まりにすぎません。

オブジェクト指向設計は、ソフトウェアエンジニアリングと同じではありません。ソフトウェアエンジニアリングは、要件から実際のシステムに至るまでのプロセス全体を、予定どおりに、低い不良率で行う必要があります。関数型プログラミングはOOとは異なる場合がありますが、要件、高レベルで詳細な設計、検証とテスト、ソフトウェアメトリック、推定、およびその他すべての「ソフトウェアエンジニアリング関連」を排除するものではありません。

さらに、関数型プログラムはモジュール性やその他の構造を示します。詳細な設計は、その構造の概念の観点から表現する必要があります。

1つのアプローチは、選択した関数型プログラミング言語内に内部DSLを作成することです。「モデル」は、DSLで表現された一連のビジネスルールです。

別の投稿への私の答えを見てください：

Clojureはどのようにして関心の分離を行っていますか？

私は、FPアプローチを使用する大規模なアプリケーションを構築する方法について、この件についてさらに書く必要があることに同意します（さらに、FP駆動のUIを文書化するために、さらに行う必要があります）

これは素朴で単純なものと考えられるかもしれませんが、「デザインレシピ」（Felleisen et al。の著書HtDPでプログラミングに適用された問題解決への体系的なアプローチ）は、探しているものに近いと思います。

ここでは、いくつかのリンク：

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

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

私は最近この本を見つけました： 機能的で反応的なドメインモデリング

私はあなたの質問と完全に一致していると思います。

本の説明から：

機能的で反応的なドメインモデリングは、純粋な関数の観点からドメインモデルを考える方法と、それらを構成してより大きな抽象を構築する方法を教えます。関数型プログラミングの基本から始めて、複雑なドメインモデルを実装するために知っておく必要がある高度な概念とパターンに徐々に進みます。この本は、代数的データ型、タイプクラスベースの設計、副作用の分離などの高度なFPパターンがモデルを読みやすく検証できるように構成する方法を示しています。

リチャードバード教授とオックスフォード大学（英国）のプログラミング代数グループに関連する「プログラム計算」/「計算による設計」スタイルがありますが、この方法論を検討するのはそれほど難しいことではないと思います。

個人的にはAoPグループの作品が好きですが、私自身はこの方法でデザインを実践する規律はありません。しかし、それは私の欠点であり、プログラム計算の1つではありません。

Behavior Driven Developmentは、ClojureとSBCLの両方でコードを迅速に開発するのに適していることがわかりました。関数型言語でBDDを活用する本当の利点は、問題をより小さな機能のチャンクに分解するより優れた仕事をするので、手続き型言語を使用するときよりもはるかに細かい粒度のユニットテストを書く傾向があることです。

正直なところ、関数型プログラムの設計レシピが必要な場合は、HaskellのPreludeなどの標準関数ライブラリを調べてください。FPでは、パターンは通常、高次のプロシージャ（関数を操作する関数）自体によってキャプチャされます。したがって、パターンが見られる場合、そのパターンをキャプチャするために高次関数が作成されることがよくあります。

良い例がfmapです。この関数は、関数を引数として取り、それを2番目の引数のすべての「要素」に適用します。これはFunctorタイプのクラスの一部であるため、Functorのインスタンス（リスト、グラフなど）をこの関数の2番目の引数として渡すことができます。2番目の引数のすべての要素に関数を適用する一般的な動作をキャプチャします。

上手、

一般に、多くの関数型プログラミング言語は「小さなおもちゃの問題」のために長い間大学で使用されています。

OOPは「状態」が原因で「並列プログラミング」が困難であるため、現在人気が高まっています。また、Google MapReduceのような当面の問題には、関数型スタイルの方が適している場合があります。

functioanlの人たちが壁にぶつかったとき（[1.00000.000行を超えるコードのシステムを実装しようとすると]）、一部の人は流行の言葉を使った新しいソフトウェアエンジニアリングの方法論を思い付くでしょう:-)。彼らは古い質問に答えるべきです：システムを断片に分割して、一度に1つずつ「噛む」ことができるようにする方法は？[反復作業、漸進的、進化的作業]機能的スタイルを使用。

関数型スタイルがオブジェクト指向スタイルに確実に影響することは確かです。関数型システムの多くの概念を「まだ」残し、OOP言語に適合させています。

しかし、関数型プログラムはこのような大きなシステムに使用されるのでしょうか？それが問題です。

そして、そのような大きなシステムを実装せずに現実的な方法論を取り入れて、手を汚すことはできません。最初にあなたの手を汚し、次に解決策を提案するべきです。ソリューション-「本当の痛みと汚れ」のない提案は「ファンタジー」になります。