はじめに

「オブジェクト指向の落とし穴」は、1995年頃に発売されました。
当時流行で、ある種の熱に浮かれていた「オブジェクト指向ブーム」に水をかけるような内容になっています。

Bruce F. Webster (原著), 細井 拓史 (翻訳)
https://www.amazon.co.jp/dp/4894712164

本書の構成はPartⅠでオブジェクト指向開発について、その概念と用語を開発者、管理者、部門責任者、経営者といった幅広い人たちが理解を共通してもらえるような簡潔な説明をしています。

PartⅡではオブジェクト指向の落とし穴を以下の構成で解説しています。

• 前兆：落とし穴にはまりかかっていることを見分けるための知識
• 結果：そのままだと生じてしまう結果
• 検知法：落とし穴にはまっているかどうかを調べる方法
• 回復法：落とし穴から抜け出すための方法
• 予防法：落とし穴を事前にさける方法

そしてPartⅢではこれらの落とし穴を踏まえた上でのプロジェクト運営のヒントについて記述しています。

本書で紹介されている落とし穴

• 概念にまつわる落とし穴
  • 間違った理由でオブジェクト指向開発を始める
  • オブジェクト技術がタダで手に入ると思う
  • オブジェクト技術がすべての問題を解決すると思う
  • オブジェクト技術が成熟したものだと考える
  • 宣伝文句を概念と混同する
  • ツールを方針と混同する
  • 見かけを方法論と混同する
  • トレーニングを実戦と混同する
  • プロトタイプを完成品と混同する
• 政治にまつわる落とし穴
  • 管理職へ教育や支援要請を事前に行わない
  • 反発を過小評価する
  • 技術を過大に売り込む
  • オブジェクト指向開発を崇める
  • アーキテクチャに関する政治的側面を認めない
  • 機能要求の海に溺れてゆく
  • オブジェクト技術に社運を賭ける
• 管理にまつわる落とし穴
  • はっきりした目的をもたないままオブジェクト技術を採用する
  • 開発者の喉にオブジェクト技術を流し込む
  • 有用なソフトウェア工学手法を捨ててしまう
  • 有効な方法論を定義して活用しない
  • 準備もせずに多くのことをやろうとする
  • 開発が線形ですすむと思い込む
  • 合意のないまま、仕様が変更されるに任せる
  • 新しい機能が忍び込む（あるいはなだれ込む）ことを許す
  • プロトタイプの機能を完成品の機能であると誤認する
  • 開発サイクルの相対コストを見積もり損なう
  • リスクの管理を怠る
  • 自分自身や他人に嘘をつく
  • 間違った尺度を使う
  • 間違った開発者を使う
• 分析と設計にまつわる落とし穴
  • 分析と設計の必要性を過小評価する
  • 分析と設計の難しさを過小評価する
  • 古い皮手袋に新しいワインを入れる（あるいはその逆）
  • 自分の盲点に気が付かない
  • 解決策が一般的すぎる、あるいは完全すぎる
  • アーキテクトの数を間違える
  • ことを複雑にしすぎる
  • パターンを全て列挙して設計を行う
  • アーキテクチャの再設計を頻繁に、間違った理由で行う
  • アーキテクチャの再設計をほとんど行わない
  • 喜ばせる相手を間違える
  • 新しいパラダイムをユーザに強制する
• 環境、言語、ツールにまつわる落とし穴
  • 商用アプリケーションのターゲット環境の選択を誤る
  • 社内に導入する環境の選択を誤る
  • オブジェクト指向に関するベンダーの言葉を信じる
  • C++を使う
  • C++を使わない
  • サポートツールとトレーニングにお金をかけない
• 実装にまつわる落とし穴
  • あわててコーディングを始める
  • カプセル化さえあれば、設計と実装の標準は不要と考える
  • プロジェクトの進行のはやさにだまされる
  • 時間もないのに多くの約束をしすぎる
  • 詳細を後回しにする
  • 軽はずみにサブシステムを書き換える
  • 重要な概念や決定事項をドキュメントに残さず、忘れる
  • 暗黒面に誘惑される
• クラスとオブジェクトにまつわる落とし穴
  • is-a関係、has-a関係、is-implemented-using関係の3つを混同する
  • インターフェイスの継承を実装の継承と混同する
  • 不当な継承の使い方をする
  • 基底クラスの機能が多すぎたり少なすぎたりする
  • 基底クラスの不変条件を保存しない
  • オブジェクト指向でないコードをそのままオブジェクトに変換する
  • オブジェクトを膨れ上がらせる
  • オブジェクトが崩れるに任せる
  • "スイスアーミーナイフ"のようなオブジェクトを作る
  • "超スパゲッティ"なオブジェクトやサブシステムを作る
• コーディングにまつわる落とし穴
  • オブジェクトをコピーする
  • オブジェクトの同値性と一意性を調べる
  • オブジェクトを追跡しない
  • メモリの消費に無頓着である
  • switch文と多態を混同する
• 品質保証にまつわる落とし穴
  • 組み合わせ数が爆発的に増えることを忘れる
  • 単体テストを行わない
  • テストを後回しにする
  • テストやサポートの必要性とそのコストを過小評価する
• 再利用にまつわる落とし穴
  • 再利用の難しさを理解しない
  • 非現実的な期待を持ったり持たせたりする
  • コードの再利用にばかり目を奪われる
  • 再利用のための投資を惜しむ
  • プロジェクトが終わってから一般化を行う
  • オブジェクト間の接続が多すぎる
  • 循環依存を許す

ここで列挙したオブジェクト指向の落とし穴といわれているものは、オブジェクト指向開発特有のものではなく、ソフトウェア開発にとって一般的なものがあります。

これら一般的な話が、本書で取り上げられた理由としては、オブジェクト指向開発においており大きなダメージを与える類の落とし穴。一般にオブジェクト指向開発のおかげで排除されると考えられていたが、そうではなかった落とし穴。そして、オブジェクト指向開発を破綻させる落とし穴であるためです。

これらの教訓は四半世紀後の視点で読んでみても、今だ役に立ちます。

また、「オブジェクト指向」ではなく「RPA」や「AI」などの現在流行りの単語に置き換えてこれらの教訓は再利用できます。

たとえば、前述の落とし穴を「オブジェクト指向技術がすべての問題を解決すると思う」という落とし穴を「RPA技術がすべての問題を解決すると思う」言い換えて、本書を読み返しても重要な教訓を我々に与えてくれるでしょう。

Amazonのレビューでは2003年時点で、「～オブジェクト指向の本の中でもこの本は古めに属する。」とか言われていますが、同時に「内容は今でも通用することばかり」と言っています。

そして、15年以上たった令和時代においても、より古くはなっていますが、内容は今でもなお通用します。