┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.27 2003/12/17
■ I N D E X
┃
┣【Topics】「オブジェクト倶楽部クリスマス会」実施！
┣【プログラミング】リファクタリング [2] −プログラミングの体質改善
┗【ＸＰ】XP実践家への道 [9] 第九道標 - 「テスト駆動開発」と「リファクタリング」
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 「オブジェクト倶楽部クリスマス会」実施！
〇 〇━━━━━━━━━━━━━ ━━・
昨日16日、港区笹川記念会館にて、オブジェクト倶楽部クリスマス会「オブジェ
クト指向実践者の集い」が、予定人員を超えた大人数にて、盛況のうちに実施
されました。
快くご協力くださった講演者、ワークショップオーガナイザの皆さん。また、
参加者の中にも、著名なオブジェクターが顔を揃え、交流会はかなり「濃い」
ものになったようです。
オブジェクト倶楽部の平鍋健児はもちろん、司会に天野勝、各展示やワーク
ショップなどでも、岡村、梅田、北野（ko-chan）スタッフ（hiroshi）など、
メルマガでも馴染みの面々が顔を揃え、ハプニング？もありましたが、無事終
了することができました。
お忙しい中ご参加くださった皆さん、本当にありがとうございました。
ご要望がありました講演資料等は、公開可能なものは近日中に公開いたします。
お楽しみに。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】リファクタリング [2] −プログラミングの体質改善
前回は不吉な匂いから『コメント』を紹介しました。今回は予定通り『重複し
たコード』を紹介します。重複したコードは何が問題なのでしょうか？あなた
もこんな経験ありませんか？
バグの原因を突き止め、さっと修正し確認。「やった直ったー」と満足なあな
た。周囲に報告し他の作業を行っていると...
だれか：「直し漏れあるよー」
あなた：「え゛...」
そうです。まったく同じ処理が他にもいるのです。ヽ(￣Д￣*)ちっ
というわけで、重複したコードはメンテが大変になるという問題を抱えていま
す。他にもコード量が増えることで可読性が下がりやすいでしょう。筆者が良
く遭遇するパターンを例に対処法を見ていきましょう。
例、機能の追加
手順
１、似た雰囲気のコマンドクラスを丸々コピペ（コピー＆ペースト）
２、関係ありそうな部分をガリガリ修正（意外と少量）
３、完成＆コミット
ってぉぃ。ちょっと待って！ほとんど重複してるじゃないですか。
こいつは対処しないといけませんよね。ここからが対処法の始まりです。
『メソッドの引き上げ』
まったく同じ（インタフェースも内容も）メソッドがある場合は、それらを親
クラスに移動しましょう。と言っても、必ず親クラスに移動するわけではあり
ません。メソッドを所有しているクラスの１つを選び、他のクラスはそのクラ
スに対して処理を委譲するほうが良いケースもありますし、第三者となるクラ
スを作成して、そこにメソッドを所有するほうが良いケースもあります。
『Template Methodの形成』
メソッドの中身はほとんど同じなのに少し違うから引き上げられない、だけど
ちょっとした修正が必要になると全てのクラスを同じように修正しないといけ
ない…そんなときはありませんか？そんなときはTemplate Methodの出番です。
Template Methodとは、文字通りテンプレートとなるメソッドです。テンプレー
トでは、共通のインタフェースを利用することで、子クラス固有の処理と切り
離して手順を定義できます。例を見ていただければ、お分かりいただけると思
います。
[例：Template Methodの形成]
--< before >-----------------------------------------------
public class CreateLine {
public void exec() {
Line2D line = new Line2D.Double();
line.setLine(.....);
list.store(line);
draw(.....);
}
}
public class CreateRectangle {
public void exec() {
Rectangle2D rect = new Rectangle2D.Double();
rect.setFrame(.....);
list.store(rect);
draw(.....);
}
}
--< after >------------------------------------------------
public abstract class CreateShape {
public void exec() {
Shape shape = createShape();
list.store(shape);
draw(.....);
}
protected abstract Shape createShape();
}
public class CreateLine extends CreateShape {
protected Shape createShape() {
Line2D line = new Line2D.Double();
line.setLine(.....);
return line;
}
}
public class CreateRectangle extends CreateShape {
protected Shape createShape() {
Rectangle2D rect = new Rectangle2D.Double();
rect.setFrame(.....);
return rect;
}
}
-----------------------------------------------------------
それぞれ線や矩形を作って格納し、さらに描画を行うクラスです。元々が短い
コードなのであまり気になりませんが、Template Methodを適用したことで、修
正に強い構造になりました。例えば、図形に色を付ける拡張を行う場合には、
親クラスのメソッドを修正するだけで終わりなのです。良くなってますよね。
今回は、不吉な匂いから『重複したコード』を紹介しました。実践すれば、今
後の拡張が楽になりそうです。
次回は、不吉な匂いから『スイッチ文』を紹介する予定です。わかりにくい点
や質問などは随時とりあげていきたいと思いますので、気軽にご意見をお寄せ
ください。お待ちしております。（梅田）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+1+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+1+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+1+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＸＰ】XP実践家への道 [9] 第九道標 - 「テスト駆動開発」と「リファクタリング」
こんにちは、天野勝です。
今回から読まれる方もいらっしゃると思いますので、簡単にこの連載の概要を
説明します。この連載はRoy W. Miller(*1)の提案しているXPのプラクティス(*2)
を、筆者の解釈にもとづき皆様に紹介していくというものです。
☆ ☆ ☆
今回は開発者のプラクティスである「テスト駆動開発」と「リファクタリング」
を説明します。
■サンプルコード駆動開発
みなさんどうやってプログラミングを覚えましたか。
私は、サンプルコードを見て独学しました。このサンプルコードから文法やラ
イブラリの使い方まで覚えました。入門書を選択するときの基準は、ともかく
サンプルコードの量です。だらだら長い解説を読むよりも、的をついたサンプ
ルコードがあれば、一発で理解できます。この記事を読まれている方の多くも、
そんな感じですよね。
「テスト駆動開発」では、テストコードを先に書いて、そのテストを満たす製
品コードを書いて、必要に応じてリファクタリングするという作業を繰り返し
ながら開発を進めていきます。テストコードを書かないことには開発が進めら
れないのです。
この「テスト駆動開発」の私にとっての最大のメリットは、サンプルコードが
たくさん手に入ることです。テストコードがそのままサンプルコードになるの
です。私流に言い換えると別名「サンプルコード駆動開発」です。わざわざ設
計書とかを入手しなくても、どうやって使えばいいかがテストコードを見れば
分かってしまうなんてうれしいじゃないですか。そう思いませんか。
ちなみに「テスト駆動開発」のメリットとして、製品コードが完成すると同時
に、全てのコードのテストが行われている(命令網羅)(*3)というのを第一に挙
げる人もいます。プロジェクトマネジメント的にはこのような品質に関わるよ
うなことがメリットなのでしょうが、開発者的にはストレス無く開発が進めら
れるということにメリットを強く感じます。
■コードの鮮度を保つ
「動いているなら直すな」これは、いにしえより伝わる開発者の鉄則でした。
正しく動作しているコードに、わざわざ手を加えて動かなくなってしまうとい
うことがよくあります。ですので、機能を追加するときは、なるべく既存のコー
ドを変更しないように気をつけます。最初のうちはこれでよいのですが、機能
追加や修正が増えていくと次第に手がつけられなくなります。微妙なバランス
で動いている不安定なシステムと化してしまいます。
「リファクタリング」では、既存のコードを果敢に修正します。新しい機能追
加に備えるのです。動いているコードでも必要とあらば修正を行い、コードに
新しい息吹を吹き込むのです。でも、動いているコードに手を入れるのは確か
に不安です。でも、テストコードがあるので、ちょっと直してテストすること
が可能です。不安無く機能を追加したり修正したりできるのです。
テスト駆動開発とリファクタリングは切っても切れない関係です。2つのプラク
ティスとせずに、1つのプラクティスとして名前を付けたほうが良いと思ってい
ます。テストコードがない場合は、いにしえより伝わる鉄則に従って直さない
ほうがよいでしょう。
リファクタリングについてより詳しく知りたい方は、梅田の記事をご参照下さ
い。
☆ ☆ ☆
今回は開発者のプラクティスから「テスト駆動開発」と「リファクタリング」
を説明しました。次回は、今回と同じく開発者のプラクティスの「ペア・プロ
グラミング」と「集団的な所有権」について説明いたします。この連載に対す
るご意見お待ちしています。(天野勝)
*1: 「XP エクストリーム・プログラミング 適用編」の著者です
*2: http://www-6.ibm.com/jp/developerworks/java/021018/j_j-xp0813.html
*3: 判定条件の全ての組み合わせを実行する条件網羅まで行うのが望ましいです。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+8+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+8+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+8+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
今週はなんだかリファクタリング特集でしたね(笑)。
でも開発をしている皆さんには、一番身近で実感できるプラクティスではない
ですか？実際、テストにはいろいろ難しい点もあるとは思いますが。
皆さんが一番素敵！と思うプラクティスや原則はなんですか？？
（いりさ）
昨日は、大盛況のうちに、オブジェクト倶楽部クリスマス会を終了しました。
講演会、交流会ともに、お忙しい中参加していただき、本当にありがとうござ
いました。皆さん、有意義な時間を過ごすことができましたでしょうか。オブ
ジェクト倶楽部始まって以来の大型イベントで不備等ありましたが、回収いた
しましたアンケートを次に活かしていきますので、今後とも、オブジェクト倶
楽部をよろしくお願いします。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.