おそらく、オブジェクト指向のパラダイムを使用する最大の約束は、コードの再利用です。これが達成されたという論争もある。なぜ達成されたのか（達成されなかったのか）？

OOPが定義するとおりにコードを再利用し、プロジェクトの生産性を高めますか？

それとも管理しやすいですか？または保守が簡単ですか？または、より品質が高いですか？

おそらく、コードの再利用は良いことですが、この目標を達成する方法はいくつかあります。問題は、OOPが提供するコード再利用の方法です。良かった？オブジェクト指向、サブクラス化、ポリモーフィズムなどよりも優れたコード再利用を実現する方法はありますか？より良い方法は何ですか？なんで？

OOPの再利用や他のパラダイムの再利用の経験を教えてください。

コードの再利用は非常に良い考えです。 素晴らしいものではありません。

私は約30年間のソフトウェアエンジニアリングから「再利用」しようとする視点を持っています。

70年代前半に構築した1つのOSの設計を、70年代後半に構築した別のOSに再利用したことを発見した後、80年代に研究トピックとして「コード再利用」の調査を開始しました。

コードの再利用の良い点は、神に誠実な既存のコードを時々再利用できることです。しかし、世界はコードでいっぱいです。欲しいものをどうやって見つけることができますか？これが私がリユースの呪いと呼ぶものです：

私はサンタクロースです（オープンソースも可）。10億個のソフトウェアコンポーネントが入っています。それらのいずれかを使用できます。

幸運を選ぶ。

再利用の問題をうまく解決するには：

• 再利用者は何らかの方法で必要なものを指定する必要があります（機能、パフォーマンス、ターゲット言語、環境の仮定など）
• これらの潜在的な基準によってさまざまな方法でインデックス付けされた「再利用可能な」コードのライブラリが必要です
• 候補要素を選択するための何らかのメカニズムが存在する必要があります（10億個の要素では、それらをすべて個人的に見ることはできません）
• 選択した候補者が仕様からどれだけ離れているかを特徴付ける方法が必要です
• 再利用者が選択した再利用可能なコードを変更できるようにするための通常のプロセスが存在する必要があります（OOPの最大の貢献は、既存のコンポーネント/オブジェクトをそのスロットをオーバーライドして編集できることです。OOPは他のヘルプを提供しません）。
• これはすべて、単に再コーディングするよりも明らかに安くなければなりません

長年にわたって発見されてきたほとんどのことは、コードを再利用可能にするために、その目的のために設計する必要があるか、暗黙的な仮定が多すぎることです。最も成功したコード再利用ライブラリは、実際にはかなり小さいものです。おそらく、ライブラリとフレームワークは「再利用可能な」コードであり、非常に成功しています。JavaとC＃が成功するのは、かなり優れたコンピューター言語であるためではなく、適切に設計され、実装され、文書化された巨大なライブラリーがあるためです。しかし、人々はライブラリのソースコードを見ません。よく文書化されたAPIを呼び出すだけです（一般的に使用できるように設計されています）。

コードの再利用が行われていない（OOPでもない）ことは、システムをコーディングする能力を大幅に向上させることです。

主な欠陥は、コードに組み込まれた仮定が多すぎるため、あらゆる種類のコードの再利用が根本的に制限されることだと思います。コードを小さくすれば、仮定を最小限に抑えることができますが、ゼロから構築するコストはそれほど大きくなく、再利用による効果はありません。コードチャンクを巨大にすると、新しいコンテキストではほとんど役に立たなくなります。ガリバーのように、それらは数百万の小さなひもでビーチに結び付けられており、すべてをカットする余裕はありません。

取り組むべきことは、知識を再利用してコードを構築することです。これを行うことができれば、その知識を適用して必要なコードを作成し、現在の一連の仮定を処理できます。

これを行うには、ソフトウェアコンポーネントを特徴付けるのと同じ仕様機能が必要です（まだ何をしたいかを言わなければなりません！）。ただし、この「構築」知識を仕様に適用して、必要なコードを生成します。

コミュニティとして、私たちはまだこれが得意ではありません。しかし、人々は常にそれを行います。なぜ自動化できないのですか？多くの研究があり、これは多くの状況でそれができることを示しています。

これに必要な重要な機械の1つは、「コンポーネントの説明」（これらは単なる正式なドキュメントであり、プログラミング言語のように解析できる）を受け入れ、プログラム変換を適用するための機械ツールです。

コンパイラはすでにこれを行っています：-}そして、彼らは取り組む問題のクラスが本当に得意です。

コード生成を伴うUMLモデルは、これを行う1つの試みです。あまり良い試みではありません。ほとんどのUMLモデルで言われていることは、「このようなデータがあります」ということです。機能が省略されている場合、実際のプログラムを生成するのはかなり困難です。

DMSと呼ばれるツールである実用的なプログラム変換システムを構築しようとしています。プログラム変換を、コードを生成するための抽象的な仕様ではなく、それをクリーンアップするためのレガシーコードに適用することにより、かなり注意散漫になりました。（これらは要約でも同じ問題です！）。（そのようなツールを構築するには多くの時間がかかります;私はこれを15年間やってきましたが、その間にあなたは食べなければなりません）。

ただし、DMSには、上記で説明した2つの重要な特性があります。任意の形式仕様を処理する機能と、「コード生成知識」を変換としてキャプチャし、要求に応じて適用する機能です。そして驚くべきことに、いくつかの特別な場合、仕様からかなり興味深いコードを生成します。DMSは、主に実装を生成するためにそれ自体を使用して構築されます。これにより、少なくとも（知識）再利用の約束のいくつか、つまり非常に大きな生産性の向上が達成されました。私は約7人の技術者のチームを持っています。おそらく1〜2 MSLOCのDMSの「仕様」を作成しましたが、10MSLOCの生成コードがあります。

要約： 生成知識の再利用はコードの再利用ではなく勝ちです。

コードの再利用はOOPで実現されますが、関数型プログラミングでも実現されます。コードのブロックを取得し、他のコードで呼び出し可能にすると、他の場所でこの機能を使用できるようになり、コードが再利用されます。

このタイプのコードの再利用により、コードがより管理しやすくなります。これは、この1つの呼び出し可能ブロックを変更すると、呼び出されるすべての場所が変更されるためです。この結果により、品質と可読性も向上したと思います。

OOPが単にコードの再利用を提供するために存在するかどうかはわかりません。OOPは、オブジェクトと対話し、データ構造の詳細を抽象化する方法の1つとして捉えています。

Wikpediaから：

オブジェクト指向プログラミングには、1960年代にまでさかのぼることのできるルーツがあります。ハードウェアとソフトウェアがますます複雑になるにつれて、管理性がしばしば懸念事項になりました。研究者は、ソフトウェアの品質を維持する方法を研究し、オブジェクト指向プログラミングを開発して、プログラミングロジックの個別の再利用可能なユニットを強調することにより、共通の問題に対処しました[要出典]。このテクノロジーは、プロセスではなくデータに焦点を当てており、各インスタンス（「オブジェクト」）が独自のデータ構造（「メンバー」）を操作するために必要なすべての情報を含む自給自足モジュール（「クラス」）で構成されるプログラムを使用しています。これは、特にデータではなくモジュールの機能に重点を置いていた長年にわたって支配的だった既存のモジュール式プログラミングとは対照的ですが、コードの再利用のために同様に提供されます。プログラミングロジックの自給自足の再利用可能なユニット。リンクされたモジュール（サブルーチン）を使用してコラボレーションを可能にします。この従来のアプローチは、今もなお続いており、データと動作を別々に考慮する傾向があります。

はいといいえ

コードの再利用は、多くの異なるアクティビティの包括的な用語です。

1. 単一プロジェクト内でのコードの再利用。OOはこれに完全に適しており、適切に設計されたアプリケーションは、モデル化された世界の関係を密接にマッピングするため、重複コードを可能な限り回避します。ただし、OO以前のテクノロジーでも同じことを達成できると主張できますが、これは事実ですが、OOの方が多くの点で便利です。
2. サードパーティのライブラリこれは、OOの有無に関係なく同様に機能するようです。
3. クロスパーパスコードの再利用 OOの最大のコード再利用の約束は、あるアプリケーション用に作成されたコードを、後で特別に設計されていない別のアプリケーション用に再利用できることです。これは、OOの概念が上位の管理オフィスのドアを通過し、OOがそれを完全に達成できなかったときの大流行でした。目的はオブジェクト指向設計の重要な側面であり（おそらくすべての手続き型コードですが、それは私の理論にすぎません）、コードを再利用しようとする試みはメンテナンス障害で終わったことが判明しました。（古いフレームワークのよく知られているアンチパターンは誰も変更することを敢えてせず、その友人である、すべてのアプリのためのわずかに異なるフレームワークは通常ここに由来します。）

長い回答を投稿しますが、なぜですか？ウディ・ダーハンは、私よりもずっと上手く説明しています。

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

これが投稿の始まりです。

この業界は再利用に夢中です。

より多くのコードを再利用すれば、すべてが良くなるという信念があります。

オブジェクト指向のすべてのポイントは再利用であるとまで言っている人もいます。カプセル化は大きなことでした。その後、コンポーネント指向が再利用を実現するはずでした。どうやらそれはうまくうまくいかなかったようです。なぜなら、ここで私たちは今、サービス指向に対する再利用の希望を固定しているからです。

パターンの本全体が、その日のオリエンテーションで再利用を達成する方法について書かれています。サービスは、エンティティサービスやアクティビティサービスから、プロセスサービスやオーケストレーションサービスに至るまで、あらゆる方法で分類されています。サービスの構成は、再利用と再利用可能なサービスの作成の鍵として宣伝されています。

汚い小さな秘密を教えてください：

再利用は誤りです

関数型プログラミングは、コードを再利用する良い方法です。

多くのプログラムには、繰り返されるコード構造があります。このため、OOPの世界ではいくつかの設計パターンが使用されていますが、これは関数型プログラミング言語の再帰関数とパターンマッチングによって実現できます。詳細については、「実世界の関数型プログラミング」の最初の章を参照してください。

OOPの深い継承は多くの場合誤解を招く可能性があると思います。クラスがあり、密接に関連するメソッドの多くが異なるファイルに実装されています。ジョー・アームストロングがOOPについて言ったように：

オブジェクト指向言語の問題は、それらが持ち歩くこの暗黙の環境をすべて持っていることです。バナナが欲しかったのですが、バナナとジャングル全体を保持しているゴリラが手に入りました。

高次機能は、それが再利用などをコーディングに来るときにも非常に便利ですmapし、foldrそれがGoogleのための基盤であるMapReduceの。

非同期メッセージパッシングは、複雑なソフトウェアを整理するための優れた方法でもあり、コンピューターサイエンティストによっては、オブジェクトは、Tellのように非同期で互いに通信すると想定されていると述べています。これについての詳細は、 オブジェクト指向プログラミング：間違ったパス？たジョー・アームストロングが引用されています。

私はオブジェクト指向プログラミングが何であるか疑問に思い始めました。そして、Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと思いました。それから、私の論文のスーパーバイザーは「しかし、あなたは間違っています、Erlangは非常にオブジェクト指向です」と言いました。彼は、オブジェクト指向言語はオブジェクト指向ではないと述べました。私はこれを信じるかどうかなりわからないけれども、私は、と思うかもしれないが、オブジェクト指向プログラミングの3つの教義は、それがに基づいているということなので、Erlangのは唯一のオブジェクト指向言語であるかもしれないメッセージパッシングあなたが持っていることを、隔離オブジェクトとの間を多型を持っている。

イベントドリブンシステムやErlangのような非同期メッセージパッシングもシステムを分離する非常に良い方法であり、複雑なシステムでは疎結合が重要です。十分に分離されたシステムを使用すると、実行中にシステムを進化させることができます。異なるノードで実行することもできます。Unibetはこれについて素晴らしいプレゼンテーションを行いました：ドメインイベント駆動型アーキテクチャ

ただし、コードの再利用のほとんどは、ライブラリとフレームワークを使用して行われると思います。

謙虚なunixパイプは、コードの再利用のために、他のどんなものよりも多くのことを行ってきました。オブジェクトが登場したとき、オブジェクトは偶然にコードを構造化する直感的な方法であり、後に人々はその上にあらゆるものを追加し始めました。一般的に、オブジェクトはカプセル化のためであり、コードの再利用のためではありません。コードの再利用にはさらに何かが必要であり、クラス継承階層は、コードの再利用メカニズムが実際にあるべきものの貧弱な代替物です。

OOPは特別なものではありません。OOPの有無にかかわらず、再利用可能なコードを作成できます。純粋な関数は特に再利用可能です。たとえば、java.lang.math.sqrt(double)数値を入力し、数値を出力します。OOPはありませんが、他のほとんどのコードよりも間違いなく再利用可能です。

関数型プログラミングの観点から見ると、OOPは主に状態の管理に関するものです。

関数型プログラミングでは、http：//haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.htmlのリストに便利な関数を簡単に何百も作成できます。

Listクラスには何百ものメソッドがありますか？パブリックメソッドは、小さくしたい内部状態へのインターフェイスと見なされます。

悲しいことに、多くの小さな関数を（再）使用する代わりに、一部の人々は機能を複製します。私にとっては、OOP は関数型プログラミングほどコードの再利用を推奨していないからです。

私にとっては、はい、しかし常にではありません。他の方法でもできたはずです。

ほとんどの場合、抽象基本クラスを作成し、そのクラスの具体的な実装を作成します。

また、多くのフレームワークは継承を利用してコードを再利用します（Delphi、Java、.Netは、すぐに思い浮かぶものです）。

それは、多くのユーティリティライブラリとコードのスニペットが同様に仕事をすることができなかったと言っているわけではありませんが、うまく設計されたオブジェクト階層について何か楽しいことがあります。

私の経験では、継承階層などのOOP原則を使用していたよりも、一般的なプログラミング機能（C ++テンプレートなど）を介して「再利用可能な」コードを活用することに成功しました。

OOPは効果的に再利用するにはオープンすぎます。

再利用する方法は多すぎます。各パブリッククラスは、「私の新しいインスタンスを作成してください！」と尋ねます。、各パブリックメソッドは「電話して！」、保護された各メソッドは「オーバーライドしてください！」-そして、これらの再利用の方法はすべて異なり、異なるパラメーターを持ち、異なるコンテキストで表示され、すべて異なるルールを持ち、それを呼び出す/拡張する/オーバーライドする方法があります。

APIは優れており、OOP（または非oop）ポイントの厳密なサブセットですが、実際には、APIは過剰に機能し、永久に成長し、接続ポイントが多すぎます。また、優れたAPIは生活を楽にすることができます。これは、OOPのインターフェースを提供する最良の方法です。

Datadlowパラダイムは、コンポーネントに厳密なインターフェイスを提供します。コンポーネントには次のタイプのポートがあります。

• 消費者（入力）、および
• プロデューサー（出力）。

ドメインによって異なりますが、いくつかのパケットタイプがあるため、コンシューマーとプロデューサーは同じ（または互換性のある）ポートを使用して接続できます。接続のパラメーターやその他の調整はなく、消費者と生産者を実際に接続するだけなので、視覚的に実行できる最も美しい部分です。

私は、あなたが見てとることができ、少し不明であったStackOverflowの上の「データフロー」タグ、またはウィキペディア「datafowプログラミング」またはウィキペディア「フローベースのプログラミングを」。

（また、C ++でデータフローシステムを記述しました。したがって、OOPとDFは敵ではなく、DFはより高いレベルの組織的な方法です。）

CommonLispには、再利用を実現する多くの手段があります。

• 動的型付け、デフォルトでコードを汎用的にする

• 命令的な抽象化、すなわちサブルーチン

• オブジェクト指向、多重継承と多重ディスパッチ

• 構文抽象化、新しい構文構造を定義したり、定型コードを短縮したりする機能

• 機能の抽象化、クロージャ、高階関数

CommonLispのエクスペリエンスを他の言語と比較しようとすると、コードの再利用を容易にする主要な機能は、オブジェクト指向と機能の両方の抽象化の存在であることがわかります。これらは、代替よりも補完的です。それらがなければ、欠けている機能を不器用な方法で再実装する必要があります。たとえば、非拡張メソッドのディスパッチを取得するためにクロージャーおよびパターンマッチングとして使用されるファンクタークラスを参照してください。

人々がそれを説明するような「再利用」のようなものは本当にありません。再利用は、何かの偶然の性質です。それを計画するのは難しいです。「再利用」について話すとき、ほとんどの人が意味するのは「使用」です。あまり魅力的で刺激的な用語ではありません。ライブラリを使用する場合、通常はライブラリを意図した目的に使用しています。本当におかしなことをしていない限り、再利用することはありません。

その意味で、現実世界での再利用とは、物を再利用することです。ここでこれらの座席を再利用して、ベッドを形成するために並べ替えることができます！非常に快適なベッドではありませんが、私はそれを行うことができます。それは彼らの主な用途ではありません。元の適用範囲外でそれらを再利用しています。[...]明日、私は英国に戻ります。私は飛行機を再利用しません。私はそれが意図された目的のためにそれを使用します、それについて空想的または刺激的なものは何もありません。

—ケヴリン・ヘニー

私はrisk笑して告白するつもりです、私はごく最近になってOOPを使用しています。自動的に来るわけではありません。私の経験のほとんどはリレーショナルデータベースに関係しているので、テーブルと結合について考えています。プログラミングに関しては考えを変えなくて済むように、最初から学ぶ方が良いという主張があります。私にはそんな贅沢はないので、象牙の塔の理論について私のキャリアを無駄にすることを拒否します。他のすべてと同様に、私はそれを理解します。

最初は、コンセプト全体が意味をなさないと思いました。それは単に不必要で、面倒すぎるように思えました。私は知っている、これはクレイジーな話です。明らかに、何かの利点を理解したり、より良い方法のためにそれを却下するには、ある程度の理解が必要です。

コードの再利用には、コードを繰り返さないという意欲、それを達成する方法の理解、事前の計画が必要です。価値がないと判断した場合、コードの再利用を避けるべきですか？また、他のクラスからコードを継承すべきだと判断したときにエラーをスローするほど厳密にオブジェクト指向である言語はありません。せいぜい、それらはそれを実装するのに役立つ環境を提供します。

OOPの最大の利点は、コードの編成方法を一​​般的に受け入れることだと思います。それ以外はすべてグレービーです。プログラマのチームは、すべてのクラスをどのように構成するかについて完全には同意していないかもしれませんが、コードを見つけることができるはずです。

どこにでも存在する可能性があることを知るのに十分な手続き型コードを見てきました。

OOPを使用すると、コードを再利用する方法が増えます。それだけです。

水平再利用：アスペクト、特性、移植

クラシックOOは、特にクラス間で実際の機能を共有するためのより良い方法がないためにすべての継承を夢中にすると、コードの再利用が不足することがあります。この問題のために、AOP、特性、グラフトなどの水平再利用メカニズムが作成されました。

アスペクト指向プログラミング

私はAOPをOOPの欠けているハーフオレンジと考えています。AOPは実際にはあまり知られていませんが、実稼働コードになっています。

私は簡単な言葉で説明し、それを試してみましょう：特殊な構造で、あなたが噴射することができることを想像し、フィルタ機能面と呼ばれる、これらの側面を経由影響を受けるために何が起こっているか、どのように定義する「メソッド」を持つ反射が、コンパイル時に、このプロセスはウィービングと呼ばれます。

例は、「getで始まる特定のクラスのすべてのメソッドについて、取得したデータと取得した時間をプログラムがログファイルに書き込む」という側面です。

AOPをよりよく理解したい場合は、この2つの講演をご覧ください。

• アスペクト指向プログラミングを使用してアプリケーション攻撃を防止する1/6
• アスペクト指向プログラミング：Gregor Kiczales（AOPの主人公）によるモジュール性の急進的な研究

特性と移植

トレイトは、OOPを補完する再利用可能なコードを定義するための別の構成要素であり、mixinに似ていますが、よりクリーンです。

それらを説明するのではなく、両方を説明する素晴らしいPHP RFCがあります。特性はPHPに来ていますが、すでにトランクにコミットされています。

要約すれば

私の意見では、OOPは依然としてモジュール性の鍵であり、今日よく知られているように、OOPはまだ不完全です。

OOPは、これらのツールなしで使用できる場所よりも多くの場所で使用できるコードを作成できる便利なツールのセットを提供します。PrintIt古いオブジェクト.toString()を取得して呼び出す関数を作成する場合、複数のタイプのオブジェクトで呼び出すとすぐにそのコードを再利用することになります。これらのツールを使用すると、コードの各行でさらに多くのことができます。

流行に敏感な人たちの間では、現在、関数型プログラミングは非常に人気があります。それは、コードの各行がより多くのことをするためのツールの完全に別個のセットを提供します。おそらく良くも機能もしませんが、ツールボックスに別のツールを提供します。

（オブジェクト指向の再利用の全体的な余分なレベルのためのクレイジーなアイデアがありました。アイデアは、単一のCustomerクラスを定義し、作成したすべてのアプリケーションで使用できるというものでした。動作しませんでした。しかし、それはオブジェクト指向の失敗、または再利用の失敗を意味するものではありません。

上記の投稿を読んで、いくつかのコメント：

• 多くの人は、OOPでのコードの再利用は継承を意味すると考えています。私は同意しない。インターフェイスとコントラクトは、OOPシステムでのコードの再利用の中核です。OOPは、コンポーネントテクノロジーの作成におけるグレーボックスの試みです。
• 再利用の対象としてのドメイン固有の「フレームワーク」と一般的な「フレームワーク」の違いは、あまりにも抽象的だと思います。物事に関する私の見解では、コンポーネント（簡潔で最小限の再利用可能なインターフェイスコントラクトとその背後にある実装）は、それが対処する問題が十分に理解されている場合にのみ実行できます。非ドメインの専門家がドメインについての知識が少なくても自分の仕事を行えるようにするドメイン固有のコンポーネントは、（再）有用なコンポーネントです。ユーザーはインターフェースを理解する必要がありますが、問題のドメインの複雑さについては理解する必要はありません。
• 忘れられがちな再利用のレベル：アイデアの再利用、仕様の再利用、アーキテクチャ/設計の再利用、インターフェイスの再利用、テストケースの再利用。コードの再利用が常に好ましいとは限りません。しかし、特定のアーキテクチャに固執して新しい類似の製品に取り組むことは、多くの場合、大きな時間の節約になります。
• 私の目のOOPデザインパターン（Gamma et。al）は、より大規模なコードの再利用という文脈で意味があるというよりも、戦術的な実装手法について詳しく説明しました。OOP要素を使用してアプリケーションを作成するのに役立ちますが、単一のアプリケーションを超える「コードの再利用」の問題に対する解決策とは思われません。
• 多分それは公平ではありません：C / C ++ / C＃の20年の経験と6か月の関数型プログラミング（F＃）。再利用を可能にする主要な要素の1つは、「インターフェイス」を簡単に見つけて、それを研究し、理解し、使用する必要があることです。純粋な関数型プログラミングでは、構造、再利用の候補、すべてがどこから始まりどこで終わるかを簡単に見分けることはできません。そのように賞賛されている「構文糖」は、多くの場合私の目に塩であり、何が起こるかを簡単に見ることができません。したがって、私は見たくない隠れた副作用（怠yな評価、モナド、...）を持っているかもしれない関数（それは何ですか-関数の束？）を再利用しようとする可能性は低いでしょう。誤解しないでください、関数型プログラミングには非常にクールな側面がありますが、すべての長所は、かなりの疑いで見られます。
• 仕様、設計、実装は結合されていますが、「同じもの」に関する容易に通過可能なビューではありません。新しいプログラミングパラダイムよりも将来の生産性を高めるためには、ギャップを埋め、それらのビュー間の相互利益を高める（自動推論、トレーサビリティ）ことが非常に重要です。正式な仕様言語、標準化されたテスト表記法（ttcn3など）、およびコメントの散らばりのない仕様に対するインターフェースと契約の検証をサポートするプログラミング言語は、私たちが最も必要とするものです。

問題はもっと微妙なものです。

1. OOPは、可変状態でコードを構造化するための優れた方法です。状態をオブジェクトにカプセル化することにより、命令型のステートフルコードがより理解しやすくなります。たとえば、状態の一部がクラスのプライベートフィールドとして表される場合、少なくともこの特定の状態の一部はこのメソッドによってのみ変更できるためクラス。これが今十分である（そして、あなたは簡単に。ところで、継承を乱用することによってこの利点を破ることができる）が、waaay良くさえ、これを持っていない以上。
2. 可変状態のコードは本質的に再利用が困難です。不変のデータ構造を使用するコードよりもはるかに難しい。

したがって、OOP自体は、再利用可能なコードを作成することで悪くはありませんが、OOPを使用して記述される種類のコードは本質的に再利用が困難です。

また、関数型プログラミングにより、再利用可能なコードが増える可能性があります。しかし、期限を守って正常な機能コードを記述するための抽象化を正しく行うことは、実行不可能な場合があります。そして、「半分右」の抽象化は、OOPスタイルを表現しやすくなります。また、コードの再利用が容易になる傾向はありません。抽象化のレベルが高いということは、コードを理解するには、プログラマーの限られた認知能力からより多くの先行投資が必要になることを意味します。

実際の例として、ゲームコードには多くの可変状態が含まれます。これは、非常にパズル/アルゴリズム的なものでない限り、これがゲームのコーディングを考える自然な方法だからです。そしてもちろん、再利用するのは難しい。ただし、同じ知識を含む同じコードは、OOPなしで再利用するのがさらに困難になります。そして、それを機能的なスタイルに書き換えるには、そのコードについての考え方、その背後にある知識を完全に変える必要があるかもしれません。ええ、OOからFPへの書き直し後、コードの背後にある結果の知識ははるかに明確になります...しかし、コストは膨大になる可能性があり、あなたが最終的に信じられないほどスマートでうまく抽象化されたコードを再利用したい人によっても支払わなければならない種類のコスト。逆説的に、人々は技術的には再利用可能であっても、コードを再利用しないことになります。

...これは最後の微妙さをもたらします。コードの再利用は、コードだけではなく、People | Codeインターフェースに関するものです。OOPは、このインターフェイスを提供するのにふさわしい仕事をしています。これは、最近作成された多くの種類のコードについて、多くの人がどのように考えているかとよく一致するためです。FPはコードの再利用には向いているかもしれませんが、最近人々が実際に書く必要のある種類のコードを簡単に再利用することはできません。これは、記述する必要があるコードの種類が変わると変わります。

PSそして、「OOは可変状態ではない、不変状態のOOを持つこともできる」と言いたい場合は...「FPを名前空間として使用するFP」と呼びます。それがあなたのために働くとき、それは素晴らしいです、そして、それはいくつかの言語のモジュールシステムのいくつかの欠点を避けて、より再利用可能なコードをもたらすかもしれません。しかし、それはオブジェクト指向ではありません;）