C＃/ OOPでは貧弱なドメインモデルが悪いと考えられますが、F＃/ FPでは非常に重要なのはなぜですか？

でブログの記事楽しさと利益のためにF＃上、それは言います：

機能設計では、動作をデータから分離することが非常に重要です。データ型は単純で「ダム」です。そして、別に、これらのデータ型に作用する多くの関数があります。

これは、動作とデータを組み合わせることを意図したオブジェクト指向設計の正反対です。結局のところ、それはまさにクラスです。実際にオブジェクト指向の設計では、振る舞い以外は何もありません。データはプライベートであり、メソッドを介してのみアクセスできます。

実際、OODでは、データ型の周囲に十分な動作がないことは悪いことと見なされ、「貧血領域モデル」という名前さえあります。

C＃では、F＃から借用し続け、より機能的なスタイルのコードを記述しようとしているようです。なぜデータ/動作を分離するという考えを借りず、それを悪いと考えるのでしょうか？定義がOOPを伴わないというだけなのでしょうか、それともC＃で悪いのに何らかの理由でF＃に適用されない（そして実際には逆になる）具体的な理由がありますか？

（注：私は、ブログ投稿のどちらかの意見に同意しない個人ではなく、善/悪の意見を変える可能性のあるC＃/ F＃の違いに特に興味があります）。

FPがこれを目的とし、C＃OOPが目的としない主な理由は、FPでは参照の透明性に焦点が当てられているためです。つまり、データが関数に入り、データが出てきますが、元のデータは変更されません。

C＃OOPには、オブジェクトの管理を委任する責任の委任という概念があります。したがって、オブジェクトの内部を変更する必要があります。

FPでは、オブジェクトの値を変更したくないため、関数をオブジェクトに埋め込むことは意味がありません。

さらにFPでは、C＃OOPが許可するよりもはるかに一般化された関数を許可する、より高い種類の多態性があります。この方法では、any aで機能する関数を書くことができるため、データのブロックに埋め込むことは意味がありません。それはメソッドを緊密に結合し、その特定の種類のものでのみ動作しaます。そのような振る舞いはすべてC＃OOPで一般的であり、とにかく関数を抽象化する能力は一般的にありませんが、FPではトレードオフです

C＃OOPの貧血ドメインモデルで見た最大の問題は、DTO xがあるためにコードが重複することと、4人の異なるユーザーが他の実装を見なかったためにアクティビティfをDTO xにコミットする4つの異なる関数があることです。メソッドをDTO xに直接配置すると、4人全員がfの実装を確認して再利用します。

C＃OOPの貧血データモデルはコードの再利用を妨げますが、FPの場合はそうではありません。1つの関数が非常に多くの異なるタイプにわたって一般化され、その関数は、 C＃で1つのDTOを記述します。

以下のようなコメントで指摘し、型推論は、FPは、このような重要な多型を許可するに依存している利点の一つであり、具体的に、あなたはこのバックトレースすることができますヒンドリーミルナーのアルゴリズムW型推論と型システムを、C＃OOP型システムでのこのような型推論は、徹底的な検索が必要なために制約ベースの推論が追加されるとコンパイル時間が非常に長くなるため、回避されました。詳細はこちら：https : //stackoverflow.com/questions/3968834/generics-why -この場合コンパイラの推論型引数をカント

C＃/ OOPでは貧弱なドメインモデルが悪いと考えられますが、F＃/ FPでは非常に重要なのはなぜですか？

あなたの質問には、あなたが得る答えの有用性を制限する大きな問題があります：あなたは、F＃とFPが類似していることを暗示している/仮定しています。FPは、記号用語の書き換え、動的および静的を含む言語の巨大なファミリーです。静的に型付けされたFP言語の中でも、OCamlやSMLの高次モジュール（F＃には存在しない）などのドメインモデルを表現するためのさまざまなテクノロジがあります。F＃はこれらの関数型言語の1つですが、無駄のないことで特に注目に値し、特に高階のモジュールや高種類の型を提供しません。

実際、ドメインモデルがFPでどのように表現されるかを説明することはできませんでした。ここでのもう1つの答えは、Haskellでどのように行われるかについて非常に具体的に述べており、Lisp（すべてのFP言語の母）、ML言語ファミリ、またはその他の機能言語にはまったく適用できません。

なぜデータ/動作を分離するという考えを借りず、それを悪いと考えるのでしょうか？

ジェネリックは、データと動作を分離する方法と見なされる場合があります。ジェネリックは、関数型プログラミング言語のMLファミリーに由来し、OOPの一部ではありません。もちろん、C＃にはジェネリックがあります。そのため、C＃はデータと動作を分離するという考え方を徐々に取り入れていると主張することができます。

定義がOOPに適合しないというだけですか、

OOPは根本的に異なる前提に基づいているため、データと動作を分離するために必要なツールは提供されません。すべての実用的な目的のために、製品と合計のデータ型が必要で、それらを介してディスパッチします。MLでは、これはユニオンとレコードタイプ、およびパターンマッチングを意味します。

私がここで与えた例をチェックしてください。

または、C＃で悪いのに、何らかの理由でF＃に適用されない（実際には逆になる）という具体的な理由はありますか？

OOPからC＃へのジャンプに注意してください。C＃は、他の言語ほどOOPについて純粋ではありません。.NET Frameworkには、ジェネリック、静的メソッド、さらにはラムダがいっぱいになりました。

（注：私は、ブログ投稿のどちらかの意見に同意しない個人ではなく、善/悪の意見を変える可能性のあるC＃/ F＃の違いに特に興味があります）。

C＃にはユニオン型とパターンマッチングがないため、ほとんど実行できません。あなたが持っているのはハンマーだけである場合、すべてが釘のように見えます...

ビジネスアプリケーションでは、不変の値のパターンマッチングは、すべての可能なケースを確実にカバーするために優れているため、データを非表示にしたくないことが多いと思います。ただし、複雑なアルゴリズムまたはデータ構造を実装する場合は、実装の詳細を非表示にして、ADT（代数データ型）をADT（抽象データ型）に変換することをお勧めします。