エンジニアのための「失敗学」のススメ

第5回 失敗の「考古」学

この記事を読むのに必要な時間:およそ 2 分

ドイツの宰相ビスマルクの有名な台詞に曰く:

愚者は経験に学び,賢者は歴史に学ぶ

しかし,失敗学的な見地で言うなら,経験=失敗から学ぶことができるなら,賢者とは言わないまでも,愚者という程でもありませんので:

愚者は経験を活かさず,凡夫は経験に学び,賢者は歴史に学ぶ

といったあたりが妥当ではないでしょうか。

前回までの解説は,自身の失敗経験を如何にして活用するか,という点に着目したものでしたが,今回は歴史=他者の失敗経験から学ぶ方法について,ソフトウェアパターン(software pattern)を題材に説明します。

ソフトウェアパターンにおける失敗「考古」

よくあるつまずき

デザインパターン(design pattern)に代表されるソフトウェアパターンは,「ベストプラクティス」(best practice)という言い方に象徴されるように,一般には「成功事例」として捉えられる状況が多いように思われます。

その一方で,第1回で述べたような成功体験の限界故なのか,ソフトウェアパターンを「難しい」とか「役に立たない」と評する人が少なくありません。

特に,まだそれほど開発経験を積んでいない人が,ソフトウェアパターンを学習した際に漏らす感想の多くは:

書いてあることは覚えたが,どのように使ったら良いのかわからない

というものが多いように思われます。

彼らの話を聞いてみると,どうやらソフトウェアパターンを,「この場合は,こうしなさい」というような,ルール集ガイドラインのように捉えているようなのです。

パターン定義において,目に付き易く,いかにも「ベストプラクティス」っぽい部分だけを捉えれば,ルール集やガイドラインに見えてしまうのは,確かに止むを得ないかもしれません。

しかしそれでは,非常に浅い理解しかできません。

「パターンを適用しない」状況を考えてみる

ソフトウェアパターンの定義には,そのパターンによって解決される問題の記述が必ずあります。

言い換えるなら,そのパターンを適用しない場合の失敗例が必ず記述されている,ということです。

たとえば,デザインパターンの1つ,Observerパターンと呼ばれるパターンの場合,パターンを適用しない場合には以下の様な問題が発生することが,「動機」において記述されています。

ここで言う「動機」とは, 『オブジェクト指向における再利用のためのデザインパターン』におけるパターン定義形式でいうところの「動機」記述を指しています。
再利用性の低下
GUI 部品のような,本来汎用性を求められる要素は,表示対象となるデータオブジェクトを固定した場合,他の表示対象への適用が難しくなるため,再利用性が著しく低下してしまいます。
表現形式選択の制限
表示を行うGUI部品と,表示対象となるデータモデルの関係が固定的になっている場合,任意の表現形式(例:棒グラフ・円グラフ・折れ線グラフ)を選択したり,単一の表示対象データモデルに対して複数の表現形式を関連付けたりといった,表現形式選択の自由度を制限してしまいます。
Observer パターン定義において,上記2つの問題点は共に(Observer パターンの導入による)「構成要素間の抽象的結合」により解消される問題としていますが,イメージのしやすさを優先して,具体的な問題点を列挙しています。

このような失敗事例は,まさに「パターンを適用する理由」を端的に表していますので,パターンを理解する上で非常に有効な示唆を与えてくれることでしょう。

著者プロフィール

藤原克則(ふじわらかつのり)

Mercurial三昧の日々が嵩じて, いつの間にやら『入門Mercurial Linux/Windows対応』を上梓。凝り性なのが災いして,年がら年中アップアップな一介の実装屋。最近は仕事の縁が元で,OpenSolarisに入れ込む毎日。

コメント

コメントの記入