。・。・゜★・。・。☆・゜・。・゜。・。・゜★・。・。★
☆ ♪１００ 号 記 念 号♪ ☆
★ ★
☆ オ ブ ジ ェ ク ト 倶 楽 部 ☆
★ ★
。・。・゜★・。・。☆・゜・。・゜。・。・゜★・。・。☆
No.100 2005/07/13
■ I N D E X
┃
┣【Topics】☆祝☆「週刊オブジェクト倶楽部」100号！
┣【新発想】オブジェクト指向の再定義][7] - EoTとユニットテスト
┣【プログラミング】ソフトウェア原則 [2] IOP(Inside-Out Principle)
┣【オブジェクト入門】暴いておやりよＯＯバッキー[1]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 ☆祝☆「週刊オブジェクト倶楽部」100号！
〇 〇━━━━━━━━━━━━━ ━━・
2003年6月18日に第1号が発行されました「週刊オブジェクト倶楽部」ですが、
たくさんの購読者の皆さんに恵まれ、今週号で100号になりました。たくさんの
購読者のみなさんに恵まれたことを、本当に感謝いたします。これからもどう
ぞよろしくお願いいたします。
なお、今週号は、過去の記事の中から、みなさんにご好評いただいたベスト記
事トップ3をお送りします。
＝＝＝＝＝＝＝＝＝＝＝＝ 100号記念プレゼント＝＝＝＝＝＝＝＝＝＝＝＝＝
思い出記事、過去の号で良かったものを、貴方の思い出と共に語ってください。
スタッフが心打たれた10名の方に粗品を進呈いたします。
過去記事のアーカイブはこちら↓
http://www.ObjectClub.jp/ml-arch/magazine/
○下記フォーマットにて、editors@ObjectClub.jpまでメールください
○送られてきた情報は、オブジェクト倶楽部Webサイトで公開させていただく
可能性があります。
○いただいた情報は、オブジェクト倶楽部内部の統計にのみ使用いたします
=====================================================================
お名前：
ハンドルネーム：
メールアドレス：
記事タイトル／号数(発行日)：
思い出：
=====================================================================
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【新発想】オブジェクト指向の再定義][7] - EoTとユニットテスト
＝＝＝＝＝＝＝＝＝ ベスト1！ 2004/12/22号の記事です ＝＝＝＝＝＝＝＝＝
テスト容易性(EoT=Ease of Testing)が設計品質を高める、ということを以前書
いた。もう少し具体的な根拠を書きたい。
ユニットテストをたくさん作るということは、設計に対してどんな意味を持っ
ているのだろう？物理的にいうと、「プログラムのエントリーポイントを増や
している」ということになる。
（http://www.ObjectClub.jp/ml-arch/magazine/magazine75/UnitTests.GIF）
エントリーポイントとは、プログラムのスタート地点である。通常であれば、
プログラムはmainという名前の決まったエントリーポイントから呼び出され、
多くのモジュールを通過して終了する。しかし、ユニットテストを導入するこ
とによって、多くのテストメソッドが独立したエントリーポイントなる。main
以外にも多数のエントリーポイントが作られ、テスト対象のモジュール（クラ
スやメソッド）はさまざまな道筋（文脈）で呼び出されることになる。こうし
て多くの道筋で使われることで、モジュールの文脈依存が小さくなり、この結
果分かりやすく再利用しやすいテスト対象モジュールが取り出されることにな
る。さらに、モジュールの良い名前の採択が進む（文脈を表す名前でなく、責
務を表すメソッド名が現れる）。そして、――これが最も大切なことなのだが
――テストがあることによって以降のソフトウェアの変更が小さなコストでで
きるようになる（EoTは、EoC(Ease of Changing)の前提条件でもある）。
結論として、テストしやすい設計とは、「再利用性の高い設計」、「変更容易
性の高い設計」を、テストというより具体的な言葉によって方針化していると
いえる。以前、XPをやり始めたチームで、「このメソッドはユニットテストで
きません」という発言をよく聞いた。例えば、「タイマー起動である条件に合
致するユーザをDBから選択し、そのユーザのアドレスにメールを送る」という
メソッドをテストしようとしており、これはテストできない、という言い分で
ある。これは典型的な間違いだ。まず、「タイマー起動」、「DBから条件に合
致するユーザを選択」、「メールを送付」という3つに分けてテストできないか、
と考える。テストを基点としてモジュール分割を考えるわけだ。タイマー起動
のメソッドについては、時間をパラメータとし、すぐに起動されるイベントを
テストしよう。メールを送付できることをテストするのは難しい。そこでMock
（スタブ）を登場させる。メールの送付が他のクラスの責務であれば、自クラ
スのテストとしてはMailerMockを定義して、そこにメッセージが送られている
ことをテストすればよい。基本は、「テストしやすいように、責務を分割する」
ことだ。この指針が、EoT(Ease of Testing)の本質だ。テストはモジュール分
割のよいナイフになる。（平鍋）
※この連載、Webサイトで公開始めました。
http://www.ObjectClub.jp/technicaldoc/object-orientation/OO_redefine/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【オブジェクト入門】暴いておやりよＯＯバッキー[1]
＝＝＝＝＝＝＝＝＝ ベスト2！ 2004/02/18号の記事です ＝＝＝＝＝＝＝＝＝
■暴いておやりよＯＯバッキー[1]
筆者が非オブジェクトな時代から今まで経験した、オブジェクト指向での自ら
の失敗を取り上げてＯＯバッキーに断罪させるコーナーです。ちなみに主人公
は「おーおーばっきー」と読みます、よろしく！
登場人物
ＯＯバッキー：性格が悪い子猫。
オブジェクト指向の勘違いを指摘していじめるのが何より好き。
Ｕ君 ：ＯＯバッキーの飼い主。いつもＯＯバッキーにいじめられている。
気が弱い。オブジェクト指向の初心者。
ＯＯバッキー：ニャー！俺ＯＯバッキー。
オブジェクト指向の勘違いを探しにやってきた子猫なんだ。
勘違い野郎はどこにいるのかニャー。
Ｕ君 ：ＯＯバッキー。ある本を見て、社員のモデリングをしてみたん
だけど、レビューしてくれるかなぁ。一生懸命やった自信作な
んだ。
社 員
△
│
┌──┼──┐
│ │ │
担当 主任 部長
ＯＯバッキー：ニャー。こんなものはモデルでも何でもないニャー。
小学校からやり直したほうがいいんじゃないかニャー。
Ｕ君 ：そ、そこまで言わなくても。（悲しくて泣いてしまう）
なにが、だめなの？
ＯＯバッキー：主任が部長に昇格したときが表現できないニャー。
いっぺん死んでから、部長になれというのかニャー。
Ｕ君 ：そんな難しいこといわれてもわかんないよ。
じゃ、ＯＯバッキーはどうすんだよ？
ＯＯバッキー：こうだニャー。こんなの基礎の基礎だニャー。
社員──役職
△
│
┌──┼──┐
│ │ │
担当 主任 部長
Ｕ君 ：でも某本のサンプルは僕のモデルだったよ。
ＯＯバッキー：ニャー。某本にもこれはサンプルであって正しいモデルではな
いと言っているニャー。
社員は主任から部長になるケースがあるから、社員を継承し
た主任や部長だと、主任から部長になったケースに対応できな
いニャー。一度主任オブジェクトを消してから、部長オブジェ
クトを作り直さないといけないから、これじゃ主任の人を殺し
て、部長の人をつくっているのと同じで不自然だニャー。俺様
のモデルのように、社員クラスが役職をもっていて、役職が部
長とか主任になっていたら、社員クラスのオブジェクト自体を
消す必用がないニャー。社員から役職に処理を委譲すればいい
だけだニャー。
あー猫の俺に言わせているご主人さまも情けないし。あーや
るせねーニャー。
Ｕ君 ：うーむ。よーわからんような、わかったような。
ＯＯバッキー：いっぺんプログラムつくってみればわかるニャー。
こんなことやってるようじゃその筆者もたいしたことないニャー。
暴いておやり、ねぇ子猫。僕の育てたＯＯバッキー。
おなかつつけば語りだす真実を・・・。（OO槻ケンジ）
※この連載、Webサイトで公開始めました。
http://www.ObjectClub.jp/technicaldoc/object-orientation/oobacky/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【設計】ソフトウェアのお言葉[2]
- クラス継承よりもオブジェクトコンポジションを多用すること
＝＝＝＝＝＝＝＝＝ ベスト3！ 2005/01/19号の記事です ＝＝＝＝＝＝＝＝＝
こんにちは、天野勝です。
今回のお言葉は「クラス継承よりもオブジェクトコンポジションを多用するこ
と。」[*1]です。前回に引き続きGoF本[*2]からお言葉を頂戴いたしました。
お言葉のとおり、クラスを拡張する場合は、実装を継承するクラス継承よりも、
機能を既存のクラスに委譲するオブジェクトコンポジションを使うことが推奨
されています。
クラス継承の例(InheritanceClass)と、オブジェクトコンポジションの例
(CompositionClass)を以下に示します。
それぞれ、FixedClassクラスのwantMethodメソッドだけを必要としており、
otherMethodメソッドは新しいクラスでは必要としていません。また新たな機能
を実現するために、newMethodメソッドを定義しています。
===================================================================
// 既存のクラス。wantMethodだけ使いたい
class FixedClass {
public void wantMethod() {...}
public void otherMethod() {...}
}
// クラス継承
class InheritanceClass extends FixedClass {
public void newMethod() {...}
}
// オブジェクトコンポジション
class CompositionClass {
private FixedClass fixedClass = new FixedClass();
public void wantMethod() {
fixedClass.wantMethod();
}
public void newMethod() {...}
}
===================================================================
筆者が、オブジェクト指向を勉強して初めて感動したのは、プログラミング言
語でサポートしているクラス継承の機能でした。元のクラスを継承して、必要
なところだけ追加したり、上書きしたりして、新しいクラスを定義するのです。
俗に「差分プログラミング」などと呼ばれている考え方です。しかし、なんと
GoF本ではこの強力な機能を否定し、面倒くさい方法を推奨しているのです。新
しいクラスを作るときに、元となるクラスの参照を持たせて、必要な処理は元
のクラスに委譲するのです。
では、その推奨理由を考えてみます。
注目すべきは、クラス継承の例であるInheritantanceClassクラスでは、不要に
もかかわらずFixedClassクラスで定義しているotherMethodメソッドが公開され
てしまうという点です。
これは、不要な結合を避けるためにもインタフェースは最小にするべきという、
「インタフェース分離の原則(ISP:Interface Segregation Principle)」[*3]に
違反していることになります。
また、FixedClassクラスの一部分しか使わないということは、正しい継承関係
(is-a)が構築されているとは考えにくいです。これは「リスコフの置換原則
(LSP:Likov Substitution Principe)」[*4]も満たしているとは考えにくいです。
オブジェクトコンポジションでは、インタフェース分離の原則も、リスコフの
置換原則も満たしています。これらの原則を守ることで、今後発生しうる修正
の影響を受けにくい構造になるのです。確かに、短期的な開発のスピードは落
ちるかもしれませんが、保守も含めた長期的な開発のスピードをあげることが
できるのです。
結合度の観点で見てみると、クラス継承は良くも悪くもスーパクラスとサブク
ラスの結合が強く、スーパクラスの変更の影響をもろにサブクラスが受けてし
まうのです。うまく使えれば良いのですが、クラス継承の階層が深くなってし
まうと、より下位のサブクラスに悪い影響が出てしまうことが少なくありませ
ん。このようなことからも、新たなクラスを作成する場合は、クラス継承より
も、オブジェクトコンポジションが推奨されるのです。（天野勝）
[1]:「オブジェクト指向における再利用のためのデザインパターン」P.31
http://www.amazon.co.jp/o/ASIN/4797311126/xpjp-22/
[2]:[1]で紹介した本は、4人の著者によって書かれています。ソフトウェア開
発に多大なインパクトを与えたということから、この著者たちは、中華大革命
の4人組になぞらえて、Gang of Four、略してGoFと呼ばれています。
[3]:週刊オブジェクト倶楽部26号参照
http://www.ObjectClub.jp/ml-arch/magazine/27.html
クライアントに、クライアントが利用しないメソッドに依存するように、強制
してはならない、という原則。
[4]:日経ソフトウエア 2004年11月号 「オブジェクト指向設計の考え方」参照
全てのサブクラスは、スーパクラスが期待されているメソッドに渡されても正
しく動作するように設計されければならない、という原則。
ちなみに、B.H.Liskovは、1970年代のMIT在籍中にCLUというプログラミング言
語の中で、「抽象データ型」という概念を具体化しました。この抽象データ型
というのは、オブジェクト指向でいうところの「クラス」に相当します。
※この連載は、現在も継続中です。追ってWebサイトで公開予定です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━4 n d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「自宅ではどんな電話を利用していますか？」のホントのところ。
固定電話
http://www.ObjectClub.jp/special/kininaru/vote?vol=66&choice=0
携帯電話
http://www.ObjectClub.jp/special/kininaru/vote?vol=66&choice=1
IP電話
http://www.ObjectClub.jp/special/kininaru/vote?vol=66&choice=2
その他
http://www.ObjectClub.jp/special/kininaru/vote?vol=66&choice=3
自宅で電話は利用しません
http://www.ObjectClub.jp/special/kininaru/vote?vol=66&choice=4
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=66&choice=5
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「プロジェクトの情報共有にWikiを使ってますか？」の結果は公開
中。是非ご覧下さい。
⇒http://www.objectclub.jp/special/kininaru/vol65/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。米スペースシャトル「ディスカバリー」が、本日打
ち上げ予定らしいですね。この「週刊オブジェクト倶楽部」もおかげさまで、
100号を数えることができました。生まれ育った地球環境を飛び出し、夢を持っ
て宇宙に出て行くパイロットのように、オブジェクト倶楽部も現在の環境を飛
び出し、夢のある新しい環境を開拓できるよう、努力していこうと思います。
今後とも、進化するオブジェクト倶楽部にご期待ください。どうぞよろしくお
願いいたします。
今週の強引な一言
*** 聞いて極楽見て地獄（ことわざ）***
新しい技術って、簡単に手に入るような気がするもんですよね。でも、実際に
やってみるとなかなかこれが難しい。現場に導入するときは、まずは小さく試
してから導入しましょう。さもないと、本当に地獄になってしまいますよ。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2005 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.