大まかに言って、FPとOOPには、複雑な構造を表現し、プログラムを互いに結合できる小さな断片にカプセル化するという類似の機能があります。
これら2つの「哲学」の最大の違いは、データとデータ操作の関係です。
OOPの基本的な原則は、それらに対するデータと操作が強く関連しているということです。オブジェクトにはデータが含まれ、データに対する操作の実装です。 これは、インターフェイスを介して他のオブジェクトからすべてを隠します-応答するメソッドまたはメッセージのセット。 したがって、抽象化の中心的なモデルはデータそのものであり、インターフェイスの形で小さなAPIの背後に隠されています。
OOPアプローチでは、プログラマは新しいオブジェクトを作成し、メソッドを追加して既存のオブジェクトを拡張します。
FPの主な教義は、データは関数とはあまり関係がないということです。 同じデータセットに対して異なるアクションを実行でき、抽象化の中心的なモデルはデータ構造ではなく機能です。 関数は実装を隠し、言語の抽象化は関数と通信します。
FPアプローチでは、プログラマーは新しい関数を作成します。
クマとワニの間の決闘では、決定的な要因は地形です。
それで、一方が他方よりも好ましいのはいつですか？ ブログは実用的な実装に専念しているため、コードについて機械的に話したり、あらゆる種類の実用的なことを考えたり、リソースと時間の不足でやりすぎたりする必要がある状況でビジネスコードを書く能力などの理論的な構造を破棄します。
2つのモデルのいずれかがビジネス環境で勝つことができますか？ 私が自分自身でエスプレッソを作りながら慎重に考えて......
もちろん、機能モデルはビジネスプログラミングを支配します。 驚き？ Java、C ++、C＃、Rubyなどの言語のみを検討する場合は驚きです。
考えてみると、これはすべてOOPです。データベースとSQLにアクセスするための薄い層であり、実際には関数型言語です。 組み込みのPL / SQLプロシージャを使用してデータベースを管理することは可能ですが、これによりボトルネックが発生し、通常は価値がありません。
リレーショナルデータベースの主な利点は、将来発生する要件を処理できることです。 新しいレポートが必要なときは、それらを書くだけです。 さまざまなアプリケーションが同じ方法でデータベースにアクセスできます。 制約は、すべてのアプリケーションで機能するようにプログラムで設定できます。
後戻りすると、データベースは大きなデータ構造であり、アプリケーションはそれらの操作のセットであることがわかります。 ビジネスアプリケーションの中心となるのは、大規模で機能的なデータベースです。
それでも、アプリケーションのオブジェクトをつかみます。 シンプルなファッションフォロー？ または、アプリケーションで行う必要があることと、データベースを操作するときに行う必要があることとの間に根本的な違いがありますか？
答えは、OOPで何をすべきか、データベースで何をすべきかです。
優れたOOPアーキテクチャにより、物事の相互関係を簡単に変更できます。 カプセル化により、部品の相互作用を簡単に変更できます。 確かに、OOPでは新しいアクションを追加するのはそれほど簡単ではありません。
しかし、新しいビジネスルールをサポートするためにリファクタリングされた、注文を出すためのビジネスプロセスがある場合、OOPはその栄光をすべて引き出します。 変更について知る必要のないコードの部分は、変更について知る必要のある部分から分離されています。
一方、適切に設計されたデータベースを使用すると、新しいクエリと操作を簡単に追加できます。 別の観点からデータを確認したり、新しいデータの更新を追加することができます。 クライアントアプリケーションは、インデックス作成やパフォーマンスなどから隔離されています。
コミュニケーションの変更は困難です。 管理構造を変更し、1人のマネージャーから多対多のレポートシステムに移行すると、多くのアプリケーションが破損します。
したがって、ビジネスアプリケーションに存在する必要があるすべてのものをカードに書き留めると、長期的でめったに変化しない関係を表すものがデータベースに行き、進化し変化する操作を表すものがアプリケーションに行きます。
「カード」（アプリケーション要素）のセットは、通常、データベース要素のセットの4倍です。 すべてが変化しており、ビジネスは学び、成長し、発展しなければなりません。
では、FP-機能的なスタイルで記述されたコードはどうでしょうか？ 比較的一定のデータセットを操作する一連の操作としてのOOPプログラムの単純な編成はどうでしょうか。
それと別のものの両方が許容されますが、優先順位について-通信の期間にわたって常に考える必要があります。 何かが変更される可能性が低い場合は、同時に異なる変更が機能します-FPスタイルで配置することをお勧めします。 何かが頻繁に変更される場合は、OOPの形式で配置することをお勧めします。
各マネージャーが複数のレポートを持つことができ、各レポートにマネージャーが1つしかない場合、そのような操作は、マネージャーオブジェクトが秘密に操作を委任するAPIの背後に隠れることはほとんどありません。 このようなことは、操作が実行されるデータの形式で作成する方が簡単です。 ただし、送料に関するルールは変更される可能性が高いため、プログラムの残りの部分をそこから隔離するために、より厳しくカプセル化する必要があります。
優れたプログラムはいくつかの異なるタスクを実行する必要があるため、優れたプログラムは両方のスタイルを使用して作成されます。
OOPを使用する場合とFPを使用する場合
All Articles