そのような失望の理由もいくつかあります。 第一に、OOPに対するこの態度は高い期待の結果である可能性がありますが、フレッドブルックスは20年前にプログラマの生産性を桁違いに高める「銀の弾丸」を待つべきではないと書いています。 第二に、PLOの真剣な支持者（Grady ButchやBertrand Meyerなど）は、すべてがシンプルになると約束していませんでした。 OOPは、すべてのUGからキャンディーを作成する魔法の杖ではなく、再利用可能なラッパーでもあります。
質問は次のとおりです。コードを1行も書かずに既成のコンポーネントからシステムを構築できる場合、どのようにしてその大事な夢を実現できますか この形式では、ソフトウェアに固有の複雑さのために、また解決策自体が解決される問題に影響を与えることが多いため、この夢が一般に実現可能であるかどうかはわかりません。 それでも、再利用に費やしたエネルギーを適切な方向に向ければ、合理的な労力で、コードの「再利用」を適切なレベルに上げることができます。
このような嘆かわしい再利用の状態には、2つの理由があるように思えます。（1）開発者は再利用にあまり注意を払わない 、（2）開発者は再利用に過度に注意を払う。 はい、少なくとも馬鹿げているように聞こえますが、少し言い直してみましょう。 再利用の問題は、努力が時間通りに行われず、必ずしも必要な場所ではないことです。
標準ソフトウェアライフサイクル
始めるために、ソフトウェア開発の単一の反復の典型的なライフサイクルを見てみましょう。
従来のソフトウェア開発ライフサイクルは反復的であり、各反復は（ほぼ）同じステップで構成されます。 場合によっては、設計段階と実装段階を1つにまとめることができ、分析段階の前に、実行可能性調査が行われることがありますが、本質は変わりません。 ここで、特定のクラス（またはモジュール全体）を再利用する価値があるという決定がこれらの段階のどれで行われるのかという質問に答えてみましょう。 通常、この決定は、分析と設計の間のどこかでオンザフライで行われ、時には設計段階で、時には実装中に行われます。
一般に、一般化プロセスがシステムの設計に影響を及ぼし始め、時間との戦いではなく、時間の遅延と複雑さの増加につながるまで、これに問題はありません。
時期尚早の一般化
すべての自尊心のある開発者は、 Knutの邪悪な時期尚早な最適化についての引用を知っています。これは、非常に高速なコードにつながる可能性があります（通常、必要な場所ではありません）。 しかし、現在、多くのシステムの最も高価な部分は生産性ではなく、時期尚早な最適化の代わりに開発効率であるため、 「時期尚早な一般化」の問題に直面することが多くなっています。
実際、時期尚早の一般化は、将来の変更に対処する再利用または「柔軟性」を期待して、より複雑なソリューションを作成することになります。 しかし、通常起こるように、「柔軟性」はそれほど柔軟ではなく、人件費の結果が正当化されず、チームはより困難な解決策を得るため、要件は間違った方向に変化し始めます。 時にはもっと病理学的なケースがあります：例えば、最初から、「建築家」は、チーム、プロジェクト、顧客が何を必要としているかという明確なビジョンがまだないときに、ブラックジャックと女の子で自分の「フレームワーク」を作りたいという容赦ない欲求で仕事を引き受けることができます。 その結果、各プロジェクトは曲がったライブラリとフレームワークに囲まれていますが、これらは使用するのに不便であり、保守に費用がかかります。
問題は、公開されているコードを設計、実装、および保守するコストが、単純なカスタムソリューションを保守するコストよりも数桁高いことです。 すべては、再利用可能なコードがより完全で詳細なドキュメント、より良い品質とテスト範囲、使用例とユーザードキュメントを必要とするという事実から始まります。 コードがチーム内で再利用されることを意図している場合でも、その品質と使いやすさは、プログラマーが自分の好きな庭を囲うのではなく、あなたの決定を理解するのに経済的に実行可能なものでなければなりません。 そして、私は再利用文化の必要性について話しているのではありません。再利用文化なしでは、最愛のNIH（Not Invented Here）症状のおかげで、「再利用」の概念全体が銅の流域で覆われます。
ライブラリではなく、特定のソリューションの「柔軟性」に関しては、同様の問題に直面しています。 多くの人々は、「一般的な」ソリューション（拡張オプションが多数ある）が将来の変更に対処するための最良の方法であると考えています。 おそらくそうではありますが、実際には、このパスから理解するのが難しい（すべてを行うことができるため）面倒なコードにスライドし、それに付随することが非常に簡単であることを示しています。 動作の一部の側面が変更される可能性があると思われる場合は、抽象インターフェイスの背後に隠すだけで、この側面を実装の詳細にできます。 パフォーマンスと同様に、プログラマー（およびアーキテクト）は、将来何が変化し、新しいニーズがどのようなものになるかについての推測が不十分です。 もしそうなら、それを変更することで要件の変化に簡単に適応できるシンプルなソリューションに勝るものはありません。
これらすべての困難は、再利用を行うことが愚かであることを意味しません。 いや プロファイリング後にパフォーマンスの最適化を実行する方法と同様に、一般化は時間どおりに実行する必要があります。「機能」自体の開発中ではなく、後の段階で、可能な変更が送信される場所と一般化する必要があるものとチームが理解するとき-いいえ。
変更された反復ライフサイクル
ここでは、非常に重要な点を理解する必要があります。プロファイリングプロセスが、見つかったボトルネックのパフォーマンスを向上できることを保証しないのと同様に、一般化手順自体は、ユーザーフレンドリーなコードを作成するのに十分な条件ではありません。 これは、設計と実装の段階で得られたシンプルで適切なソリューションを再結合して再利用レベルにするための段階です。不要な依存関係が削除され、ドキュメントが改善され、ユニットテストが追加されます。 実装中にすべてがくしゃくしゃになっていて、ボトルなしでは理解できないようなボールがシステムで作られている場合、将来の「再利用」について話すことはできません。 しかし、問題をうまく解決するシンプルで理解しやすいアーキテクチャから始めると、同じタイプの複数のソリューションを1つに結合することは、共通点が明確に明確になったときにはるかに簡単になります。
注
この場合、ライブラリの開発を個別の製品とは考えません。 ライブラリは元々再利用のために研ぎ澄まされ、そこではさまざまな方法で行われます。 フレームワーク設計ガイドラインに目を通すだけで、ライブラリを開発する際に、その品質、使いやすさ、重大な変更がないこと、直感性、「階層」などが前面に出てくることを理解できます。 ここでは、一般向けのライブラリについてではなく、一般的なエンタープライズアプリケーションの「再利用」に関する問題について説明します。
一般化段階は、正式なものである必要はなく、開発の各反復で行われる必要もありませんが、遅かれ早かれ、チームはコード（および設計）を念頭に置くために追加の努力をする必要があります。
おわりに
残念ながら、一般化の段階でさえ、コードの「再利用」を増やす保証はありません。 最初の問題は、次の反復の新機能をリベットする代わりに、管理者が理解できない一般化のために余分な時間を費やすことに関連しています。 はい、誰もが再利用の重要性を主張しますが、追加コストに関しては、プロジェクトマネージャーの近視眼的役割があり、一般化は拒否されます。 これにはいくつかの真実があります。 2番目の問題は、再利用可能な高品質コードの可用性がその使用を保証しないことです。 通常の「再利用」には文化も必要です。また、誰もが愛するNIHと自転車作りへの渇望は非常に強いため、再利用を試みても何も起こりません。
しかし、いずれにせよ、私のアドバイスは、将来の変更の ためにシンプルさと「柔軟性」を選択するとき、 シンプルにこだわるという事実に要約します。 結局、ソリューションが単純であれば、将来のニーズに合わせて修正したり、再利用のために一般化することは難しくありません。 さて、この種のものが何も必要ない場合は、時間とエネルギーを節約するだけで、このシンプルなソリューションで何年も生きることができます。
注
一般化段階のアイデアは、Bertrand Meyerの著書「Object-Oriented Design of Software Systems」で提案されたので、「28.5 Generalization」セクションでいくつかの詳細を見つけることができます（ちなみに、これはOOPに関する多くの興味深いアイデアを見つけることができる素晴らしい本ですソフトウェア開発）。