2015-06-02

TimeUnitという物体

Java

小ネタ。

java.util.concurrent.TimeUnit というクラスはご存知だろうか。ご存知？なら回れ右してください。お疲れさまでした。またの機会によろしくお願いします。

...

さて、読み進めているならばご存知でないはずなので、まずJavadocのリンクをば。

TimeUnit (Java Platform SE 8)

J2SE 5.0 からいらっしゃるので、別段目新しくないどころか古参とも言えるクラスです。クラスというかenumです。定義されている列挙はナノ秒、マイクロ秒、ミリ秒、秒、分、時、日の7種類。名前の通りTimeのUnitです。できることはその時間に応じた何かしら。

TimeUnitを使えば、3日が何時間かとかすぐに出せます。忘れがちな「1日が何秒か？」とかにも答えてくれます。

long 三日の時間数 = TimeUnit.DAYS.toHours(3);
long 一日の秒数 = TimeUnit.DAYS.toSeconds(1);

便利ですね！こんな使い方をしたことはありませんが。

...

なんで今回こんな記事を書いているか？それはこんなコードをなるべく見たくないからです。

// 3分スリープする
Thread.sleep(3 * 60 * 1000);

3分とかコメントに書いてしまうと、コードを変更する時にコメントも変更しなきゃいけないです。二重メンテですね。で、コメントは変更しなくても動くので忘れられがちですし、変更忘れに気づいても対応は後回しにされがちです。なので書く必要がないならば書かないほうがいい。（このあたりは過去の記事を参照くださいませ。）

に対して、それっぽく書けるのがTimeUnitさんです。

TimeUnit.MINUTES.sleep(3);

これならコメントも要らないですし、定型的な掛け算をしなくてもいいです。1000や60の意味を気にしなくて良くもなります。掛け算せずに計算後の数字を180000とか書いて0の数を間違えたりして、「そこで数値リテラルのアンダースコアだ！180_000と書くんだ！」とか無理にProjectCoinを使おうとせずにTimeUnitを使ったほうがいいと思うんです。

そんな事態に遭遇したことはないですけど。

2015-05-09

Calendar.Builderとやらを触ってみた

Java8

知らなくても生きていけるけど、知ってるとちょっと便利っぽいもの。みんな知ってるのかもしれないけど、私は今日まで知らなかったから書いておきます。

もともとは今日 @khasunuma さんがされていた一連のツイートからです。その中で紹介されたスライドに乗っかってたので。

Date and Time APIを理解する為には、ISO 8601に踏み込みましょう！ - togetterまとめ
- 該当スライド

Date and Time APIを使わない場合に間違いなく「使える」と思ったので書いておきます。というかこんなクラス作ったことあるわ……。

なにものか？

FQCNだとjava.util.Calendar.Builderになります。Calendarクラスにネストされたstaticなクラスです。追加されたのはJavaSE8になってからなので、それ以前には入ってないです。JavaSE7以前の環境で使いたいと思ったらバージョンあげてください:p

名前の通りCalendarのインスタンスを作るものです。従来の作り方よりも私の趣味には合います。使いやすいかどうかは人それぞれなところもありますので、使ってみて考えてください。とりあえずコードとか置いておくので参考にどうぞ。

Date and Time API使えば要らないんじゃ？

JavaSE8を使うからといって、Date and Time API（JSR310）を使うのが常に正解にはならないと思っています。むしろ現時点のライブラリの対応状況や開発者の理解度、運用実績などを勘案すると使用はチャレンジの領域になってしまう感も否めません。扱える体制が整っているなら使ってった方が良いとは思いますが。

なので、まだしばらくDateやCalendarとの付き合いは続くと想像しています。ということで、Calendarの補助として入ったCalendar.Builderの使い方を覚えておくことは価値があるんじゃないかと思って触ってみました。

コード

Calendar calendar = new Calendar.Builder()
          .setDate(2015, Calendar.MAY, 9)
          .setTimeOfDay(23, 47, 16)
          .build();

これで 2015/5/9 23:47:16 のCalendarインスタンスがつくれます。どうでもいいですけどこの文章を書いている時間です。第二引数の月は通常のCalendar通り0ベースですので今まで通り基本的に定数を使いましょう。設定していないところは勝手に今の時間が入るわけではなくカレンダーのデフォルト値（だいたい0）が入るので取り回しは良さそうです。

また、DateインスタンスやEpoc値から設定するsetInstantもあるので、だいたい用は足りそうだなと思いました。

setDateやsetTimeOfDayなどのフィールドを設定するメソッドと、setInstantの両方を呼び出すと例外になるところとかも良いですね。インタフェースを工夫すれば片方を呼べばもう一方のメソッドを呼べなくするようなBuilderも作れますが、そこまですると過剰にも思えるのでこれで十分でしょう。

動くコードとどうでもいいコメントは、いつものごとくGitHubの方に置いておきます。

GitHub/irof/sandbox - CalendarBuilderTest.java

脱線: メソッド名について

GitHubに上げたコードのコメントでも書き殴っていますが、Calendar.Builderのメソッド名を単体で見た場合に不満はありません。しかしながらこれがCalendarクラスのbuilderであると考えると、従来のメソッド名との齟齬は気になるところです。

Instantは今までのjava.util.Calendarの世界にはなかった言葉で、使用する際に「Calendar#setTimeをしたいときはsetInstant」という変換が必要になってきます。既存のCalendarに沿うものとして作成されたにしてはこのあたりは少し微妙。

とはいえCalendarクラスのsetTimeメソッドって名前もたいがいアレなんですよね。引数型まで含めて書くとCalendar#setTime(Date)なので、お前は一体何を言っているんだって感じだし。そもそもDate#getTimeが合ってはいるんだろうけどTimeって名前を迂闊に使ったのが云々。長年付き合ってるから慣れてはいるんだけど、見るたびにもんにょりしてます。

個人的趣味ではオーバーロードをCalenda.Builder#setInstantのように使うのが好きですが、APIの整合性を崩す方がまずいんじゃ無いかなーと思ったりしつつ、Calendar.Builder#setDateはまさに欲しかった物体なのでsetDate(Date)とする訳にもいか無いからsetInstantでいいのかな、とかもやもやしました。結局は過去とどこで折り合いをつけるかだけの話だと思いますし、現在の選択も悪くは無いと思います。

微妙に掠る過去記事: オーバーロードの誤用 - 日々常々

まとめ

悪くない。少なくともCalendarインスタンスを作る場面では積極的に使いたいと思いました。

JavaSE8でBuilderが入ったり、ファクトリメソッドのofができたり、なんかJava標準ライブラリらしからぬものが増えてきているので、長年古き良きJavaに慣れ親しんでいた方々には抵抗があるかもしれないなと思いつつ。

Builderを使ったインスタンス生成が一般的になれば、生成対象インスタンスをイミュータブルにしやすくなるので個人的には嬉しいところです。（そもそもコンストラクタやシンプルなファクトリメソッドでインスタンス化できない時点でクラス設計負けてる感はありますが。）イミュータブルが基本になれば、もう少し世界は平和になるはず。と思ってる。

2015-05-08

匿名クラスとかローカルクラスとか

Java入門+α Java

Java入門では割愛としていたローカルクラスと、ついでに関連の強い匿名クラスについて書いておきます。ネストしたクラスとかインナークラス（内部クラス）とかはそこそこしっかり書いたつもりなので、読んでいただけると嬉しいです。

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

Amazon

言語仕様とか読んでもいいと思いますし、この辺りも参考に見てみるといいと思います。

みなさまにはいつもおせわになってます。

宣言とか呼び方とか

それぞれどのようなコードで宣言するかと、呼び方について確認しておきます。もともと書こうと思ったきっかけは呼び名が揺れまくって混乱してる人を見かけたからなので、整理がてら書いておきます。

匿名クラス

単純に作るとこんな感じになります。

Object obj = new Object() {};

これだけで匿名クラスのインスタンスができます。呼ばれ方は次のようにいろんなバリエーションある。

匿名クラス
無名クラス
匿名内部クラス
無名内部クラス
匿名インナークラス
無名インナークラス

正規表現だと (匿|無)名(内部|インナー)?クラス ですかね？どれでもだいたい同じものを指しているので、適当に読み替えてください。

ローカルクラス

これも単純に作るとこんな感じ。

class Hoge {
    {
        class Fuga { }
    }
}

これで Fuga がローカルクラスです。ブロックの中で宣言すればローカルクラス……と言おうと思ったけど、classも構文上はブロック（波かっこに囲まれているのをブロックと言うならば）ぽいので困った。とりあえず、メソッドやイニシャライザ、コンストラクタとかで宣言すればローカルクラスです。呼び名はこんな感じ。

ローカルクラス
ローカル内部クラス
ローカルインナークラス

内部つくかつかないかくらいですけれど、これもまー同じようなものです。適当に読み替えてください。

補足: 内部クラスと呼ぶか？

内部クラスとstaticなネストされたクラスが区別されることは意外と少ないのですが、意識して欲しいと思ってます。内部クラスは外側のクラスのインスタンス（エンクロージングインスタンス）への参照を持つものです。このことは、GC対象になるタイミングなどに影響があります。内部クラスのインスタンスがある限り、エンクロージングインスタンスへの参照があることになります。そのため、内部クラスと呼ばれるクラスのインスタンスは下手に公開してはいけないなど、取り扱いに注意が必要になります。

匿名クラスやローカルクラスがstaticでないメンバ（インスタンスメソッドなど、通常の用途です。）で宣言された場合、内部クラスとなる可能性があります。エンクロージングインスタンスのメンバにアクセスしなければコンパイル時にエンクロージングインスタンスの参照を持たないようにコンパイルされますが、一つでも使うと参照を持つ形になります。また、staticなメンバで宣言されたとしても、そのブロック内の変数を参照する実装がされているならば、その変数の指すオブジェクトへの参照を内部クラスは持つことになります。この場合もコンストラクタや引数で渡された以外の参照を持つことになりますので、注意が必要です。

例えば以下のようにすると、ローカルクラスFugaにはfieldを使用するためにHogeを、arg1を使用するためにObjectを受けるコンストラクタができることになります。興味があればjavac/javapしてみてください。

class Hoge {
  Object field;

  void method(Object arg1, Object arg2) {
    class Fuga {
      void m1() {
        System.out.println(field);
        System.out.println(arg1);
      }
    }
  }
}

定義する状況と定義内容により、コンストラクタの暗黙の引数経由で参照を暗黙的に持ち回すようになるかが変わります。構文的な差はなく、単に使用するか否かだけでうっかり参照を持つので、基本的に参照を持つ内部クラスとして扱った方が安全かなと思っています。

で、なんと呼ぶ？

短い方が楽なので短めの「匿名クラス」と「ローカルクラス」って呼んでます。

呼び方の揺れは目くじら立てずに、全部脳内でエイリアス貼っておけばいいんじゃないのとか思ってたり。~~いつも名前大事とかいうくせに。~~なのでこの記事ではこの呼び名で通してます。

「無名クラス」の方が匿名クラスよりも短いのですが、そこは後述の「補足:クラスの名前」で書いているように一応名前あるので「無」を避けてる、くらいです。でもたまに無名クラスっていったりもしてます。

匿名クラスとローカルクラスの違い

わかりやすい違いは、名前がつくかどうかです。名前がつけばnew演算子でインスタンスが作れます。つまり、匿名クラスのインスタンスは通常一つだけれど、ローカルクラスのインスタンスは普通に複数作れます。そのことが役に立ったことは今までありませんが。（匿名クラスのインスタンスを複数作成できます。これは補足で。）

次によく挙げられるのが、匿名クラスはコンストラクタを持てない点。イニシャライザで代替できるという話は、この記事書き始めてから知りました。なるほどと思いました。確かにコンストラクタでしかできないことを代替することはできるけれど、少々無理矢理感ある。無理矢理やってるのだから正しいけれど。

もう一つの違いは拡張についてです。匿名クラスは1つのクラスを明示的に拡張するか、1つのインタフェースを実装することにより暗黙でObjectクラスを拡張するかしかできません。一方でローカルクラスは、通常のクラスと同じように1個のクラス（なにも書かなければObjectクラス）を継承できて、0個以上のインタフェースを実装できます。

一番大きな違いは3つ目じゃないかなぁと思ってたりします。でもここで挙げた3つのことが実務で役に立ったことは今までありません。というか、ローカルクラスを書いた記憶はないです。

補足: クラスの名前

class Hoge {
  {
    class Fuga {}
    new Object(){};
  }
}

これコンパイルしたら Hoge$1.class Hoge$1Fuga.class Hoge.class の3ファイルできます。それぞれのインスタンスに対して instance.getClass().getName() をしたらそのまま Hoge$1 とか Hoge$1Fuga とかになります。匿名クラスとは言え、一応名前はあることはある。で、一応コンパイルした後なら new Hoge$1() とか new Hoge$1Fuga() とかできたりする。一応。やらないけど。

補足: 匿名クラスのインスタンス化

匿名クラスはnew演算子に続けて作成するため、複数インスタンスを作成することはできなさそうに思えます。ですが、一つ前の補足にも書いているように、作成されたインスタンスのgetClassメソッドを呼び出すことでClassオブジェクトを取得することが可能です。 Classオブジェクトが取得できれば、例えばnewInstanceメソッドを使用してインスタンスを作成することもできなくはありません。つまり、次のようなコードが動作します。

class Hoge {
  public static void main(String... args) throws Exception {
    Object o1 = new Object(){};
    Object o2 = o1.getClass().newInstance();

    System.out.println(o1.getClass().getName());
    System.out.println(o2.getClass().getName());
  }
}

この匿名クラスは引数なしのコンストラクタを持っていますが、インスタンスメソッドなどで宣言した場合は「そんなコンストラクタないよ」と怒られたりします。

この辺りは昔書いたのを参考にしてください。

意識してほしいこと

知識が十分でないならば、内部クラス系（staticでないネストしたクラス、ローカルクラス）の乱用は避けましょう。いちいちクラスファイル作るのが面倒だとか~~クラス作るのにエクセルの申請書がいるとか~~言ってないで、普通にクラス作ったほうが安全ですし、変に巧妙なコードよりもわかりやすくてまともなコードになると思います。また、内部クラスを作ったならば、そのインスタンスは下手に公開しないように注意しましょう。

匿名クラスは使い所です。一部はラムダ式で置き換えられるでしょうが、全てがそういうわけではありません。少なくとも2抽象メソッド持つインタフェースはラムダ式に出来ませんし。また、本当に匿名クラスで実装するのが正しいかは一考の余地があるはずです。匿名クラスでの実装を想定するAPIのライブラリやフレームワークは数ありますが、「サンプルコードでそうなっていたから」と言って、常にそうするのが正しいわけではありません。

まとめ

匿名クラスはともかく、ローカルクラスは本当に使いません。使い所もわかりません。無理に使わないでいいと思います。 ……有効に使っている例があったらこっそり教えてください！