Date:  Wed, 22 Jun 2005 18:50:41 +0900
Subject:  【オブジェクト倶楽部: 2005-22号】

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.97 2005/06/22

■ I N D E X
┃
┣【Topics】オブLOVEイベント いよいよ来週!
┣【PF】価値と原則[4]
┣【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[5]
┗【アンケート】気になるシステム業界 ホントのところ

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇  オブLOVEイベント いよいよ来週!
  〇 〇━━━━━━━━━━━━━ ━━・ 

オブジェクト倶楽部イベント、いよいよ来週です。諸事情により、参加締切を
23日(木)まで延ばしました。仕事のご都合で参加を迷われていた皆さん、これ
を機にお越しください。
なお、イベント事務局、講師の方からのおしらせを随時オブジェクト倶楽部Web
サイトのイベントページに公開しています。ご確認いただけるようよろしくお
願いします。また、コーチングワークショップは大好評につき、早々に締め切っ
てしまったのですが、参加希望の方が多いために、「無料体験コーチング」を
設けます。この情報もイベントでご確認いただけます。
http://www.ObjectClub.jp/event/2005summer/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【PF】価値と原則[4]

前回は、プロジェクトファシリテーションが大切にする「価値(value)」5つに
ついてお話しました。今回からは、5つの価値の1つ1つを解説していきます。

 ●コミュニケーション

1 + 1を2以上にするには、まず、1と1を足すこと、すなわち個人と個人が話を
することからはじめなければなりません。チームとは何か。チームは単なる個
人の集合ではありません。それは、一人ではできないことを協力しあって達成
する集団なのです。このためには、コミュニケーション路を「リッチ」で「短
い」ものにすることが重要です。リッチとは、「メール」や「電話」よりも対
面の話し合いを重視する、ということです。「短い」とは、できるだけ近くで
仕事をし、話したいときにすぐに相手にたどりつけるということです。

必要な人と、必要を感じたときすぐ、対面で話をしていますか?プロジェクト
ファシリテーションでは、チームとして個人の総和を超える成果を上げるため
に、「コミュニケーション」を価値とします。

●行動

人は、知識を重視するあまり、行動を起こさずに判断をすることがあります。
やってみないで物事を批判したり否定したりすることもあります。しかし、多
くの知識は、実際にやってみてはじめて意味や効果に気づくことが多いもので
す。逆に、知っているだけで実践しなければ、まったく価値のないものです。
本に書かれていること、机上の理論、他人から聞いたうまくいった例、などは  
そのままでは価値をもちません。行動に移して、体をうごかしてみることが大
切なのです。例えば、プロジェクトでふりかえりをしても、その後に行動が伴
わなければ意味がありません。問題の解決には、行動が必須です。具体的に行
動を起こすこと。とにかくやってみること。そこで気づきを得て、前進できる
のです。

プロジェクトファシリテーションの1つ1つのプラクティスも同じです。やって
みないと、その本当の効果は感じることができません。道元禅師の教えの中に、
「修さざるもの現れず(Without Practice、 No Emergence)」という言葉があり
ます。身体性のない知識は智恵にはならないのです。

あなたの言葉に行動はともなっていますか?プロジェクトファシリテーション
では、価値を現実のものとするために、そして気づきを得るために、「行動」
を価値とします。(平鍋)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-10&choice=0
普通:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-10&choice=1
イマイチ:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-10&choice=2 

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[5]

●はじめに
テスト駆動開発 with 特異メソッドついて2回に分けて考えてみたいと思います。
特異メソッドを使えば、クラス定義の際にメソッドを定義していなくても、プ
ログラムの実行中に、オブジェクトに対してメソッドが定義できます。今回の
ように高速にテストを通すプログラムを書くなどの際に便利な機能です。詳細
は、後述の「▲特異メソッドの説明」をご覧ください。

テスト駆動開発の基本は次の3ステップを、小さく繰り返すことです。
・レッド
  (クラスの境界や実装のゴールを明確にするために)
  まずテストを書き、テストに失敗することを確認する
・グリーン
  (過剰に時間をかけて、UML等で仮説を立てる代わりに)
  素早くテストを通すプログラムを書き、テストをパスするか検証する
・リファクタリング
  プログラムの設計上の問題箇所を特定し、設計を改善する

今回は、特異メソッドを使って「グリーン」のテストを通すプログラムを素早
く書くことに重点をおきます。

次回は、「リファクタリング」に重点をおきます。

●お題
目標は、注文と複数の明細(商品名、単価、数量)で構成されるものに対し
・注文の合計計算ができること
のテストが通るプログラムです。

事前にUMLのクラス図中心にモデリングを行う手段を選択する場合は、注文クラ
スと明細クラスを用意し、明細クラスには、属性として商品名、単価、数量、
振舞として単価×数量の小計、注文クラスには、振舞として注文の合計が必要
で、注文クラスと明細クラスに関連がありその多重度は1対多で、それをJavaで
実現するには注文クラスと明細クラスを用意して、フィールドとメソッドは・・
で、データ構造に例えばListを使って、さらに・・・、ようなステップを踏む
ところです。

「テスト駆動 with 特異メソッド」の手段を選択する場合は、おそらく次のよ
うなステップを踏むでしょう。
【step0 明細の小計(単価×数量)出すテストを通す】
【step1 既存の配列 + 特異メソッドを使って、注文の合計をするテストを通す】
【step2 注文を一般的な配列からドメイン特化のOrderクラスへ置き換えし、
  設計を改善する】
【step3 特異メソッドをインスタンスメソッドに移動し、設計を改善する】
今回はそのうちstep0、step1まで、進みます。

【step0 明細の小計(単価×数量)出すテストを通す】
---<order_test.rb>------------------------------
require 'test/unit'
require 'order'

class OrderTest < Test::Unit::TestCase
  def setup
    @line_note = LineItem.new("note", 110, 3)
  end

  def test_sub_total
    assert_equal(330, @line_note.sub_total)
  end
end

---<order.rb>-----------------------------------
#明細クラス
class LineItem
  attr_accessor :name, :price, :quantity
  def initialize(name, price, quantity)
    @name = name
    @price = price
    @quantity = quantity
  end
  def sub_total
    price * quantity
  end
end
-------------------------------------------------
sub_totalメソッドで小計しています。
(本来ならレッド→グリーンが基本ですが、省略しています) 

【step1 既存の配列 + 特異メソッドを使って、注文の合計をするテストを通す】
---<order_test.rb>------------------------------
require 'test/unit'
require 'order'

class OrderTest < Test::Unit::TestCase
  def setup
    @line_note = LineItem.new("note", 110, 3)
    @line_pen = LineItem.new("pen", 50, 4)
    @line_card = LineItem.new("card", 100, 5)
    # 注文オブジェクトを配列クラスで代替
    @order = []
    @order << @line_note << @line_pen << @line_card
  end
  ・・・
  def test_total
    # 特異メソッドを使って注文オブジェクトに合計を計算する役割を
    # を即席に付加。
    def @order.total
      self.inject(0){|sum, line_item| sum + line_item.sub_total }
    end
    assert_equal(1030, @order.total)
  end
end

----------------------------------------------------------------------
(本来ならレッド→グリーンが基本ですが、省略しています)
======================================================================
    @order = []
    @order << @line_note << @line_pen << @line_card
======================================================================
注文オブジェクト(@order)を既存の配列クラスで生成しています。新規に注文
クラスを作成する手間を省き、素早くテストを書くこと「レッド」に注力して
います。(注文クラスを一般的過ぎる配列を使った設計上の問題はありますが。
^^)
「<<」で注文オブジェクトに明細オブジェクトを追加しています。

======================================================================
    def @order.total
      self.inject(0){|sum, line_item| sum + line_item.sub_total }
    end
    assert_equal(1030, @order.total)
======================================================================
配列クラスには、注文の合計を計算するメソッドはありませんが、特異メソッ
ドを使って注文オブジェクト(@order)に合計するメソッドを付加しています。

特異メソッドを使って、新規にクラスを作成する手間を省き、素早くテストを
通すこと「グリーン」に注力しています。(各々のオブジェクトに特異メソッド
を重複して記述しなければ、totalは呼び出せない設計上の問題はありますが。
^^)

▲特異メソッドの説明
特異メソッドは特定のオブジェクトにある固有のメソッドです。上の例では、
注文の合計を計算するtotalメソッドが特異メソッドになります。
インスタンスメソッドの場合、「クラス」で事前にメソッドを定義し、オブジェ
クトから呼び出せるメソッドは、クラスで定義したメソッドに限られます。一
方、事前に「クラス」でメソッドを定義していなくても、オブジェクトに特異
メソッドを定義すれば、そのメソッドを呼び出すことができるようになります。

上記のように、高速にテストを通すプログラムを書くときや、あるクラスのバ
リエーションだけど、サブクラスを新規に作成しメソッド書く手間をかけるほ
どではない場合に、特異メソッドは役立ちます。

●まとめ
今回のポイントは次の3つになります。
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
・注文オブジェクトのために、新規にクラスを手間をかけて作らず、既存の配
  列で代替することで、素早くテストを書き「レッド」に注力する
・特異メソッドを使って即席に処理を書くことで、テストを通すプログラムを
  素早く書き「グリーン」に注力する
・配列+特異メソッドを使った設計の問題は、後の設計の改善で対処する。
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

残った設計上の課題は次になります。
・注文オブジェクトを生成するのに,一般的すぎる配列クラスを使用している
    今回の課題程度ならさほど問題にならないでしょう。一方、実プロジェク
    トの場合、注文クラスには、色々な属性(例えば注文日)、振舞い、関連を
    追加する必要があります。ところが、配列で注文に必要な属性、振舞い、
    関連を表現するのは、難しく、理解が容易でないプログラムになってしま
    います。

・特異メソッドでしか、合計の計算をするメソッドを定義していない
    いろいろな所から、totalメソッドを呼ぶ出す必要がある場合、オブジェク
    ト毎に重複してメソッド定義する手間をかけることになります。

次回は上の設計の問題を直す、「リファクタリング」を行いたいと思います。
(IENAGA)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-4&choice=0
普通:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-4&choice=1
イマイチ:
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-4&choice=2
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【クイズ】オブLOVEイベントのノベルティは何でしょう?

今週の気になるアンケートはお休みします。今週は、来週に迫ったオブLOVEイ
ベントに向け、クイズにします。
昨年の納涼イベントでは、オブLOVE特製うちわをノベルティにしました。
  http://www.ObjectClub.jp/event/2004summer/detail#utiwa
前回のクリスマスイベントでは、オブLOVE特製カレンダーをノベルティにしま
した。
  http://www.ObjectClub.jp/special/#calendar
さて、今回のノベルティはなんでしょう?

  オブLOVE特製うちわ。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=64&choice=0
  オブLOVE特製7月スタートカレンダー。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=64&choice=1
  オブLOVE特注JUDE製品。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=64&choice=2
  オブLOVE特製手ぬぐい。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=64&choice=3
  オブLOVEと全く無関係の何か。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=64&choice=4
  不況だから今回はなし。。
     http://www.ObjectClub.jp/special/kininaru/vote?vol=64&choice=5
  希望はこれ!
     editors@ObjectClub.jp まで詳細を!!

正解は来週のオブジェクト倶楽部イベントに来ていただければわかります。も
ちろん、来週のメルマガ上でも公開します。お楽しみに。
なお、前号の気になるアンケート「先週(2005/6/9)のサッカーは見ましたか」
の結果は公開中。是非 ご覧下さい。
⇒http://www.objectclub.jp/special/kininaru/vol63/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人です。梅雨期ですね。北陸と東北北部はまだ梅雨入りして
いないそうですが。じめじめとした季節ですが、オブLOVEスタッフ内は来週に
迫ったイベントに向け、活気付いてきました。活気付きすぎて、メルマガ配信
が遅れました。ごめんなさい。
  
今週の強引な一言
*** 気が利きすぎて間が抜ける(ことわざ)***
エンジニアたるもの、つい細部にマニアックさを求めてしまいがちです。そん
なときには肝心のところがおろそかになりがちです。たまには、全体を俯瞰し
てみませんか。新たな気づきが得られるかもしれませんよ。 
(さとみ)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒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.