システム系の例外は実行時例外＋AOPでハンドリングするのがベスト - 達人プログラマーを目指して
インフラ層のチェック例外はやはりJavaのBad Partだと思う 先日のJava言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してで、 インフラ層のフレームワークなどでは実行時例外が適切 ということを書いたのですが、この点についてもう少し詳しく考えてみたいと思います。 Java: The Good Partsの本ではRMIの章があるのですが、RMIではRemoteというマーカーインターフェースを継承しつつ、すべてのメソッドがRemoteExceptionというチェック例外を送出する規則となっています。 Java Good Parts（9.1節より引用） pubic interface StatRecorder extends Remote { void recordGame(BoxScore stats) throws RemoteException;
L'eclat des jours(2006-07-13)
_ 8月9日にもう一冊 思えば昨年5月あたりから開始して、夏に大きく停滞して（編集の方には実に申し訳ないことをしました。心よりお詫びします）、年末に完了。なんか停滞の影響かこのまま覆水盆に返らずとなるのかと思っていたものの、NetBeans5に合わせて3月くらいに手直し依頼があって、その後またどうなったのかなぁ、と思っていたところ、Rails本の校了と同時くらいに最終校正が始まって、あれよあれよというまに、アマゾンです。 Seasar2で学ぶ DIとAOP アスペクト指向によるJava開発(arton) えーと、題には問題があります。指摘した時点では遅かったらしいのですが。 本来は『DIとAOPによるJava開発』であるべきですが（Java開発って何よ？ というのもあるなぁ。Javaを開発するみたいにもとれるし）、多分AOP何それ？ というのを恐れて（その懸念はわかるのですが）『アスペクト
AspectJによる契約駆動開発 (実験編) - 檜山正幸のキマイラ飼育記 (はてなBlog)
前回触れたiContractやJMLでは、クラスやメソッドの定義の直前にドキュメンテーション・コメントと同じようにして契約を書けます。ところが、アスペクトを使う場合には、ソースコード内に直接契約を埋め込むことはできません。契約だけ別ファイルに書くことになります。これは欠点でもありますが、契約だけを事前に準備する（契約ファースト！）には向いているし、契約（だけ）のメンテナンスも楽です。 そういう事情で、ここでは、インターフェースに契約を付与することを考えましょう。 契約付きインターフェース 契約付きインターフェースの構文は、Eiffelを参考にテキトーにでっち上げます。 クラス宣言頭部に不変条件を、invariant 条件の形で書く。 メソッド宣言頭部に事前条件を、requires 条件の形で書く。 メソッド宣言頭部に事後条件を、ensures 条件の形で書く。 戻り値はresultで表す。
AspectJによる契約駆動開発 (準備＋蘊蓄編) - 檜山正幸のキマイラ飼育記 (はてなBlog)
そういうわけで（前のエントリーからの続きの気分）、なんかAspectJの練習をしたくなりました。メイヤー・ファンの僕としては、最初の課題に契約（contract）をやってみたい。"The AspectJ(TM) Programming Guide"の1.3節"Development Aspects"にも、"Pre- and Post-Conditions"、"Contract Enforcement"という例が出ているのだけど、もう少し系統的な契約記述法を探ってみましょう。 契約といえば、メイヤー先生に決まってんでしょ 契約概念について知りたいなら、迷わずメイヤー本『入門』の第7章「ソフトウェア構築への体系的アプローチ」（70ページもある）を読むべし。短い解説ならWeb上でも読めます→http://archive.eiffel.com/doc/manuals/technology/cont
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
