■

デブサミ2005 http://www.seshop.com/event/dev/

私が話すのは、2/4

・Seasar2とS2JSFのイントロ

・S2JSFによるプレゼンテーション層の革命

です。実は全然まだ席が余っているのでよろしくお願いします。m(_ _)m

夜はもちろん徳澤直子を語る会です。

s2jsf-example

の従業員メンテナンスで、修正機能しかないのは、からさわぎに間に合わなかったためです。EA4では、新規・削除・照会も追加されます。

from 2ch

org.seasar.dao.impl.DaoMetaDataImpl#createResultSetHandler 

method.getReturnType().isAssignableFrom(List.class) 

↓ 

List.class.isAssignableFrom(method.getReturnType()) 

じゃないか？

その通りですね。修正します。

converter.html

http://d.hatena.ne.jp/makotan/20041228#p3
で謎だとされている

<input type="button" value="戻る" m:action="home" onclick="location.href='../index.html'" m:immediate="true"/>

を解説しましょう。PrefixはEA2ではsですが、今の仕様はmなので、EA2を見ている人は置き換えてください。
上記のタグは、S2JSFが解釈すると

<commandButton value="戻る" action="home" immediate="true"/>

となります。action="home"となっているので、faces-config.xmlを見て指定されたページに遷移します。immediate="true"は、バリデーションチェックを走らさないために指定します。試しに、immediate="false"にして、aaaなど日付に変換できない文字列を指定してボタンをクリックすると、バリデーションで引っかかり画面遷移することが出来なくなります。
エラーになったことを確認するには、フォームのどこかに

<span s:type="messages"/>

を追加する必要があります。
onclick="location.href='../index.html'"は、モックで画面遷移をするためのものです。onclickの値がlocation.hrefではじまっているとS2JSFはあぁ、モック用のデータなんだと思ってその部分は自動的に削除します。
例えば、onclick="location.href='../index.html';alert('hoge');"を見つけると実行時には、onclick="alert('hoge');"として解釈します。
S2JSFは、結構芸が細かいです。

from 2ch

>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。

ここでいってる外部は、クラス(Entity)の外部。仕様としてクラスを使う人に公開されてる情報です。別に私が言ってる方法でも、業務ロジックを実行するときに、State/StrategyのFactory経由で、タイプコードを置き換えれば効果は同じじゃないですかね。public String hoge;のようなほんとのpublic属性だと思っているならそれは違います。
PayCalculatorの話は、委譲先のコンポーネントがStatelessなのかStatefulなのかの話で違うといってるのかな。べつにくーすでは、Statefulなコンポーネントを否定してません。業務ロジックは、データではなく、役割でクラスを分割すべきだといってるだけです。


コメントに書いている例でも、職務を表すデータと職務が果たさなければいけない機能が同じなら、あれで十分だと思います。実際は、扶養家族だとか、さまざまなファクタが絡み合ってきて、データによる分割ではうまくいかないと思います。
もし、私がOOだとか、リファクタリングだとか良く知らないだろうということで、アドバイスしていらっしゃるのでしたら、その心配はしなくても(たぶん)大丈夫です。Seasar2は、そのようなベース(OO、リファクタリング)が出来ていないととても作れませんから。
これまでのオブジェクト指向は、素晴らしいと言われながら実はあまり成功しているとはいえない状況だと思います。これは、決してオブジェクト指向をマスターすることがかなり難しいということを意味しているだけではないと思うのです。手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。
こんなにやっても、うまくいかないのは、どこか考え直さなければならないところがあるからではないでしょうか。
その原因は、過度なデータ中心のクラス設計にあると私は考えています。データと振る舞いを1つのクラスにまとめるのは、自然なことですが、あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスになりやすいと考えています。業務アプリケーションなどはとくそうで、直接関係のない機能が1つのエンティティに押し込まれやすくなります。また、複数のデータにまたがるような機能は、そもそも適したクラスに振る舞いを割り当てるのが難しくなります。
役割によってクラスを分割するのが、最もうまくいく確率が高いのではないかというのが今の私の考えです。
blogに、これまでのオブジェクト指向の批判を書くのは、私にとってはものすごくリスクの高いことです。なにを言われてもおかしくないですから。現にいろいろ言われているわけですが、それでもあえて書いているのは、これまでのオブジェクト指向がなぜうまくいっていないのかを考え直すきっかけになればと思っているからなのです。