f# - F# - oop 設計ではなく純粋な機能設計

Question

3 つのエージェントからなる単純な「マルチエージェント」システムを作成したいと考えています。エージェントごとに、メールボックス プロセッサをカプセル化して作成されたタイプがあります。すべてのエージェントに共通の属性 (position、id など) と関数 (sendMessage、move) があり、エージェントはメールボックス プロセッサの実装 (メッセージの処理方法) によって互いに異なります。さらに、特定のエージェントに固有の他の機能によって異なる場合があります。すべてのエージェントには、メッセージの送信先となる他のエージェントのリストも (その属性の 1 つとして) 含まれている必要があります。これは、F# でメールボックス プロセッサを操作する予定のモデルに基づいた非常に単純なモデルです。

OOP では、これはエージェント インターフェイス (または抽象クラス) を作成することを意味し、特定のエージェントはすべて、このインターフェイスから独自の実装で継承されます。

F# で OOP が可能であることは知っていますが、純粋な機能設計に固執したいと思います。ただし、この場合、OOP が最も適したアプローチのように思えます。関数型 (F#) の設計に関して何かアイデアをいただければ幸いです。ありがとうございました。

Answer 1

まず第一に、F#の関数型スタイルとオブジェクト指向スタイルは実際には矛盾していません。

• 関数型スタイルは、不変型、副作用のない純粋な関数、および判別共用体や関数などの F# データ型の使用で構成されます。

• オブジェクト指向スタイルは、(クラスとインターフェースを使用して) コードをどのように編成するかに重点を置いていますが、変更可能な状態を使用しなくても、コードは純粋に機能することができます。

エージェントベースのシステムでは、エージェントの実装に機能的なスタイルを使用することは理にかなっていますが、クラスを使用してエージェントを編成することは理にかなっています。これはおそらく F# でのベスト プラクティスだと思います ( MSDN の F# エージェントのカプセル化に関する記事も参照してください)。

あなたの例では、エージェントがメッセージを送信する他のエージェントのリストを保持していると言っています。検討する価値のあるいくつかの代替手段があります (インターフェースを避けたい場合):

• F# イベントを公開します ( Event<'T>)。このように、エージェントは単に通知を公開するだけで、他のエージェントのリストを明示的に管理する必要はありません (この設計では、他のタイプのサブスクライバーも許可されます)。

• 関数のリストを保持します。他のエージェントにメッセージを送信する必要がある場合は、基本的に単一のメソッドを持つインターフェースのみが必要です。その場合、 などの関数のリストを保持できます
  Message -> unit。

私は通常、イベントを公開することを好みます。この方法では、システムの結合が緩くなり、さまざまな方法でエージェントをより簡単に構成できます (構成するために特定のインターフェイスを実装する必要はありません)。この記事では、より高いレベルの観点からエージェント ベースのアーキテクチャについて説明しており、こちらも役立つ可能性があります。

Answer 2

なぜあなたは純粋な機能的なデザインに固執したいのですか？F＃では、機能とOOPの原則を明確に組み合わせることができます。私は両方のメカニズムを利用して、言語の力を活用します。

機能面とOOP面を組み合わせたい場合は、オブジェクトを不変にすることから始めます。したがって、オブジェクトを使用していますが、機能的なパラダイムになっています。

Answer 3

あなたはOODを思いついたのですが、OOPソリューションが最も自然に見えるのは驚くべきことですか？

プロセスとデータ変換を念頭に置いて設計記述を書き直した場合、それは当然FP設計として外れ、多くのクラスがあるOOでは本当に厄介に聞こえます。現状では、データのタイプやどのような変換を行う必要があるかについての説明はほとんどありません。一見すると、エージェントは、メールボックス、メッセージハンドラー（またはメッセージハンドラーのリスト）、および接続する他のエージェントのメールボックスのリストの3つの引数の関数であると言えます。将来のディスパッチがメッセージに基づいている場合、メッセージハンドラーは2つの引数の関数です。メッセージ、およびメールボックスのリスト。