良いソースとは？-Javaの参照型変数と引数- 私の結論

先日５月７日に記事を一つ書かせていただいた。
「良いソースとは？-Javaの参照型変数と引数」

簡単におさらいを。

---

最近の悩み。「良い設計・ソースとは」
【要件】
あるクラスの中で、０から９までの整数を格納しているリストが必要である。
今回はこのリスト取得のために、１つメソッドを作成したい。
メソッドは以下の要件を満たすこと。

• アクセス修飾子：private
• メソッド名：createList

と、上記のように２人のコーダーに伝えたとする。 すると、下記のようなメソッドが納品された。

【納品物1】
private void createList(List <Integer> list) {
    for(int i = 0; i < 10; i++) {
        list.add(new Integer(i));
    }
}

【納品物2】
private List<Integer> createList() {
    List<Integer> result = new ArrayList<Integer>();
    for(int i = 0; i < 10; i++) {
        result.add(new Integer(i));
    }
    return result;
}

---

「１と２でどちらが良いか」についてコメントをいただいた。
コメントを頂戴いただいた方々、この場を持って御礼申し上げます。
ありがとうございました。

頂いたコメントをまとめるとこんな感じ。

• ２が良い。
• １はNullチェックや引数のリストに対して追加をする場合には良い。（条件付）

私も２が良いと考える。その理由は以下の通り。

• 要件から「作成したメソッドを呼び出すことで、必要なリストが作成される」と読み取れ、満足するのは２である。
• １を使用する場合、呼び出し元で予期せぬデータ操作が行われてしまう可能性がある。
• １を使用する場合、予期しない例外が発生する可能性がある。

つまり、コメント頂いた方々と同じ理由だ。

もし、１のように実装する場合は、呼び出し側で明示的に入れ替える処理を記載するようにListをreturnするのが良いと思う。
そうすれば、呼び出し元で予期しないデータ操作を幾らか回避することができると考える。

コメントでも頂いたのだが、

結局はそのメソッドの責務を明確にすることが重要で、その責務に見合った引数と戻り値を設定することが大切ではないか

ということだと思う。
後輩に説明する際には、コメント頂いた内容を参考にさせていただきます。

良いソースとは？-Javaの参照型変数と引数

仕事で詳細設計と実装をやっていたり、後輩のソースコードレビューをしたり。 そこで最近の悩み。

「良い設計・ソースとは」

私自身、”何が良い”という好みはある。けど、後輩に指導するときの根拠として弱いと思う。 そこで、皆さんのご意見をお聞かせ頂けたら、と思って今回のブログを書かせていただきたい。 今回は実際に私が困った事と類似の例を紹介させていただく。

---

【要件】
あるクラスの中で、０から９までの整数を格納しているリストが必要である。
今回はこのリスト取得のために、１つメソッドを作成したい。
メソッドは以下の要件を満たすこと。

• アクセス修飾子：private
• メソッド名：createList

と、上記のように２人のコーダーに伝えたとする。 すると、下記のようなメソッドが納品された。

【納品物1】

private void createList(List<Integer> list) {
 for(int i = 0; i < 10; i++) {
  list.add(new Integer(i));
 }
}

【納品物2】

private List<Integer> createList() {
 List<Integer> result = new ArrayList<Integer>();
 for(int i = 0; i < 10; i++) {
  result.add(new Integer(i));
 }
 return result;
}

---

どちらも要件を満たしているが・・・

• どちらが”良い”ソースだと思いますか？
• それはなぜですか？

コメントに皆様のご意見をお書き頂けたら幸いです。

JavaOne Tokyo 2012に参加して～4月5日～

遅くなってしまいましたが、4月4日と5日に開催された JavaOne の二日目の5日の参加報告です。

【参加したセッション】

1. 9:00-11:00 [JK2-01] Technology Keynote
2. 11:15-12:15 [JS2-01] Chuck Munn Lee 「The Java EE 6 Programming Model Explained」
3. 12:30-13:30 ランチセッション-エンジニアに直接質問してみよう！
4. 13:15-14:15 休憩
5. 14:30-15:30 [JS2-24] 輪島 裕之 「ビジネスの継続的改善に貢献するJava EEアーキテクチャとアジャイル開発」
6. 15:45-16:45 [JS2-33] 山本 裕介 「JSR 353: Java API for JSON Processing」
7. 17:00-18:00 [JS2-41] Douglas Clarkeis 「Java Persistence API on the Grid」
8. 18:15-19:15 [BoF2-04] 木村 貴由、寺田 佳央 「The New JSR-107 Caching Standard 」
9. 19:30-20:30 スペシャルセッション

---

１． 9:00-11:00 [JK2-01] Technology Keynote

■SE 7での主な変更点

1. MapやらListの宣言時の型宣言を行うジェネリックス
   　-> 左辺だけ記述して、右辺については省略可能
2. Switch文の条件にStringが使用可能に
3. try-catchのcatch句で条件をor表記可能に
   　-> 例） catch(NullPointerException | NumberFormatException)
4. FileStreamのclose()が不要になる
   　-> try-with-resourceを使って自動close

（１）については非常に嬉しい！
MapのMapを作ったときには１行が200文字程度になったりするから・・・ ま、そんなMapを作るくらいならBeanをうまく作った方が現実的なような気がしますが（汗）

（２）これについても嬉しい！
Stringの比較をする際にはIf文が大変なことになるから。 それがSwitch文で書ければ、分岐が分かりやすくなる。

（３）今まで予期したExceptionのCatch句が複数になる場合、 ログ出力とかはそのクラス内でprivateメソッドを作って共通処理化して、 そのメソッドを呼び出すようにしていた。 結局テストのし易さとかで判断するようになると思うけど、 今はまだ旨みが分からんな。。。

（４）これってDBのトランザクションもだっけ？
それだったらかなり嬉しい！ちょっと調査が必要だな。

２．11:15-12:15 [JS2-01] Chuck Munn Lee 「The Java EE 6 Programming Model Explained」

正直なところ、英語も早かったし、通訳も早かった。。。 途中まで、というか最初しか付いていけなかった。

分かった範囲では、次の感じ。

• これまでWeb.xmlに書いていたサーブレットの設定がアノテーションでできる
• 同じくフィルターの設定もアノテーションでできる

これでweb.xmlの記載量が減ることは確か。
でも、一方のサーブレットから他方のサーブレットを呼びたい時はどうすんだ？ サーブレットクラス自身には自分のマッピングルールだけ書けば、 他のサーブレットからでも、そのマッピングルールが参照できるってこと？ １ユースケース内であればイイと思うけど、ユースケースの入り口のような 複数箇所から呼ばれそうなサーブレットはweb.xmlに記載して共通化した方が チーム開発では便利なような気がする。。。

フィルタに関してはSaStrutsでも同じようにできるようになるのか？ それならweb.xmlが太ることなく設定できるからいいかも。 けど、どのクラスに設定したかは探すのが大変になりそうだ。 でも、パッケージ構成とかクラス名とかを工夫すれば解決できるか。 ん～どうなんだろ？？

３．12:30-13:30 ランチセッション-エンジニアに直接質問してみよう！

正直なところ、ご飯を食べてるだけで、ほとんど英語でディスカッションされていたので、 内容が分からなかった。。。 本来はネイティブな方が通訳になってくれて、日本語での質問がOKだったのに、10回中３回くらいしか日本語なかった。

４．13:15-14:15 休憩

ノートPCとケータイの充電が（私の体力も）切れてしまったので、カフェで１時間休憩した。
この間にGmailに来てたメールを処理したり、ブログ書くようにまとめ作業を行ったりした。 カフェは窓際に面していて、東京タワーやスカイツリーが見えた。風景写真を撮影している人も居た。 とても明るく開放的な雰囲気で、電源タップが用意されていたので、PCを触ったり食事をしながら雑談をしたり、って感じ。 あとは、各協賛会社のブースもあって、かなりにぎわっていた。

５．14:30-15:30 [JS2-24] 輪島 裕之 「ビジネスの継続的改善に貢献するJava EEアーキテクチャとアジャイル開発」

アジャイル開発の事例紹介が聞けると思って参加。確かに事例は聞くことができた。
他の会社がどのように開発スケジュールをひいているのか、を聞くことができた。 また、要員確保の方法と契約方法について、どのような契約方法があってどのような特徴があるのかを知ることができた。

６．15:45-16:45 [JS2-33] 山本 裕介 「JSR 353: Java API for JSON Processing」

TwitterだけでなGoogle、Yahoo!でも使用されているJSON（JavaScript Object Notation）。 現在最もポピュラーなWebAPIであるJSONについて標準化を行っていること、その内容についてお話いただいた。 XMLと比較して、JSONは設定が簡単で人間でも読みやすいのが特徴。

■Javaの標準化に関する略称

• JCP：Java Community Process　Java標準化機構
• JSR：Java Specification Request　Java新機能提案
• TCK：Technology Compability Kit　準拠判断テストツール

JSONについては、JSR353で標準化作業が行われている。 標準として策定されるためにはTCKも作成する必要がある。

このセッションの中で一番驚いたのが、 JSONのモデリングにVisitorパターンが採用されていること。 Visitorパターンをちゃんと把握しているわけではないけど、ちょっと違和感を感じた。 Template Methodの方がしっくりくるような気もするけど。。。

このJSR353が策定・承認されて、Javaの標準APIとして搭載されるようになれば、 独自でAPIを突っ込む必要がなくなるので、楽になるだろうなぁ。

６．17:00-18:00 [JS2-41] Douglas Clarkeis 「Java Persistence API on the Grid」

このセッションではJavaとDatabaseとの関連について話があったみたい。 正直私の頭では、ついていくことがかなり難しかった。。。

ついていけたのは
「Java Persistence API（JPA）は、POJOとDBのEntityをマッピングしてくれる」
ということ。
このマッピングルールはアノテーションまたはXMLで設定する。 実際のマッピング処理は、Entity Manager Factoryが行う。 JPAはキャッシュを行うので、パフォーマンス向上も図れる。 けど、キャッシュ上にあるデータとDB上にあるデータでの不整合発生が問題点だったからコントロールできるようにした。 それがData Gridらしい。

ここら辺から「コヒーエンス」とか知らない単語がバンバン出てきて付いていけなくなってしまった。。。 とりあえず、アノテーションとかXMLを利用することで、DBのエンティティとのマッピングを自動化できることが分かった。 具体的な使い方については、分からないので、調べて試してみる必要があるな。

７．18:15-19:15 [BoF2-04] 木村 貴由、寺田 佳央 「The New JSR-107 Caching Standard」

Java EE 7で本格導入されるJavaのキャッシュについてのお話。 寺田さんと木村さんの絶妙なやり取りが面白く、飽きないプレゼンだった。

JCache（JSR107）がJava Objectのキャッシュ。 使い方はConcurrentMapに類似していて、Java SE/EE 6以降で使用可能。 mavenを使用することでAPIをインポートすることができる。

Google App Engineではmemcahceが該当する。

キャッシュの対象にすべきデータは下記の４種。

• DBから取得した値（参照回数の多いデータ）
• ネットワーク越しの処理結果
• オブジェクト生成に時間のかかる処理結果
• 大規模Session情報（Sessionに大きな情報を格納すると読み書きバッファが多くかかるから）

GAEではレスポンス時間とデータ量がポイントになってくるから、 Sessionとキャッシュとリクエストとをうまく使い分けていく必要があると感じた。 どのタイミングで確定させるのがいいのかな？やっぱり詳細設計の段階かな～

８．19:30-20:30 スペシャルセッション

スペシャルセッションでは、各勉強会の主催者によるパネルディスカッション。 社内の勉強も大切だがそれだけでは不十分なんだな、って感じました。 私個人では自分で勉強会を立ち上げるのは、ちょっと厳しいので既存の勉強会から参加して勉強をしていこうと思った。