JavaOne TokyoのサイトでこのBlogの紹介が掲載されました。
http://jp.sun.com/company/events/javaone/2005/highlight/050929.html
ボクが指差しているのはいつも机の上にいるDukeクンです。
フニャフニャとした素材で出来ていているので、煮詰まった
時に揉んだりすると心身を解きほぐしてくれます(笑)
閑話休題
座談会で挙がった話題の一つに「コーディング様式の変化」が
あります。確かに本来のJavaコード以外にいろいろ書くことが
増えてきており、「何かおまじないを書くと、Javaコードを生成
してくれる」というものがたくさん登場してきているように
思います。それらを自分なりに整理してみました。
・アノテーション
JavaDocでのインターフェース記述に始まり、X-Docletを経て
最近ではAOPも含めた広い分野で活用されている手法ですね。
・命名規則
「プログラマにJavaコードを記述する以外の余計な負担を与え
たくない」という発想に基づいて、一定のコーディングルール
に従って記述すると望ましい動作や仕様が付加されたコードが
得られるというもの。Seasar 2のS2DAOで採用されている命名
規約などはこれに該当するかと思います。
・XML設定ファイル
EJBのDeployment DescriptorやHibernateのマッピングファイル
などが代表例かと思います。
どのスタイルをどの場面で使うかはもちろん個々のフレームワーク
やコンテナの自由であるわけですが、それらがまちまちであること
は開発者に少なからず負担になるような気もします。
Hibernateではマッピングファイルを用いたり、Hibernate Annotator
でアノテーションを利用するけれども、S2DAOではコードの命名規約を
用いるといったように同じ役割を担うフレームワークでもスタイルが
大きく異なっていると、慣れないうちはちょっと混乱しそうですね。
Tigerでアノテーションが言語レベルでサポートされたわけですが
もし可能であるならば上記の3通り(あるいは他の手法も含めて)の
用途に関するガイドラインとそれらを柔軟に利用するための仕組み
(例えばアプリ毎に命名規則を定義できるなど)が提供されたらいい
かも知れないな、なんて思ったりしています。
個人的には下記のような使い分けができたら理想かなぁと思っています。
・アノテーション
主にインターフェースや外部仕様に関連した事柄を記述するために
用いる。AOPのインジェクションは機能を注入するという観点では
クラスのインターフェースや外部仕様をいじることになるので、
これもアノテーションが適しているように感じます。後はJUnitの
テストケースを記述するためにも使えるのではないかと思います。
テストコードを書くのは良いのですが、トータルのコード量が膨大
になることもしばしばあったりします。JUnitのテストメソッドに
記述する事前条件や事後条件をインターフェース仕様の具体例だと
捉えれば、以下のような書き方もできるのではないかと思います。
/*
* 足し算メソッド
* @param1 left 左辺の値
* @param2 right 右辺の値
* @return 足し算結果
* @assertTrue
* param1=5
* param2=6
* return=11
*/
public int Add(int left, int right)
return left+right;
}
もちろんこの方法は万能ではなく、ちゃんとモックを作成する
べきケースもたくさんあると思います。アサーションを随所に
仕込む手法に逆戻りしているという印象を与えるかも知れませ
んが、ちょっとしたメソッドのユニットテストの負担を軽減す
るという目的であれば、上記のようなスタイルでテストコード
を自動生成するのもアリなのかなと思ったりしています。
・命名規則
インターフェースで厳格に規定されているわけではないけれども
コーディングする上で常に作成することが決まっているメソッド
を自動的に生成したい場合にはこれが適していると思います。
getter/setterはまさにその典型例ですし、慣習的に『get/set
+フィールドの先頭を大文字にした名称』といったスタイルが
一般的に普及しています。アノテーションに続いて、命名規則を
開発者が手軽に定義できる仕組みが将来のJavaに導入されたら
個人的にはとても嬉しいです。
・XML設定ファイル
RDBのテーブル名やカラム名設定、その他もろもろのJNDI名など
デプロイ先の環境によって変化する可能性のあるものはやはり
コードとは別に管理しておいた方が良いと考えています。EJBの
DDはすごく嫌われているみたいなのですが、環境の変化に依存
する設定情報も全てアノテーションでPOJOに押し込んでしまう
というのもちょっと極端かなという気がします。何をコード内
に収めて、何をXML設定ファイルに外出しするか？はコーディング
の段階とデプロイ・運用段階の双方を考慮に入れて、バランスの
いい選択をすることが大事ではないかなと思います。
ちょこっと書くつもりだったのが、気がついたらかなり長くなって
しまいました....Javaのコーディングスタイルが今後どうなって
いくのか？についてはボク自身も大変関心あるトピックですので、
JavaOne Tokyoでは各スピーカーに直撃インタビューしてみたいと
思います。
