「混合」言語での設計：オブジェクト指向設計または関数型プログラミング？

過去数年間で、私が使用したい言語はますます「機能的」になりつつあります。現在、C＃、F＃、Scalaなどの「ハイブリッド」言語を使用しています。ドメインオブジェクトに対応するクラスを使用してアプリケーションを設計し、これによりコーディングがより簡単に、より正確に、より安全になる機能機能を使用します（特にコレクションの操作時または関数の受け渡し時）。

ただし、パターンを設計する場合、2つの世界は「衝突」します。私が最近直面した具体的な例は、Observerパターンです。アイテムが作成または変更されたときに、プロデューサーに他のコード（「消費者/オブザーバー」、たとえばDBストレージ、ロガーなど）に通知してほしい。

私は最初に次のように「機能的に」それをしました：

producer.foo(item => { updateItemInDb(item); insertLog(item) })
// calls the function passed as argument as an item is processed

しかし、私は今、もっと「OO」アプローチを使用すべきかどうか疑問に思っています。

interface IItemObserver {
  onNotify(Item)
}
class DBObserver : IItemObserver ...
class LogObserver: IItemObserver ...

producer.addObserver(new DBObserver)
producer.addObserver(new LogObserver)
producer.foo() //calls observer in a loop

2つのアプローチの長所と短所はどれですか？かつてFPの第一人者が、デザインパターンは言語の制限のためだけにあると言ったことを聞いたことがあり、それが関数型言語にはほとんどない理由です。たぶん、これはその例でしょうか？

編集：私の特定のシナリオでは、私はそれを必要としませんが、..機能的な方法で「観測者」の削除と追加をどのように実装しますか？（つまり、パターンのすべての機能をどのように実装しますか？）たとえば、新しい関数を渡すだけですか？

これは、呼び出し元オブジェクトの関心の境界外でタスクを実行するという概念を伝える2つの異なるアプローチの良い例です。

この例では機能的なアプローチを採用する必要があることは明らかですが、一般的には、呼び出されたオブジェクトが示す動作がどれほど複雑であるかに大きく依存します。本当に複雑な動作の問題であり、よく似たロジックを頻繁に再適用し、関数ジェネレーターを使用してそれを明確に表現できない場合は、おそらくクラス構成または継承に行きたいでしょう。アドホックベースで既存の動作を再利用および拡張するためのもう少しの自由があります。

しかし、私が観察したパターンの1つは、通常、開発者は最初は機能的なアプローチを採用し、よりきめ細かい動作が必要になった場合にのみクラスベースのアプローチを採用することを決定するというものです。たとえば、Djangoが機能ベースのビュー、テンプレートローダー、テストランナーからクラスベースのビューに変わったのは、メリットと要件が明らかになった後ですが、それ以前ではないことを知っています。

機能バージョンは、はるかに短く、保守しやすく、読みやすく、一般的に、考えられるほぼすべての点で非常に優れています。

すべてではありませんが、多くのパターンは、オブザーバーなどのOOPの機能の不足を補うことです。これらは機能的にはるかに優れたモデルです。

あなたの「FPの第一人者」は部分的に正しいです。多くのオブジェクト指向パターンは、機能的なことを行うためのハッキングです。（これが、せいぜい疑わしいと思われるFP言語が少ない理由であるという彼の主張です。）ObserverおよびStrategyパターンは、一流の機能をエミュレートしようとしています。訪問者パターンは、パターンマッチングをシミュレートするためのハックです。あなたIItemObserverは単なる変装の機能です。アイテムを受け取る他の機能とは違うふりをしても、何も買えません。

オブジェクトはデータ抽象化の一種です。このホワイトペーパーは、そのトピックに光を当てるのに役立ちます。オブジェクトは有用ですが、すべてに適しているわけではないことを認識することが重要です。二分法はありません。適切なジョブに適切なツールを選択するだけの問題であり、関数型プログラミングではオブジェクトを放棄する必要はありません。それはさておき、関数型プログラミングは関数を使用するだけではありません。副作用と突然変異を最小限に抑えることも重要です。

私は関数型言語が苦手なので、質問に本当に答えることはできません。しかし、私はあなたが持っているものが機能している限り、アプローチについてそれほど心配するべきではないと思います。私が理解していることから、将来リスナーを追加しないか、実行中にリスナーを変更しない限り、ここでオブザーバーパターンをスキップできます。

OO言語の「制限」をデザインパターンが補うことに同意しません。OOP機能をうまく利用するためにあります。多態性と継承は機能であり、制限ではありません。設計パターンはこれらの機能を利用して、柔軟な設計を促進します。OOで完全に非OOプログラムを作成できます。細心の注意を払って、FPを模倣した、状態を持たないオブジェクトを含むプログラム全体を作成できます。