┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.48 2004/06/09
■ I N D E X
┃
┣【Topics】納涼イベント参加者、好評受付中です。
┣【プログラミング】リファクタリング−プログラミングの体質改善 [8]
┣【プログラミング】コード＝カタで目指せ達人プログラマ [番外]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 納涼イベント参加者、好評受付中です。
〇 〇━━━━━━━━━━━━━ ━━・
7月9日に開催します、オブジェクト倶楽部納涼イベント！現在好評参加受付中
です。あなたが現場で体験した「こわーい話」を披露してくださるライトニン
グトークスも、定員にまだ若干空きがあります。持ち時間5分、延長なし。あな
たの怖い話を熱く語ってみませんか？また、イベント当日のオブジェクト指向
開発関係の展示物（コマーシャル色OK）も受け付け中。
詳細はこちら：http://www.ObjectClub.jp/event/2004summer
なお、申し込みしていただいた方は、参加費のお支払いをしていただいた後、
振込み完了メールをお忘れなく！！
http://www.ObjectClub.jp/event/entry_infomation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】リファクタリング−プログラミングの体質改善 [8]
さて、前回は不吉な匂いから『属性、操作の横恋慕』を紹介しました。今回は
予定通り『属性、操作の横恋慕』の例外ケースを紹介します。『属性、操作の
横恋慕』の症状は次のようなものでしたね。
[属性、操作の横恋慕で見られる症状]
・やたらと他のクラスのgetメソッドを呼び出している
お気付きの方もいらっしゃると思いますが、きれいなソースコードでもこのル
ールから逸脱していることがあります。例えば「Strategyパターン」のように
ロジックを構造から分離しているケースなどがそれにあたります。それでは、
例外ケースを見て行きましょう。
『属性、操作の横恋慕』の例外ケース(例、Strategyパターン)
正直なところ、全く知らないのですが、入札システムについて考えてみましょ
う。単純に考えると、売却＝最高価格、購入＝最低価格、での入札確定があり
えますね。モデルにしてみるとこんな感じになりました。
--< モデル >----------------------------------------------------------
┏━━━━━━━━━━┓ ┏━━━━━┓
┃ 入 札 箱 ┃ ┃ 入札票 ┃
┣━━━━━━━━━━┫ ┣━━━━━┫
┣━━━━━━━━━━┫ ＊┃金額 ┃
┃add入札票(入札票) ┃━━→┃名前 ┃
┃get最高価格入札票() ┃ ┃住所 ┃
┃get最低価格入札票() ┃ ┣━━━━━┫
┗━━━━━━━━━━┛ ┗━━━━━┛
--< 最高価格入札票取得 >----------------------------------------------
入札票 a入札票 = a入札箱.get最高価格入札票();
----------------------------------------------------------------------
現時点では至ってシンプルですが、「適正価格内での最高価格で入札確定」や
「適正価格内での最低価格で入札確定」、同じく「適正価格内からランダムで
入札確定」などが、必要になるかもしれません。そうなると、どんどん「入札
箱クラス」が巨大化していきます。これでは前回紹介した『巨大なクラス』に
なってしまいますよね。この問題に対処するにはどうしたら良いでしょう？
その答えの１つが「Strategyパターン」です。「Strategyパターン」では、ロ
ジックを「戦略」として構造から分離します。適用後のモデルを見てみましょ
う。
--< モデル >----------------------------------------------------------
┏━━━━━━━━━━━┓
┃ 入 札 箱 ┃ ┏━━━━━━━━┓
┣━━━━━━━━━━━┫ ┃ 入札戦略 ┃
┣━━━━━━━━━━━┫１ １┣━━━━━━━━┫
┃add入札票(入札票) ┃━━━━┣━━━━━━━━┫
┃get入札票(int) ┃ ┃get確定入札票() ┃
┃get総入札票数() ┃ ┗━━━━━━━━┛
┃set入札戦略(入札戦略) ┃ △
┃get確定入札票() ┃ ┃
┗━━━━━━━━━━━┛ ┃
┃ ┏━━━━┻━━━━┓
↓＊ ┏━━━━━━━━┓ ┏━━━━━━━━┓
┏━━━━━┓ ┃ 最高価格入札 ┃ ┃ 最低価格入札 ┃
┃ 入札票 ┃ ┣━━━━━━━━┫ ┣━━━━━━━━┫
┣━━━━━┫ ┣━━━━━━━━┫ ┣━━━━━━━━┫
┃金額 ┃ ┃get確定入札票() ┃ ┃get確定入札票() ┃
┃名前 ┃ ┗━━━━━━━━┛ ┗━━━━━━━━┛
┃住所 ┃
┣━━━━━┫
┃： ┃
┗━━━━━┛
--< 入札箱クラス >----------------------------------------------------
public class 入札箱 {
:
public 入札票 get確定入札票() {
return a入札戦略.get確定入札票(); // 入札戦略クラスで実処理を行う
}
}
--< 最高価格入札クラス >----------------------------------------------
public class 最高価格入札 extends 入札戦略 {
public 入札票 get確定入札票() {
if (a入札箱.get総入札票数() == 0) return null;
入札票 max入札票 = a入札箱.get入札票(0);
for (int i = 1; i < a入札箱.get総入札票数(); i++) {
入札票 a入札票 = a入札箱.get入札票(i);
if (max入札票.get金額() < a入札票.get金額()) max入札票 = a入札票
}
return max入札票;
}
}
--< 最高価格入札票取得 >----------------------------------------------
a入札箱.set入札戦略(new 最高価格入札(a入札箱));
入札票 a入札票 = a入札箱.get確定入札票();
----------------------------------------------------------------------
このように「Strategyパターン」を適用することで、構造からロジックを分離
することができました。こうなると当然「最高価格入札クラス」や「最低価格
入札クラス」のget確定入札票()メソッドでは、「入札箱クラス」のget入札票
メソッドを何度も何度も呼び出すことになります。これは『属性、操作の横恋
慕』の症状だから良くないの？ という疑問も生まれますよね。
ですが、もちろんこれは『属性、操作の横恋慕』になっても良い例外ケースの
１つです。「Strategyパターン」は、既存のクラスを修正せずにロジックを追
加・修正可能にするためのパターンですので、あるクラスから分離されたロジ
ッククラスから、データを保持するクラスのgetメソッドを頻繁に呼び出すこ
とが必要になります。だからといって、「Strategyパターン」が良くないなん
てことはありませんよね。『不吉な匂い』とは、良くない構造に気付くための
あくまで目安なのです。
今回は『属性、操作の横恋慕』の例外ケースを紹介しました。みなさんのクラ
ス定義における良いヒントになったでしょうか？
わかりにくい点や質問などは随時とりあげていきたいと思いますので、気軽に
ご意見をお寄せください。お待ちしております。（梅田）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+7+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+7+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+7+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】コード＝カタで目指せ達人プログラマ [番外]
■ はじめに
この連載では、Dave"達人"Thomasによるコード＝カタを筆者による乱暴な要約
でお届けしているのですが、今回は少し趣を変えまして、Daveの割と最近のウェ
ブログのエントリにかこつけて、一冊書籍をお勧めしたいと思います。
■「テスト駆動かテストファーストか？」
DaveのウェブログであるPragDaveに「Test Driven or Test First?」なるタイ
トルの記事[*1]がポストされました。タイムスタンプは5/27です。
例によって乱暴に要約すると「テスト駆動開発(TDD)とテストファースト開発は
異なる。テストファーストはテスト駆動のサブクラスである」とのこと。例え
ば、開発手法おけるアジャイルプロセスとXPとの区別と同じだということです。
さすが達人。TDDかテストファーストか？と思い至る遥か手前、「っていうか
J2EEな業務アプリのチーム開発でTDDってどうすんのよ」と途方に暮れていた
(それもいまや過去のものとなりましたが)筆者とは大違いです。
結論を先取りしますが、TDDにテストファーストは必須ではない、という言葉
は本格的なTDD開発の入り口に立つ者には心強いひとことです。なので、Dave
の主張をもう少し詳しく見てみたいと思います。その後に、筆者の独断を混入
させつつTDD実践の入り口に立つための書籍を紹介します。
なお、本メルマガの読者諸賢にとっては蛇足かもしれませんが、ケント・ベック
自らが「TDDの皮肉の1つ」として述べている[*2]ように「TDDはテスト技法」で
はなく、「TDDは分析技法および設計技法」です(この論点についてはarton氏の
記事[*3]を参照。単なる整理にとどまらない従来型設計技法との対比は必読)。
■ テストファーストはテスト駆動のサブクラスである
DaveにとってTDDとは「設計と実装についての見通しを得るためにテストを利用
する」ものだそうです。曰く「テストが語りかけてくるものに耳を傾け、その
声にコードを従わせる」と。テストが設計を駆動し、かつその設計を検証する。
一方のテストファーストは、TDDを先鋭化したものであり、テストに失敗した
コードをテストに通るように修正する場合以外には一行たりとも本番コードを
記述してはならない、というプラクティスです。
Daveによればテストファーストはテスト駆動のサブクラスだそうです。テスト
ファーストはテスト駆動の利点すべてを兼ね備えており、そこへさらにテスト
ケースを必ず記述する厳格さが加えられる、と。
論理的にテストファーストは「正しい」のですが、現実では往々にして、その
正しさゆえの厳格さが足枷となる場面に出くわします。しかし、テスト駆動の
考え方は状況にかかわらず利用できる「重要で、普遍的と言ってもいいプラク
ティス」であるとDaveは述べています。
■ いきなりテストファーストは難しい
TDDで謳われているテストは、その明快な原理原則とは裏腹に、スキルを要する
技法です(インタフェースと実装設計のレベルが試されるのだから当然なのです
が)。しかも、設計が定量的に測定される(それはテスト可能か？)ので誤魔化し
も効きません。
TDDの概念と技術を内面化することなしにテストファーストに挑んでも、いず
れ開発は立ち行かなくなります。まずはテストファーストにこだわらず、その
スーパークラスであるTDDでの「テスト可能な設計を行う技術」を身につける
ことが大事だと思います。しかし……
■ コンテナ、この厄介なるもの
テストファーストにあらずともTDDで開発するならば、いずれにせよテストは
書かねばなりません。筆者の主戦場はJ2EEなのですが、J2EE環境では大鑑巨砲
主義の重量級コンテナという厄介なシロモノがテスト記述の行く手を阻みます。
テストファースト実践のためにTDDを身につけようとしたらJ2EEではそもそも
テストが書きづらい。どん詰まりです。
■ 『JUnit・イン・アクション』
ところが先日、一筋の光明が見えました。『JUnit・イン・アクション』[*4]
という書籍です。内容の半分以上がJ2EE環境での単体テストを扱っており、
スタブ、モック、インコンテナそれぞれを駆使した解説は非常に具体的で、ま
さに「今日から使える」といった趣です。EJBだって単体テストできる!
TDDを我が物にすることなしに「テストファーストかTDDか？」といった選択も
ありえません。周囲にTDDグルが居なくて取っ掛かりが掴みきれず、悩んでいる
方は是非、参考にしてみてください。また、本書がテストファーストの本でな
いことも、見逃せないポイントです。
筆者のTDDのどん詰まりからの脱出談については、いつかどこかで稿を改めてお
話しできれば、と思います。（かくたに）
*1: http://pragprog.com/pragdave/Practices/TestDrivenOrTestFirst.rdoc
*2: http://www.amazon.co.jp/exec/obidos/ASIN/4894717115/xpjp-22/
*3: http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/1/
http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/2/
*4: http://www.amazon.co.jp/exec/obidos/ASIN/4797325143/xpjp-22/
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E004+3+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E004+3+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E004+3+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「休日はアウトドア派？インドア派？」のホントのところ。
システム業界の人というと、どことなくインドア派の人が多いような気がしま
すが、実際のところはどうなのでしょうか。皆さんの投票お待ちしています。
アウトドア派です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+0
どちらかといえばアウトドア派です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+1
その日の気分によります。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+2
どちらかといえばインドア派です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+3
インドア派です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+4
休日もなく働いています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+5
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+13+6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部HP上にて公開します。お楽しみに。
なお、前号「出身は文系？理系？それとも体育会系？！」の結果は公開中。是
非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
「蛍」と聞くと夏のイメージですが、実は今がもっとも蛍鑑賞に適した時期ら
しい、ということを最近知りました。（これって実は常識なのでしょうか？！）
そして、夜9時頃が一番きれいに見れる時間帯だそうです。今ではすっかり珍し
くなったように感じますが、実は都内目白でも見れるみたいです。知らないだ
けで他にもそんな場所はたくさんありそうですよね。働き過ぎのみなさん、癒
されたいみなさん、たまには蛍を見に行ってみるのも新鮮でいいと思いますよ。
今週の強引な一言
*** 凝っては思案に余る（ことわざ）***
自分の役割だけに固執して、部分最適化してもプロジェクトはうまく進みませ
ん。他人の書いたコードも見るもよし、今までペアプロをしたことない人とペ
アプロするもよし、プロジェクト全体を見るような努力を怠らないようにしま
しょう。（めぐみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml_help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.