■ [UML] JBuilder用のUML設計ツール新版，従来価格の6分の1以下で登場 : IT Pro ニュース

• 「ツールが高価なので開発者はUMLの良さを実感できない」と米ボーランド幹部 : IT Pro ニュース

どんどん安くなります……が、各社大丈夫なんでしょうか。

■ Eclipseパーフェクトマニュアル

Eclipseで見るMDAの未来 - Eclipseでは上流工程と下流工程を結びつける「MDA（Model Driven Architecture）」の導入が進んできています。今すぐEclipseでMDAの未来を体験しましょう。

どのことを指しているのでしょう。

■ TSS漁

• Humor: New Invisible Framework Announced
• MainSoft announces Visual MainWin For J2EE

memo.

■ ４月スタート「あるある大事典ＩＩ」、志村けんが司会

堺・志村の強力ツートップ体制となる

ヒロミを外す。なかなか賢明。

■ [xyzzy] xyzzy > migemo.l

ぐむ。便利なんだが、だんだんこっちがxyzzyに付いていけなくなってきている。

■ ファウラーたんキター！其之弐

2004/4/20だそーな。

■ 合格いたしました

おめ！すげーすげーすげー。

■ Code Kata One - Supermarket Pricing

てなわけで、コード＝カタ。まずはローカライズする。

• 靴下：3足1000円 (4足、5足はどうする？）
• 牛肉：1キロ1990円 (250グラムはどうする？)
• 缶詰：2個買ったら1個おまけ (おまけの1個に価格はあるのか？)

出荷（何て言えばいい？チェックアウトのこと）、在庫、購買、監査記録まで視野に入れる。ビジネスロジックがどこにあるかというと、左記の単位にあるので、それらをオブジェクトとするのが一番かな。「靴下」のようなオブジェクトをたくさん作っていくとなると、スーパーにはどれだけ商品があんねんという話になるので、ここはデータを保持するだけにしときたい。

続く……かな。

追記：

前言撤回。「商品とは何か」を考えた場合、「3足1000円の靴下」「1足○○円の靴下」は別オブジェクトとするほうが自然だな。それぞれに別のロジックがあるわけだし。

        3足1000の靴下
-----------------------------
-----------------------------
売値を知っている
卸値を知っている
在庫数を知っている -> 在庫情報
利益を知っている（派生情報）

こういうクラスを作っていくのが良いのかな。これだったら、「期間限定3足1000円」というのにも対応できそう。その都度、クラスを作ればいいのだから。ここで最も「変わりやすい」のはビジネスロジックという罠。

■ メールの宛名に「様」をつけるか

ツッコミもいれたけど、あくまでもアドレス帳を見やすくするための自分用の改名のように見て取れる。

だから、

To:ひげのひと<hige@example.com>

とか

To:ゲハのひと<hage@example.com>

とかなんてのもありえたりして。こんなの着たら、「様」より萎える。

■ This kata involves no coding.とかいってるけど、Rubyでプロト。

わーすごい。Rubyだなあ。Ruby。うんうん。でも、ぼくは↓のほうが良いかなあって思うんだけど、どうだろう。Item.initializeにsales_unitsを引数にすると、Itemを他で使えなくなるので、SalesUnitにItemを入れたほうが良いと思いますた。

CheckOut<>--Order<>--OrderLine<>--SalesUnit<>--Item

でもこういうのって、もうパターンがありそうですよね。あ、「OrderLine」って日本語で言うと何になるんでしょうか。

つーか、もちっと勉強せねばだなあ。何かよいオブジェクトモデリング本ありますでしょうか。ストリームラインほげほげとかゆーのを買ってみようかと思っているんですが。

追記：

takaiさんとこに書かれているのは、『アナリシスパターン』でしょうか。ファウラー歴が短いので、手にしたこともありません。今度見てみます。つーか、コメント欄欲しいっすよー＞takaiさん。

追記2：artonさんからのツッコミ

うわッ。たどたどしく答えてみるテスト。

仮に上のモデル（SalesUnit<>--Item）にした場合、

• 1足500円:SalesUnit
• 2足900円:SalesUnit
• 3足1000円:SalesUnit

という3つのオブジェクトが作れることになります。これの何がいいかっつーと、このオブジェクトごとに利益が出せるからです。

• 靴下:Item

に price（売値） ではなく、cost（原価）を属性として持たせておけば、SalesUnit 内で 自分の持つ「price」「Itemオブジェクトの数」「Itemオブジェクト.cost」から revenue（利益）が算出できます。

ぐはっ。もうギブアップ。時間ください。

追記3：たどたどしくRuby...

恥ずかしすぎる。

class Item
   attr_reader :name, :cost
   def initialize(name = nil, cost = 0)
      @name = name
      @cost = cost
   end
end

class SalesUnit
   def initialize(items = [], price = 0)
      @items = items
      @price = price
   end
   def get_revenue
      totalcost = 0;
      @items.each{|i|
         totalcost += i.cost
      }
      @price - totalcost
   end
end

#
# exec ...
#
socks = Item.new("socks",300)

socks3 = []
3.times do
   socks3 << socks
end
print "Socks3:"
puts SalesUnit.new(socks3,1000).get_revenue

socks2 = []
2.times do
   socks2 << socks
end
print "Socks2:"
puts SalesUnit.new(socks2,900).get_revenue

socks1 = []
1.times do
   socks1 << socks
end
print "Socks1:"
puts SalesUnit.new(socks1,500).get_revenue

追記4：

あ。

束ねてあるわけではない

見落としていた＿|￣|○

追記5：

振り分け用のクラスを作るのも複雑になってイヤンなので、SalesUnitの中を魑魅魍魎にし、initializeでitems[]を渡すと、後はあんじょうやってくれはる。というのはどうデスカ。

追記6:

えーやはりtakaiさんのでお願いします（弱腰）

■ [Palm] PigyDoc Ver0.16

今ごろになってPalmをいじり始めている。PIM以外に使うようになりました。