「関数とデータ間の密結合」が悪いのはなぜですか？

この引用は、「Clojureの喜び」のp。32、しかし誰かが先週の夕食で私に同じことを言って、私はそれを他の場所でも聞いた：

[A]オブジェクト指向プログラミングの欠点は、関数とデータの間の密結合です。

アプリケーションで不要な結合が悪い理由を理解しています。また、オブジェクト指向プログラミングであっても、可変状態と継承を避けるべきだと言っています。しかし、なぜクラスに関数を貼り付けるのが本質的に悪いのかはわかりません。

つまり、クラスに関数を追加すると、Gmailでメールにタグを付けたり、ファイルをフォルダーに貼り付けたりするように思えます。それはあなたが再びそれを見つけるのを助ける組織的なテクニックです。いくつかの基準を選択してから、同じようなものをまとめます。OOP以前は、プログラムはファイル内のメソッドのかなり大きな袋でした。つまり、関数をどこかに配置する必要があります。整理してみませんか？

これが型に対するベール攻撃である場合、関数への入力および出力の型を制限することは間違っていると言うだけではありませんか？それに同意できるかどうかはわかりませんが、少なくともプロとコンタイプの安全性に関する議論には精通しています。これは、ほとんど別の懸念のように思えます。

確かに、時々それを間違え、機能を間違ったクラスに置きます。しかし、他の間違いと比較すると、これは非常に小さな不便さのようです。

そのため、Clojureには名前空間があります。OOPのクラスに関数を貼り付けることは、Clojureの名前空間に関数を貼り付けることとどのように異なりますか？クラスの関数は、必ずしもそのクラスのメンバーだけで動作するとは限らないことを忘れないでください。java.lang.StringBuilderを見てください。これは、すべての参照型で動作するか、オートボクシングを通じて、すべての型で動作します。

PSこの引用は、私が読んだことのない本を参照しています：Multiparadigm Programming in Leda：Timothy Budd、1995。

理論的には、緩やかな関数とデータの結合により、同じデータで機能する関数を追加するのが簡単になります。欠点は、データ構造自体を変更することがより困難になることです。そのため、実際には、適切に設計された機能コードと適切に設計されたOOPコードは、非常に類似したレベルの結合を持っています。

データ構造の例として、有向非巡回グラフ（DAG）を取り上げます。関数型プログラミングでは、繰り返しを避けるために抽象化が必要なので、ノードとエッジの追加と削除、特定のノードから到達可能なノードの検索、トポロジカルソートの作成などの機能を備えたモジュールを作成します。コンパイラーがデータを強制していなくても、データに効果的に密結合しています。難しい方法でノードを追加できますが、なぜ追加したいのですか？1つのモジュール内の凝集性により、システム全体の密結合が防止されます。

逆に、OOP側では、DAGオブジェクトをパラメーターとして渡して、基本的なDAG操作以外の機能を個別の「ビュー」クラスで実行します。DAGデータを操作するビューを必要な数だけ追加するのは簡単で、関数型プログラムで見られるのと同じレベルの関数データの分離を作成します。コンパイラは、すべてを1つのクラスに詰め込むことを妨げませんが、同僚はそうします。

プログラミングパラダイムを変更しても、抽象化、結合、結合のベストプラクティスは変更されません。コンパイラーが実施するのに役立つプラクティスが変更されるだけです。関数型プログラミングでは、関数とデータの結合が必要な場合は、コンパイラーではなく紳士の同意によって強制されます。OOPでは、モデルビューの分離は、コンパイラーではなく紳士の同意によって実施されます。

まだ知らなかった場合は、この洞察が必要です。オブジェクト指向とクロージャーの概念は、同じコインの両面です。とはいえ、閉鎖とは何ですか？周囲のスコープから変数またはデータを取得して関数内でバインドするか、オブジェクト指向の観点から、たとえばコンストラクタに何かを渡すときに効果的に同じことを行い、後でそれを使用できるようにしますそのインスタンスのメンバー関数のデータ。しかし、周囲のスコープから物を取り出すのは良いことではありません-周囲のスコープが大きいほど、これを行うのはより邪悪です（実際には、作業を完了するにはいくつかの悪が必要です）。グローバル変数を使用すると、これが極端になり、プログラム内の関数がプログラムスコープで変数を使用します。があるグローバル変数が悪である理由に関する他の場所での良い説明。

オブジェクト指向の手法に従う場合、プログラム内のすべてのモジュールが特定の最小レベルの悪を持っていることを基本的にすでに受け入れています。プログラミングに機能的なアプローチをとる場合、プログラムにはクロージャーの悪が含まれない理想的なものを目指していますが、一部のモジュールにはまだあるかもしれませんが、オブジェクト指向はオブジェクト指向よりはるかに少ないでしょう。

それはオブジェクト指向の欠点です-クロージャー標準（プログラミングの壊れたウィンドウ理論の一種）を作成することにより、この種の悪、データの機能への結合を促進します。

唯一のプラス面は、最初に多くのクロージャーを使用することを知っていた場合、OOは少なくとも平均的なプログラマーが理解できるようにそのアプローチを整理するのに役立つアイデア的なフレームワークを提供することです。特に、閉じられる変数は、関数のクロージャーで暗黙的に取得されるのではなく、コンストラクターで明示されます。多くのクロージャを使用する関数型プログラムは、同等のオブジェクト指向プログラムよりも多くの場合、よりわかりにくいですが、必ずしもエレガントではありません:)

型結合についてです：

オブジェクトに組み込まれてそのオブジェクトで機能する関数は、他のタイプのオブジェクトでは使用できません。

Haskellでは、型クラスに対して機能する関数を作成します。したがって、関数が機能する特定のクラスのタイプである限り、特定の関数が機能できるオブジェクトにはさまざまなタイプがあります。

独立型の関数を使用すると、タイプAの内部で動作するように関数を書くことに集中した場合に得られない分離が可能になります。それ以外の場合は、タイプBインスタンスまたはタイプCインスタンスで使用するのに十分一般的です。

Javaおよび同様のOOPの化身では、インスタンスメソッドは（無料の関数や拡張メソッドとは異なり）他のモジュールから追加できません。

インスタンスメソッドによってのみ実装できるインターフェイスを検討する場合、これはより多くの制限になります。異なるモジュールでインターフェースとクラスを定義してから、3番目のモジュールのコードを使用してそれらをバインドすることはできません。Haskellの型クラスのような、より柔軟なアプローチでそれが可能になります。

オブジェクト指向は、基本的に手続き型データ抽象化（または直交問題である副作用を取り除く場合は機能データ抽象化）に関するものです。ある意味では、Lambda Calculusは、機能データの抽象化のみを提供するため、最も古く、最も純粋なオブジェクト指向言語です（関数以外に構造を持たないため）。

単一のオブジェクトの操作のみが、そのオブジェクトのデータ表現を検査できます。同じタイプの他のオブジェクトでさえそれを行うことはできません。（これがオブジェクト指向データ抽象化と抽象データ型の主な違いです。ADTを使用すると、同じ型のオブジェクトは互いのデータ表現を検査でき、他の型のオブジェクトの表現のみが非表示になります。）

これが意味することは、同じタイプの複数のオブジェクトが異なるデータ表現を持つ場合があるということです。まったく同じオブジェクトでも、異なる時間に異なるデータ表現を持つ場合があります。（たとえば、Scalaでは、MapsとSetsは要素の数に応じて配列とハッシュトライを切り替えます。これは、定数が非常に小さいため、配列内の線形検索が検索ツリーの対数検索よりも高速であるためです。 ）

オブジェクトの外側からは、そのデータ表現を知ることはできません。これは、密結合の反対です。

データと関数の間の密結合は悪いものです。お互いに独立して変更できるようにしたいので、密結合はこれを難しくします。

関数に表示されるさまざまなデータが関数の変更を必要とせず、同様に、それらの関数の変更をサポートするために操作中のデータを変更することなく関数を変更できるようにする必要があります。