┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.41 2004/04/14
■ I N D E X
┃
┣【プログラミング】リファクタリング−プログラミングの体質改善 [6]
┣【コラム】早く失敗せよ(Fail Early)
┗【アンケート】気になるシステム業界 ホントのところ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】リファクタリング-プログラミングの体質改善 [6]
さて、前回は、不吉な匂いから『多すぎる引数』を紹介しました。今回は、予
定通り『巨大なクラス』を紹介します。巨大なクラスを前にすると、「ソース
コードを眺めただけでそのクラスを理解できない気分でいっぱいになる」のは、
私だけではありませんよね？
[巨大なクラスで見られる症状]
・属性がいっぱい（色んなものがごちゃ混ぜ）
・役割が多いので、処理の意図を読み取りにくい
・修正しようと思ったら、どこかに依存している
こうなると保守も拡張もやりにくいですね。本当に巨大だとリファクタリング
するのも大変だったり・・・。今回は、この問題を解決するためのリファクタ
リングを紹介します。
『クラスの抽出』『サブクラスの抽出』
属性をじっと見ていると、互いに関係深い属性が見えてきますよね。それらを
まとめると、ひとつのモノになりそうなときはありませんか？ そんなときは、
それらをひとつのクラスとして抽出してしまいましょう。特定のインスタンス
でのみ使用される属性がある場合は、サブクラスとして抽出するほうが適して
いることもありますので、そのあたりは見極めが必要です。
それでは、『クラスの抽出』の例を見てみましょう。次のようなクラスを見て
何か感じませんか？
--< before >----------------------------------------------------------
┏━━━━━━┓
┃ 携帯電話 ┃
┣━━━━━━┫
┃時 ┃
┃分 ┃
┃秒 ┃
┃電話帳 ┃
┣━━━━━━┫
┃アラーム() ┃
┃送話() ┃
┃受話() ┃
┗━━━━━━┛
----------------------------------------------------------------------
「時」「分」「秒」の３つでひとつのモノを表しそうですね。そう考えるとア
ラーム()操作は、それらと密接に関係していることに気が付きます。このよう
に、複数のモノが合体したようなクラスは分解の必要アリです。携帯電話クラ
スから、時計クラスとして抽出してしまいましょう。携帯電話クラスのアラー
ム()操作は、同時に抽出した時計クラスのアラーム()操作に委譲するのが良さ
そうです。
このように、クラスを抽出することでクラスの役割が明確になりましたね。
--< after >-----------------------------------------------------------
┏━━━━━━┓ ┏━━━━━┓
┃ 携帯電話 ┃ ┃ 時計 ┃
┣━━━━━━┫ ┣━━━━━┫
┃電話帳 ┃ ┃時 ┃
┣━━━━━━┫━━→┃分 ┃
┃アラーム() ┃ ┃秒 ┃
┃送話() ┃ ┣━━━━━┫
┃受話() ┃ ┃アラーム()┃
┗━━━━━━┛ ┗━━━━━┛
----------------------------------------------------------------------
今回はおまけとしてもうひとつ、『巨大なクラス』と対極に位置する不吉な匂
い『怠け者クラス』についても簡単に紹介しましょう。こちらは、作成された
ときには必要だったクラスがリファクタリングの過程でとても小さくなったと
きや、拡張を予定して冗長なつくりにしておいた部分が結局使われなかったと
きなどに、その部分を無くしてしまえというものです。今回の内容の反対です
ね。このとき、サブクラスを無くすことを『階層の平坦化』、他のクラスに合
体させることを『クラスのインライン化』といいます。
クラスを増やすほうが良いこともあれば、減らしたほうが良いこともあるんで
すね。バランス感覚が大事ということでしょう。今後紹介する匂いの中にも、
このように両極に位置するものがあります。
次回は、不吉な匂いから『パラレル継承』を紹介する予定です。わかりにくい
点や質問などは随時とりあげていきたいと思いますので、気軽にご意見をお寄
せください。お待ちしております。（梅田）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+5+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+5+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【コラム】早く失敗せよ(Fail Early)
ソフトウェアには欠陥がつき物だ。欠陥といっても、顧客のビジネスを阻害す
るバグもあれば、テスト時に発見されるロジックのミス、さらにはコーディン
グ中のつづり間違いだってある。この「欠陥」がどのくらいムダを生むか、ま
た、そのムダの損害を抑えるために有効な方法は何か、を考察してみたい。
私は以前、プロトタイプ宣言による関数の型チェックが無いC言語コンパイラを
用いていた（ANSI C 以前）。そして、そのチームの習慣として、return 文の
返り値を括弧で囲む癖があった。
int factorial(i) /* 階乗を計算する */
int i;
{
if (i)
retrun( factorial(i-1) );
else
return(1);
}
古い形式の関数先頭部や、if の条件判定に整数の非零を使っている部分に、
ちょっとしたレトロを感じる方もいるだろう。この時代（1988年）のほとんど
のコンパイラは、このコードを無言で通した。
また、その時私の開発していたアプリケーションは、ソースコードが1Mステッ
プを超えており、全体のリンクに３時間を要するまでに肥大化していた。（そ
のころは、Sun4 という大きなUNIXマシンを使っていた。メモリは8M byte だっ
たと思う）
このコードのコンパイルを通し、アプリケーション全体をリンクした。３時間
後、make プロセスは、以下のエラーで停止した。
ld: linkage error ... undefined symbol 'retrun'
return を retrun とつづり間違いしただけで、私は３時間の時間を無駄にし
た。この教訓から、私は return 文に括弧をつける習慣をやめた。()があるこ
とで、コンパイラは retrun を未定義の関数と認識してオブジェクトコードに
参照を埋め込み、リンカーに解決を任せたのだ。return に括弧がなければ、コ
ンパイラはコンパイルエラーとし、その場でエラーが分かっただろう。
このプロジェクトは、その後、プロトタイプ宣言を取り入れた ANSI-C に乗り
換えた。これにより、未解決シンボルのミスをコンパイル時に撲滅できた。
このエピソードで言いたかったことは、「早く失敗せよ」(Fail Early)である。
欠陥は、ランタイムよりもリンクタイムに、リンクタイムよりもコンパイルタ
イムに発見すべきだ。また、発見できるような設計をし、発見できるような環
境を用い、発見できるようなプロセスを使うべきだ。
トヨタ生産方式では、７つのムダが定義されている。その１つ「欠陥のムダ」
のコストは、
欠陥のムダ＝欠陥の大きさ×その欠陥が滞在していた期間
である。大きな欠陥でも、瞬時にプロセスの中で取り除かれれば大きな損害に
はならない。小さな欠陥でも、長くプロセスの中に滞在すればそのムダの全体
量は大きい。
コンパイル時にエラーを見つけるために、IDE を用いて常時コンパイルする。
型安全な言語をもちいる。assert を積極的に用いる。コーディングしてからテ
ストするまでの時間を短縮する。結合前にユニットテストを通過させる。ペア
プログラミングで常時レビューを行う。仕様の矛盾点は、すぐに顧客に相談す
る。。。これらは、すべて「欠陥をできる限り早く発見する」ことで、欠陥の
ムダを削減しようとしているのである。
さらに、この「Fail Early」は逆転の発想、「Fail First」に繋がる。先に欠
陥を定義してから、この欠陥を取り去るような設計をする、すなわちテスト駆
動開発である。テスト駆動開発は、ある意味この考え方の最終形だ。この開発
手法は、まだ発展途上であるが、新しい一つの開発のあり方を示唆している、
と言えるだろう。「テスト」と「コーディング」は限りなく接近し、ついに順
序が逆転したのである。（平鍋）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?H003+5+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?H003+5+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?H003+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗気になるシステム業界 ホントのところ
今週は「平均睡眠時間はどのくらい？」のホントのところ。システム業界にあ
っては、残業の鬼と化している方も少なくないことでしょう。ちゃんと睡眠時
間、とれていますか？
8時間以上寝ています。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+0
約7時間から8時間くらい寝ています。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+1
約6時間から7時間くらい寝ています。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+2
約5時間から6時間くらい寝ています。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+3
約4時間から5時間くらい寝ています。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+4
4時間以下です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+5
それは秘密です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+7+6
ちょっと語らせて！
editors@ObjectClub.esm.co.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部HP上にて公開します。お楽しみに。
なお、前号「オブジェクト指向の必要性」の結果は公開中。是非ご覧下さい。
⇒http://www.objectclub.jp/ml-arch/magazine/question/index.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
ちょうど今、業務で「欠陥」探しに勤しんでいます。熱中して重箱の隅をつつ
くような作業を繰り返していると視界が狭くなっていくのか、より効率的な方
法を考えること自体、忘れてしまったりしませんか？「発見できるような設計
をし、発見できるような環境を用い、発見できるようなプロセスを使うべき
だ。」の一文に冷や水を浴びせられた編集人でした。
今週の強引な一言
*** 健全なる精神は健全なる身体に宿る（Decimus Junius Juvenalis）***
これはローマの詩人ユヴェナリスの言説で、元は「健全な体に健全な精神が宿
ってほしい」という祈りの言葉です。正しかった意味はさておき、ここでは、
広く流布している意味で受け取ってください。
まずは、身体作りです。身も心もボロボロではいいものを作ることはできませ
ん。ついつい人をけなしてコミュニケーションを悪くしてしまうこともありま
す。よく寝て、よく遊び、よい仕事しましょう。（さわ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.