Railsの作者は美しいコードが書けるからRubyを選んだそうだが、俺にとってのRubyは美しいというよりもカッコいい。かっこいいからRubyを使う。
Railsに付属しているActiveSupportはTime等のオブジェクトに便利なメソッドを提供する。Railsユーザならご存知のことと思うが、
Time.now.tomorrow.midnight
これで明日の00:00:00の日時が取得できるというのを目にして、そのカッコよさにクラクラした。機能拡張に対して非常にオープンなRubyの言語仕様はかっこいい。このtomorrowやmidnightメソッドのように既存のクラスにもメソッドを自在に追加作成できるのも動的言語の楽しみだ。
それにしてもこのTimeの拡張、Javaの腐ったDate、Calendarの仕様と比べると雲泥の差である。ま、Javaでも似たような真似は出来ない事は無いが…、GregorianCalendarのサブクラスを作ればtomorrowやmidnightのようなメソッドを実装することはできる。
public class ActiveCalendar extends GregorianCalendar{ public ActiveCalendar tomorrow() { add(DATE, 1); return this; } public ActiveCalendar midnight() { set(HOUR_OF_DATE, 0); set(MINUTE, 0); set(SECOND, 0); return this; } } Date date = new ActiveCalendar().tomorrow().midnight().getTime();
しかし、これは外延の継承、お勧めできない種類のもの。そもそもグレゴリオ歴じゃなくても明日はあるのだからGregorianCalendarの機能ではなくCalendarそのものの仕様を拡張するのが本筋。こういうタイプの機能拡張は、Calendarのデコレータを作成するのがベストだが、Calendarはインターフェースではないのでデコレータパターン難しい。
結局、日時操作のためのstaticなメソッドを集めたUtilsクラスなんてモノを作ることになってしまうのだが、これが最悪にださい。オブジェクト指向プログラミングの屈辱的敗北である。Javaの日付クラス設計のダメさについては散々言われていることだが、拡張性もダメダメ。ただ、これは言語仕様ではなくクラスライブラリ設計の悪さでJava言語そのものが悪いわけではないのだが…、
http://journal.mycom.co.jp/column/jsr/004/index.html
というわけで、JSR-310では拡張に対して開かれたクラス設計してほしい。で、何だっけ? Rubyはかっこいい。