再利用は全自動ではない

オブジェクト指向を導入すれば過去の資産を簡単に有効利用できる、と考えるのは勘違いです。また、とにかく一度作ったものは将来再利用できる、と考えるのも勘違いです。本当は、再利用するために作られたものだけが再利用できるのです。

• ソフトウェアコンポーネント

新しいプロジェクトの開発が始まったとき、当然、以前に似たようなプロジェクトがなかったか探してみるでしょう。そうやって、流用可能なライブラリが見つかればラッキーですが、ない場合は作るしかありません。でも、新しく作るならまだマシです。それよりもっと困った結果になるのは、「似ているけれどもそのままでは使えない」場合です。

「似ているけれどもそのままでは使えない」ライブラリがある場合は、まずソースコードを探し出して自分のプロジェクトにコピーするでしょう。それから、ソースレベルで自分のプロジェクトに合うように修正を加えます。この時点で、このライブラリはもはや流用元とは別の代物になります。

この方法には、次のようなマズイ点があります：

• 修正したからには、テストしなければならない。
• オリジナルのライブラリにバグがあることが判明し、修正されるかもしれない。そうなれば独自に修正したバージョンにもバグがある可能性が高いが、その修正は自力で行う必要がある。
• 流用が行われる度に、カスタムバージョンのライブラリが無秩序に発生し、管理が不能になる。
• 将来、別のプロジェクトでも同じことが繰り返される。永遠に・・・。

正しい再利用は、ソースレベルでの修正を伴いません。つまり、「似ているけれどもそのままでは使えない」ようなものを見つけたときは、次のどちらかのようにすべきです：

• 使わない。
• 今後のプロジェクトでそのままで使えるような改造を施し、次回から流用できるようにする。

修正を行わずにそのまま「ブラックボックス」として流用する場合は、カスタムバージョンを作るという悪い方法に比べて次のような利点があります：

• テストは以前のプロジェクトで済んでいる（はず）。
• オリジナルのバグが修正されたとき、修正後のバージョンをそのまま現在のプロジェクトに適用すれば良い。
• オリジナルの機能が拡張された場合、その恩恵を得ることができる。
• この方法が慣例となれば、残業時間が減る。そして、今まで残業が多かったのはやり方がまずかったせいだと気づく。

さて、賢明な方ならもうお気づきでしょうが、ブラックボックスとして流用できるライブラリは、はじめからそのように計画されていればこそ、そうなっているのです。汎用化は、意識的に行わなければ実現しません。どのようなときでも、

「この機能は汎用化できないだろうか？」

と考えてみることができるかどうかが重要です。もしそれが可能で、かつメリットがあるなら、どのようなプロジェクトでも利用できるように汎用化するようにします。もちろん、だれでも使い方がわかるようなマニュアルを書く労力を惜しんではいけません。使い方がわからなければ、意味がありません。

そのままの形で再利用できるライブラリを作るとき、オブジェクト指向が威力を発揮します。そのような「ブラックボックス」オブジェクトのことをソフトウェアコンポーネントと呼びます。例えば、GUI 環境のコントロール（ボタンやテキストボックスなど）はソフトウェアコンポーネントです。