トップ «前の日記(2003-12-04) 最新次の日記(2003-12-06)» 編集

日々の破片

2003-12-05

_ 取りあえず上っ面をいじった程度の良い点、悪い点

よい点：迸るユーザーエクスピアリアンスってのはこれか、ってくらい、きれいだ。サファリの映し出す世界は相当衝撃的だった。一応、ブラウジングしてみた世界は、各種Windows,Solaris(CDE,Gnome),リコーフォントを入れたGnome on Linuxとかいろいろ知っていたが、驚いた。影云々の前にフォントが全然違う。使ってみないとわかんないもんだね。後、キータッチは良い。初代98ノートを思い出した。

悪い点：慣れない点を含む。なんといってもdeleteがbackspaceとして振る舞うのは許しがたい（というか位置からdeleteが無いと言うか）。それから、USBポートが左にある点。ノート用マウスって、使い勝手からケーブルが短めなんだがそれが非常に悪い方向に働いてしまう。つまり、ケーブルをキーボードの上をまたがらせないと右に置けないんですが。これは辛いな。あと、やはり（Macとは関係ないけど）タッチパッドは使いにくい。すごく。スクロールボタンの欠如も辛いかな（Looxだと３番目のボタン＋アキュポイント（の富士通版）でスクロールするからそれに慣れてるし。言う方がどうかしてるんだけどNetBEUIが無い。しょうがないけどさ（と思ったらプリンタサーバがAppleTalkをサポートしてることがわかったから問題なし）。音が悪い（いや、安価なほうのノートに言う台詞じゃないのはわかってるけど）

バグっぽい：サファリ。パスワードが正しく入らないようだ（基本認証に失敗する）。これはキャプチャして確認しないと断言できないけど(単に送信してないだけにも見える)。だから、これはIEで打ち込み。

シェルの出し方がわからないけど、これは後回し。とりあえずマカーとして使ってから裏側へ進む予定。

_ クソー（と口惜しがるってことはちょっと自己過信が過ぎるんじゃないか？）

ドメインモデル貧血症

圏外から。kdmsnrさんの翻訳（かな）。

やっぱ、まだまだトランザクションスクリプトで十分だよなって考えて書いてきたが、こういう挑発的なことを書かれると考え直しちゃうよな……いかんいかん、だが、ちょっと変えられる部分は変えることにするか。

でも、オブジェクト爆発症候群っていうかドメインモデル高脂質症ってこともありえるから注意は必要（たぶん、そんなことはわかっていて、むしろ貧血気味な人であふれてるから注意を促してるんだろうけど）。

_ なぜこのアンチパターンが一般的になっているのか

向こうの国についてはわからないが、仕様書の記述方法にあるのは間違いないだろう。特に文書としての仕様書は叙述的になりがちではないだろうか？

AがBならCに1を加算
AがDならCに2を加算
Cが100を越えたらEを実行

をそのまま実装すると

if a == b
  c += 1
elsif a == d
  c += 2
end
if c > 100
  e.apply
end

これを、たとえば

a.apply_current_status(c)
c.apply_current_status(e)
...
class C
  def apply_current_status(e)
    if @value > 100
       e.appy
    end
  end
 ...
end

のように、オブジェクトのインタラクションとして記述することにメリットがあることは容易に想像できる。たとえばaの状態判断が増加しても、メインとなっているサービス部分の処理への影響が出ないことなんかは端的に出ている。
さらに、サービス部分はこんな感じまでもっていけるかも。

 procs = []
 tx.each do |item|
   procs << [ item.foo, resource.get(item.bar) ]
 end
 procs.each do |stat|
   stat[0].apply_current_status(stat[1])
 end

問題は、この実装が、最初の仕様書とは似ても似つかぬことだ。
そこで仕様書の記述方法も変える必要が出てくるだろう、たぶん。たぶんってのは、メタデータである仕様と実装が似ても似つかぬのは当たり前って言えば当たり前だから、いらないって言えばいらないからだ。
たとえば、bshに移植することを考えたら、元の仕様書のほうが良さそうっていうか、なんにでも応用は利くよな。
だから、仕様が重要ならソースも重要なんだけど、なんとなく（文字通りなんとなくで、慣習とか不文律とかなんだろうけど）仕様とソースが一致していたほうが良いように思えるってのはある。
で面倒になってモラトリアムの結果、仕様書なしってのをやってみたけど、評判は悪いな。当然か。って言うか、メタデータたる仕様書はあるんだけど、「プログラム解説」っていうレベルの仕様書が必要だと考える人がいる限り、そしてプログラムの作り方が、いくらコーディング標準があっても巧拙がある以上、たしかにソースコードガイドが必要なプログラムが出て来る可能性は否定できなくもないし。
っていうか、企業によりけりだろうから、なんとも言えないところでもある。ある程度底辺を見なきゃならんしな。（しょせん相対的なものだからこっちが最底辺の可能性は常にある）。

_ だめだな

コンテキストが抜けてる。

上のC#apply_current_statusは、あくまでも「この」仕様でのCの振る舞いであって、別の仕様（仕様というより処理だし、その処理を決定するのはコンテキスト）では当然、異なる振る舞いをすることになる。それを無視すると、意図が読めなかったり、単純にCやAに処理が移動していくだけになる。すると、コンテキストを各クラスがコードで判断することになっていくから、かえってだめだめだ。

だからこそのストラテジなんだが（当然Cとその派生物はコンテキスト分存在するーーとまではいかないだろうが）、こんな単純な例でストラテジを出すこと自体が高脂血症になっている。

うーん。

っていうか、日記にこんなこと書いてる余裕はないんだが。最初の予定通りにやれって。