関数型プログラミングはGoF設計パターンを置き換えるものですか？

昨年F＃とOCamlの学習を始めて以来、デザインパターン（特にJavaの場合）が命令型言語で欠落している機能の回避策であると主張する記事を数多く読みました。私が見つけた1つの記事はかなり強い主張をしています：

私が会ったほとんどの人は、Gang of Four（GoF）によるデザインパターンの本を読んだことがあります 。自尊心のあるプログラマーなら誰でも、その本は言語にとらわれず、パターンは、使用する言語に関係なく、ソフトウェアエンジニアリング全般に当てはまることを教えてくれます。これは高貴な主張です。残念ながら、それは真実からかけ離れています。

関数型言語は非常に表現力があります。関数型言語では、言語が非常に高レベルである可能性が高いため、設計パターンは必要ありません。結局、設計パターンをすべて排除する概念でプログラミングすることになります。

関数型プログラミング（FP）の主な機能には、ファーストクラスの値、カリー化、不変値などの関数が含まれます。OOデザインパターンがこれらの機能のいずれかに近似していることは明らかではありません。

さらに、OOPをサポートする関数型言語（F＃やOCamlなど）では、これらの言語を使用するプログラマーが、他のすべてのOOP言語で利用可能な同じデザインパターンを使用することは明らかです。実際、現在、私は毎日F＃とOCamlを使用しており、これらの言語で使用するパターンとJavaで書くときに使用するパターンとの間に顕著な違いはありません。

関数型プログラミングによってOOP設計パターンが不要になるという主張に真実はありますか？もしそうなら、典型的なOOP設計パターンとそれに相当する機能の例を投稿またはリンクできますか？

あなたが引用したブログ投稿は、その主張を少し誇張しています。FPはデザインパターンの必要性を排除しません。「デザインパターン」という用語は、FP言語で同じことを説明するために広く使用されているわけではありません。しかし、それらは存在します。関数型言語には、「問題Xに遭遇したときに、Yのようなコードを使用する」という形式のベストプラクティスルールがたくさんあります。これは、基本的にデザインパターンです。

ただし、ほとんどのOOP固有のデザインパターンは、関数型言語ではほとんど無関係です。

一般に、デザインパターンは言語の欠点を修正するためだけに存在していると言っても、特に論争の的にはならないと思います。そして、別の言語が同じ問題を簡単に解決できる場合、その他の言語はそのための設計パターンを必要としません。その言語のユーザーは、問題が存在することにさえ気付かないかもしれません。なぜなら、それはその言語では問題ではないからです。

ギャングオブフォーがこの問題について述べていることは次のとおりです。

プログラミング言語の選択は、自分の視点に影響を与えるため、重要です。私たちのパターンは、Smalltalk / C ++レベルの言語機能を想定しており、その選択により、簡単に実装できるものと実装できないものが決まります。手続き型言語を想定した場合、「継承」、「カプセル化」、「ポリモーフィズム」と呼ばれる設計パターンが含まれている可能性があります。同様に、パターンの一部は、あまり一般的ではないオブジェクト指向言語によって直接サポートされています。CLOSには、たとえば、Visitorなどのパターンの必要性を減らすマルチメソッドがあります。実際、SmalltalkとC ++の間には十分な違いがあり、一部のパターンは1つの言語で他の言語よりも簡単に表現できます。（たとえば、イテレーターを参照してください。）

（上記は、Introduction to the Design Patternsブックの4ページ、パラグラフ3からの引用です）

関数型プログラミングの主な機能には、ファーストクラスの値、カリー化、不変値などの関数が含まれます。OOデザインパターンがこれらの機能のいずれかに近似していることは明らかではありません。

ファーストクラスの関数の近似でない場合、コマンドパターンは何ですか？:) FP言語では、関数を引数として別の関数に渡すだけです。OOP言語では、関数をクラスにラップする必要があります。これをインスタンス化して、そのオブジェクトを他の関数に渡すことができます。効果は同じですが、OOPではデザインパターンと呼ばれ、かなり多くのコードが必要です。そして、カレー化されていない場合、抽象的なファクトリパターンは何ですか？関数にパラメーターを少しずつ渡して、最後に呼び出したときにどのような値が関数から出力されるかを構成します。

したがって、はい。FPF言語ではいくつかのGoFデザインパターンが冗長になっています。これは、より強力で使いやすい代替手段が存在するためです。

しかしもちろん、FP言語では解決されないデザインパターンがまだあります。シングルトンに相当するFPとは何ですか？（シングルトンは一般にひどいパターンであることを少しの間無視します。）

そして、それは両方の方法でも機能します。先ほど言ったように、FPにもデザインパターンがあります。人々は通常それらをそのように考えていないだけです。

しかし、あなたはモナドに出くわしたかもしれません。「グローバルな状態に対処する」ための設計パターンではないにしても、それらは何ですか？これはOOP言語では非常に単純な問題であり、同等のデザインパターンは存在しません。

「静的変数をインクリメントする」、または「そのソケットから読み取る」ためのデザインパターンは必要ありません。これは、あなたがすることだけなのでです。

モナドが設計パターンであると言うことは、通常の演算で整数を表し、ゼロ要素が設計パターンであると言うのと同じくらいばかげています。いいえ、モナドは数学的なパターンであり、デザインパターンではありません。

（純粋な）関数型言語では、モナドの「デザインパターン」や、同じことを可能にする他の方法で回避しない限り、副作用や変更可能な状態は不可能です。

さらに、OOPをサポートする関数型言語（F＃やOCamlなど）では、これらの言語を使用するプログラマーが、他のすべてのOOP言語で利用可能な同じデザインパターンを使用することは明らかです。実際、現在私はF＃とOCamlを毎日使用しており、これらの言語で使用するパターンとJavaで書くときに使用するパターンとの間に顕著な違いはありません。

おそらくあなたはまだ命令的に考えているからですか？多くの人は、生涯にわたって命令型言語を扱った後、関数型言語を試すときにその習慣をあきらめるのに苦労しています。（私はF＃でかなり面白い試みをいくつか見ました。文字通りすべての関数は、基本的にはCプログラムを取得し、すべてのセミコロンを 'let'で置き換えたかのように、単に 'let'ステートメントの文字列でした。:)）

しかし、別の可能性としては、OOP言語での設計パターンを必要とする問題を簡単に解決していることに気付いていない可能性があります。

カレーを使用するとき、または関数を引数として別の関数に渡すときは、停止して、OOP言語でそれを行う方法を考えてください。

関数型プログラミングによってOOP設計パターンが不要になるという主張に真実はありますか？

うん。:) FP言語で作業する場合、OOP固有のデザインパターンは必要ありません。ただし、MVCやその他の非OOP固有のものなど、いくつかの一般的なデザインパターンが必要です。代わりに、FP固有の新しい「デザインパターン」がいくつか必要です。すべての言語には欠点があり、通常、デザインパターンはそれらを回避する方法です。

とにかく、ML（少なくとも学習目的では私の個人的なお気に入り）やHaskellなどの「よりクリーンな」FP言語で手を試すのは興味深いかもしれません。新しい何かに直面しています。

予想通り、何人かの人が私のデザインパターンの定義に「言語の欠点を修正する」と異議を唱えたので、これが私の正当化です。

すでに述べたように、ほとんどの設計パターンは1つのプログラミングパラダイムに固有であり、場合によっては1つの特定の言語にも固有です。多くの場合、それらはそのパラダイムにのみ存在する問題を解決します（FPのモナド、またはOOPの抽象ファクトリーを参照）。

抽象ファクトリパターンがFPに存在しないのはなぜですか？解決しようとする問題はそこには存在しないからです。

したがって、FP言語にはない問題がOOP言語に存在する場合、それは明らかにOOP言語の欠点です。問題は解決できますが、あなたの言語では解決できませんが、問題を回避するには、あなたからの一連の定型コードが必要です。理想的には、私たちのプログラミング言語がすべての問題を魔法のように解消することを望んでいます。依然として存在する問題は、原則として言語の欠点です。;）

関数型プログラミングによってOOP設計パターンが不要になるという主張に真実はありますか？

関数型プログラミングは、オブジェクト指向プログラミングと同じではありません。オブジェクト指向の設計パターンは、関数型プログラミングには適用されません。代わりに、関数型プログラミングの設計パターンがあります。

関数型プログラミングの場合、オブジェクト指向の設計パターンの本を読むことはありません。FP設計パターンに関する他の本も読んでください。

言語にとらわれない

完全にではありません。オブジェクト指向言語に関して言語にとらわれないもののみ。デザインパターンは、手続き型言語にはまったく適用されません。リレーショナルデータベースの設計コンテキストではほとんど意味がありません。スプレッドシートのデザインには適用されません。

典型的なOOP設計パターンとそれに相当する機能？

上記は存在すべきではありません。これは、OOコードとして書き換えられた手続き型コードを要求するようなものです。うーん...元のFortran（またはC）をJavaに翻訳する場合、それを翻訳する以外に何もしていません。それを完全にOOパラダイムに書き換えると、元のFortranやCのようには見えなくなり、認識できなくなります。

オブジェクト指向の設計から機能的な設計への単純なマッピングはありません。彼らは問題を見る非常に異なる方法です。

関数型プログラミング（すべてのプログラミングスタイルと同様）には、設計パターンがあります。リレーショナルデータベースには設計パターン、OOには設計パターン、手続き型プログラミングには設計パターンがあります。建物の建築も含め、すべてにデザインパターンがあります。

設計パターンは、概念としては、テクノロジーや問題のドメインに関係なく、時代を超えた構築方法です。ただし、特定の設計パターンは、特定の問題領域およびテクノロジーに適用されます。

彼らがやっていることを考えている誰もがデザインパターンを明らかにするでしょう。

言語とパターンの密接な関連についてのブライアンのコメントは要点です、

この議論の欠けている部分はイディオムの概念です。James O. Coplienの著書「Advanced C ++」は、ここで大きな影響を与えました。クリストファーアレクサンダーと名前のないコラムを発見するずっと前に（そして、アレクサンダーを読まないとパターンについて賢明に話すことができません）、彼は真に言語を学ぶ上でイディオムを習得することの重要性について話しました。彼は例としてCで文字列のコピーを使用しました。while(*from++ = *to++);これは、欠落している言語機能（またはライブラリ機能）のバンドエイドと見なすことができますが、本当に重要なのは、それが他のどれよりも思考または表現の単位が大きいことです。その部分。

それが私たちの意図をより簡潔に表現できるようにするために、パターンや言語がやろうとしていることです。思考の単位が豊富であるほど、表現できる思考が複雑になります。システムアーキテクチャから少しいじくり回すまで、さまざまなスケールで豊富な共有語彙を使用することで、よりインテリジェントな会話を行い、何をすべきかについて考えることができます。

個人として学ぶこともできます。これが演習全体の要点です。自分では考えられないことを一人ひとりが理解して使うことができます。言語、フレームワーク、ライブラリ、パターン、イディオムなどはすべて、知的財産を共有する立場にあります。

GoFの本はOOPと明確に結び付いています。タイトルは「デザインパターン-再利用可能なオブジェクト指向ソフトウェアの要素」です（強調は私のものです）。

Peter Norvigによる動的プログラミングの設計パターンは、この一般的なテーマを慎重にカバーしていますが、「関数型」ではなく「動的」言語についてです（重複があります）。

このトピックについて説明する別のリンクを次に示します。http：//blog.ezyang.com/2010/05/design-patterns-in-haskel/

エドワードは彼のブログ投稿で、23の元のGoFパターンすべてをHaskellの観点から説明しています。

これを「一般的なデザインパターン」と「FP対OOP」のレベルで見てみると、わかる答えはせいぜいあいまいなものです。

ただし、両方の軸でより深いレベルに移動し、特定のデザインパターンと特定の言語機能を検討してください。

したがって、たとえば、一部の特定のパターン（Visitor、Strategy、Command、Observerなど）は、代数的データタイプとパターンマッチング、クロージャ、ファーストクラス関数などを備えた言語を使用すると、確実に変更または非表示になります。しかし、「周りをくぐる」。

一般的に、新しい（または人気が高まっている）言語機能によって、特定のパターンは時間の経過とともに排除されていると私は言います。これは言語設計の自然な流れです。言語がより高水準になるにつれて、以前は例を使用して本でしか呼び出せなかった抽象化が、特定の言語機能またはライブラリのアプリケーションになりました。

（余談：ここに私が書いた最近のブログがあります。FPとデザインパターンに関するより多くの議論への他のリンクがあります。）

Norvigのプレゼンテーションは、すべてのGoFパターンを分析したことをほのめかしており、23のパターンのうち16は関数型言語での実装が単純であるか、単に言語の一部であると述べています。したがって、おそらくそれらの少なくとも7つは、a）同等に複雑であるか、b）言語に存在していません。残念ながら、それらは列挙されていません！

GoFの「創造的」または「構造的」パターンのほとんどは、JavaまたはC ++のプリミティブ型システムに必要なことをさせるためのトリックにすぎないことは明らかだと思います。しかし、残りの部分は、どの言語でプログラミングしても考慮に値します。

1つはプロトタイプかもしれません。これはJavaScriptの基本的な概念ですが、他の言語ではゼロから実装する必要があります。

私のお気に入りのパターンの1つはNull Objectパターンです。適切な種類の何もしないオブジェクトとして何かが存在しないことを表します。これは、関数型言語でモデル化する方が簡単な場合があります。しかし、実際の成果は視点の変化です。

Lispのような言語でマクロをサポートしている場合、ドメイン固有の抽象化を構築できます。抽象化は、一般的なイディオムソリューションよりもはるかに優れていることがよくあります。

さらに、OO設計パターンソリューションでさえ、言語固有です。

デザインパターンは、プログラミング言語では解決できない一般的な問題の解決策です。Javaでは、シングルトンパターンは何か（単純化）の問題を解決します。

Scalaには、クラスに加えてオブジェクトと呼ばれる最上位の構造があります。シングルトンを取得するためにシングルトンパターンを使用する必要はありません。言語の一部です。

パターンは、何度も何度も見られ、次に説明され、文書化される同様の問題を解決する方法です。したがって、FPはパターンを置き換えるつもりはありません。ただし、FPは新しいパターンを作成し、いくつかの現在の「ベストプラクティス」パターンを「廃止」する可能性があります。

他の人が言ったように、関数型プログラミングに固有のパターンがあります。デザインパターンを取り除く問題は、関数型に切り替えることではなく、言語機能の問題だと思います。

Scalaが「シングルトンパターン」を排除する方法を見てみましょう。クラスの代わりにオブジェクトを宣言するだけです。別の機能であるパターンマッチングは、ビジターパターンの不格好さを回避するのに役立ちます。こちらの比較をご覧ください： Scalaのパターンマッチング=ステロイドのビジターパターン

Scalaは、F＃と同様に、OO機能の融合です。F＃については知りませんが、おそらくこのような機能があります。

クロージャは関数型言語で存在しますが、それらに限定する必要はありません。これらは委任者パターンを支援します。

もう一つの観察。このコードはパターンを実装します。これは非常に古典的であり、非常に要素的であるため、通常は「パターン」とは考えませんが、それは確かです。

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

JavaやC＃などの命令型言語は、これを処理するために本質的に機能的な構造である「foreach」を採用しています。

GoF デザインパターンは、JavaやC ++などのSimula 67の子孫であるOO言語の回避策レシピをコーディングしています。

設計パターンによって扱われる「病気」のほとんどは、次の原因が原因です。

• 静的に型付けされたクラス。オブジェクトを指定しますが、それ自体はオブジェクトではありません。
• 単一のディスパッチへの制限（左端の引数のみがメソッドの選択に使用され、残りの引数は静的型としてのみ考慮されます：動的型がある場合、アドホックアプローチでそれを分類するのはメソッド次第です）。
• 通常の関数呼び出しとオブジェクト指向の関数呼び出しの違い。つまり、オブジェクト指向の関数は、通常の関数が期待される場所では関数の引数として渡すことができず、その逆も同様です。そして
• 「基本型」と「クラス型」の違い。

ソリューションは対応する設計パターンと基本的に同じ方法で構造化されていますが、Common Lispオブジェクトシステムで消えないこれらの設計パターンは1つだけではありません。（さらに、そのオブジェクトシステムはGoFの本に10年以上先行しています。CommonLispは、その本が最初に出版されたのと同じ年にANSI標準になりました。）

関数型プログラミングに関する限り、パターンが適用されるかどうかは、指定された関数型プログラミング言語に何らかのオブジェクトシステムがあるかどうか、およびパターンの恩恵を受けるオブジェクトシステムをモデルにしているかどうかによって異なります。このタイプのオブジェクト指向は、関数型プログラミングとうまく混ざりません。なぜなら、状態の変化が前面と中央にあるからです。

構築および非変更アクセスは関数型プログラミングと互換性があるため、抽象化アクセスまたは構築に関係するパターンを適用できます：ファクトリ、ファサード、プロキシ、デコレータ、ビジターなどのパターン。

一方、状態や戦略などの行動パターンは、機能のOOPには直接適用されない可能性があります。これは、それらが適用されないという意味ではありません。おそらくそれらは、どういうわけか、可変状態をシミュレートするために利用可能なあらゆるトリックと組み合わせて適用されます。

ジェレミー・ギボンズの優れた、しかしやや密度の高い論文をいくつか差し上げたいと思います。「高次データ型汎用プログラムとしての設計パターン」と「イテレーターパターンの本質」（どちらもこちらから入手できます：http：// www。 comlab.ox.ac.uk/jeremy.gibbons/publications/）。

これらはどちらも、他の（オブジェクト指向の）設定で特定の設計パターンによってカバーされる地形を、慣用的な機能構成がどのようにカバーするかを説明します。

タイプシステムを起動しないと、この議論はできません。

関数型プログラミングの主な機能には、ファーストクラスの値、カリー化、不変値などの関数が含まれます。OOデザインパターンがこれらの機能のいずれかに近似していることは明らかではありません。

これは、これらの機能がOOPと同じ問題に対応していないためです...これらは命令型プログラミングの代替手段です。OOPに対するFPの答えは、MLとHaskellの型システムにあります。具体的には、合計型、抽象データ型、MLモジュール、Haskell型クラスです。

しかしもちろん、FP言語では解決されないデザインパターンもまだあります。シングルトンに相当するFPとは何ですか？（シングルトンは一般にひどいパターンであることを少しの間無視します）

タイプクラスが最初に行うことは、シングルトンの必要性を排除することです。

23のリストを調べてさらに削除することもできますが、今は時間がありません。

関数型プログラミングロジックを自然なOO言語に導入するために設計されているGoFデザインパターンは2つだけだと思います。戦略と指揮について考える。他のGoF設計パターンのいくつかは、設計を簡素化して目的を維持するために関数型プログラミングによって変更できます。

本質的に、はい！

• パターンが欠落している機能（高次関数、ストリーム処理など）を回避する場合、その究極性によって構成が容易になります。
• パターンの実装を何度も書き換える必要性自体は、言語の匂いと見なすことができます。

さらに、このページ（AreDesignPatternsMissingLanguageFeatures）は、「パターン/機能」の変換テーブルと、掘り下げようとする場合のいくつかの素晴らしい議論を提供します。

関数型プログラミングは設計パターンを置き換えるものではありません。デザインパターンを置き換えることはできません。

パターンは単に存在します。彼らは時間の経過とともに出現しました。GoFの本はそれらのいくつかを公式化した。開発者が関数型プログラミング言語を使用して新しいパターンが明らかになった場合、それは刺激的なものであり、おそらくそれらについて書かれた本もあるでしょう。

「Functional Programming Patterns- in Scala and Clojure」という名前の新しい2013年の本では、著者Michael.B。Linnは、GoFパターンの多くのケースで比較と代替を提供し、「テール再帰」、「メモ化」、「レイジーシーケンス」などの新しい機能パターンについても説明しています。

この本はAmazonで入手できます。数十年のオブジェクト指向の背景から来たときに、それは非常に有益で励みになりました。

OOPおよびGoFパターンは状態を扱います。OOPは現実をモデル化し、コードベースを現実の所定の要件に可能な限り近づけます。GoFデザインパターンは、原子の現実世界の問題を解決するために特定されたパターンです。彼らは状態の問題を意味論的に扱います。

実際の関数型プログラミングでは状態が存在しないため、GoFパターンを適用しても意味がありません。GoFデザインパターンと同じように機能的なデザインパターンはありません。関数は現実ではなく数学の構造であるため、すべての機能設計パターンは現実とは対照的に人工的です。

関数が「将来の要求」を処理することを本当に困難にする関数パラメーターの一部でない限り、関数は現在の時刻が何であれ常に同じ値を返すため、時間の概念に欠けています。ハイブリッド言語はこれらの概念を組み合わせており、実際の関数型プログラミング言語ではありません。

関数型言語は、物理学の現在の自然な制限という1つの理由だけで上昇しています。今日のプロセッサは、物理法則により、命令の処理速度が制限されています。クロック周波数は停滞していますが、処理コアが拡大しています。そのため、最新のアプリケーションの速度を上げるために、命令の並列処理がますます重要になっています。関数型プログラミングには定義による状態がなく、したがって副作用がないため、関数を安全に並列処理しても安全です。

GoFパターンは廃止されていません。これらは、少なくとも実際の要件をモデル化するために必要です。しかし、関数型プログラミング言語を使用する場合は、それらを同等のハイブリッド言語に変換する必要があります。最後に、永続化を使用する場合、関数型プログラムのみを作成する機会はありません。プログラムのハイブリッド要素には、GoFパターンを使用する必要性が残っています。純粋に機能する他の要素については、状態がないため、GoFパターンを使用する必要はありません。

GoFパターンは実際の関数型プログラミングには必要ないため、SOLIDの原則を適用すべきではないという意味ではありません。SOLIDの原則は、言語パラダイムを超えています。

関数型プログラミングでは、デザインパターンの意味が異なります。実際、より高いレベルの抽象化とHOFがビルディングブロックとして使用されるため、関数型プログラミングではほとんどのOOP設計パターンは不要です。

HOFの原則は、関数を引数として他の関数に渡すことができることを意味します。関数は値を返すことができます。

受け入れられた回答が言ったように、OOPとFPにはすべて特定のパターンがあります。

しかし、私が考えることができるすべてのプログラミングプラットフォームが持っているべきであるほど一般的であるいくつかのパターンがあります。以下は（不完全な）リストです。

• アダプタ。私は、世界と話す必要がないほど包括的（かつ自己実現）である便利なプログラミングプラットフォームについてはほとんど考えられません。そうする場合は、必ずアダプターが必要です。

• ファサード。大きなソースコードを処理できるプログラミングプラットフォームは、モジュール化できる必要があります。プログラムの他の部分のモジュールを作成する場合は、コードの「ダーティ」な部分を非表示にし、優れたインターフェースを提供する必要があります。

• 通訳。一般に、どのプログラムでも、入力の解析と出力の出力の2つだけを実行しています。マウス入力を解析し、ウィンドウウィジェットを印刷する必要があります。したがって、組み込みのインタープリターがあると、プログラムに物事をカスタマイズする追加の力が与えられます。

また、私は典型的なFP言語であるHaskellで、GoFパターンに似ているが名前が異なることに気付きました。私の意見では、FPとOOPの両方の言語で解決すべきいくつかの共通の問題があるため、それらはそこにあったと考えています。

• モナドトランスフォーマーとデコレーター。前者は既存のモナドに能力を追加するために使用され、後者は既存のオブジェクトに能力を追加します。

それぞれのパラダイムは異なる目的を果たしており、このように比較することはできないと思います。

GoFのデザインパターンがすべての言語に適用できるとは聞いていません。これらはすべてのOOP言語に適用できると聞いています。関数型プログラミングを使用する場合、解決する問題の領域はオブジェクト指向言語とは異なります。

ユーザーインターフェイスの作成には関数型言語を使用しませんが、C＃やJavaなどのオブジェクト指向言語の1つを使用すると、この作業が簡単になります。関数型言語を作成している場合は、OOデザインパターンの使用を検討しません。

OOPとFPの目標は異なります。OOPはソフトウェアコンポーネントの複雑さ/可動部分をカプセル化することを目的としており、FPはソフトウェアコンポーネントの複雑さと依存関係を最小限に抑えることを目的としています。

ただし、これら2つのパラダイムは必ずしも100％矛盾するわけではなく、両方の世界から利益を得るために一緒に適用できます。

C＃のような関数型プログラミングをネイティブにサポートしていない言語でも、FPの原則を理解していれば、関数型コードを書くことができます。同様に、OOPの原則、パターン、ベストプラクティスを理解していれば、F＃を使用してOOPの原則を適用できます。使用するプログラミング言語に関係なく、解決しようとする状況と問題に基づいて正しい選択をします。

一部のパターンは、FPをサポートする言語で実装する方が簡単です。たとえば、Strategyはクロージャーをうまく使用して実装できます。ただし、状況によっては、クラスベースのアプローチを使用して戦略を実装することを好む場合があります。たとえば、戦略自体が非常に複雑である場合や、テンプレートメソッドを使用してモデル化する構造を共有する場合などです。

マルチパラダイム言語（Ruby）で開発した私の経験では、FP実装は単純なケースでうまく機能しますが、コンテキストがより複雑な場合は、GoF OOPベースのアプローチの方が適しています。

FPアプローチはOOPアプローチを置き換えるものではなく、それを補完します。

関数型プログラミングの最も重要特性、私見では、あなたが何もなく、使用してプログラミングされていることである表現 -表現内の式内の式の全てが「温めマシンが評価」という最後の、最後の式に評価すること。

オブジェクト指向プログラミングの最大の特徴であるIMHOは、内部状態を持つオブジェクトを使用してプログラミングすることです。純粋な関数に内部状態を含めることはできません。オブジェクト指向プログラミング言語には、物事を起こすためのステートメントが必要です。（関数型プログラミングにはステートメントがありません。）

リンゴとオレンジを比較しています。関数型プログラミングは式を使用したプログラミングであり、オブジェクト指向プログラミングは内部状態を使用したプログラミングであるため、オブジェクト指向プログラミングのパターンは関数プログラミングには適用されません。

あなた自身を支えます。

設計パターンを置き換えてSOLIDとDRYを暴いたと私が主張するのを聞くと、多くの人が悪化します。私はだれでもない。それにもかかわらず、私はコラボレーティブ（製造）アーキテクチャを正しくモデル化し、プロセスを構築するためのルールを、その背後にあるコードと科学とともにWebサイトhttp://www.powersemantics.com/で公開しました。

私の主張は、設計パターンは、製造が「マスカスタマイゼーション」と呼ぶものを達成しようとするものであり、すべてのステップを再形成、再構成、拡張できるプロセスフォームです。このようなプロセスは、コンパイルされていないスクリプトと考えることができます。ここでは（オンラインの）議論を繰り返すつもりはありません。要するに、私の大規模カスタマイズアーキテクチャは、面倒なセマンティクスを一切使用せずにその柔軟性を実現することで、デザインパターンを置き換えます。モデルが上手く機能していることに驚きましたが、プログラマーがコードを書く方法は、製造がどのように共同作業を組織化するかについてのキャンドルを保持していません。

• 製造=各ステップは1つの製品と相互作用します
• OOP =各ステップはそれ自体および他のモジュールと相互作用し、役に立たないオフィスワーカーのようにポイントツーポイントで製品を渡します

このアーキテクチャはリファクタリングを必要としません。複雑さに影響を与える集中化と配布に関するルールもあります。しかし、あなたの質問に答えるために、関数型プログラミングは別の一連の処理セマンティクスであり、1）ソースルーティングが（スクリプト）ドキュメントとして存在し、起動前に書き直すことができ、2）モジュールが簡単かつ動的に追加または削除されます。

OOPは「ハードコードされたプロセス」のパラダイムであり、デザインパターンはそのパラダイムを回避する方法であると言えます。しかし、それがマスカスタマイゼーションのすべてです。設計パターンは動的プロセスを乱雑なハードコードとして具体化します。意味がありません。F＃が関数をパラメーターとして渡すことができるという事実は、関数型言語とOOP 言語が同様に、大規模なカスタマイズ自体を達成しようとする試みを意味します。

読者にとって、スクリプトを表すハードコードはどれほど混乱しますか？コンパイラのコンシューマがそのような機能にお金を払うと思っても、私にはまったくそのような機能は意味のない無駄です。大量カスタマイズのポイントは、Visual Studioを使用するプログラマーにとって動的ではなく、プロセス自体を動的にすることなので、それらは無意味です。

（OCamlのような、クラス、モジュールなどの）高水準の関数型PLは、型の多様性と表現力の点でOOP命令型言語よりも確実に優先されます。抽象化はリークせず、ほとんどのアイデアをプログラムで直接表現できます。したがって、はい、それは設計パターンに取って代わります。そのほとんどは、とにかく機能パターンに比べて途方もなく単純化されています。