« 小悪魔ペン入れ | メイン | メールから記事を投稿 »
2005年11月24日
Javaの嫌いなところ。 [プログラミング]
最近大学でめっきりJavaばかり弄るようになった。Javaはどうにも全般的に好きになれない。概ねはいいのだが、いくつか不便な点があるからだ。Javaのここが嫌いだ。
プロパティの扱い
オブジェクト指向言語において、フィールドの可視性を private にするのは、もはや変える事のできない慣習となっている。その上で用意するのが、変数にアクセスするための専用のメソッドだ。
幾つかの言語には、プロパティという概念がある。VBやC#などがそうだ。しかしJavaにはない。Javaが用意した解決策は、それらの替わりに setなんたら / getなんたら という名前を持たせるというものだった。
これには幾つかの問題がある。まず外部から見た場合、このメソッドがプロパティであるのかメソッドであるのか判別することができない。そして何よりも、getter/setter によってラップされたプロパティに対して、演算子を用いることが出来ない。次の例を見てみよう。
point.x += 10;
これはプロパティを持つ言語による表記だ。xというフィールドの値を10加算しているというのが一目でわかる。しかしJavaで書くと、こうなるかもしれない。
point.setX( point.getX() + 10 );
ごく単純な加算にもかかわらず、記述がひどく冗長になる。前例ではやりたいことが明白だが、この例ではとてもわかりにくい。
一般の変数型がオブジェクトじゃない
int や boolean などの変数型は、java.lang.Object を継承してない。これはどんな不便さがあるだろう。
int num = 1; // int型の変数を宣言
ArrayList list = new ArrayList(); // 可変長配列を宣言
list.add( num ); // int変数を配列に追加
これだとエラーになる。ArrayList#add メソッドの引数が、Object 型しか取らないからだ。intはObject型を継承していないので、このままでは配列に含めることが出来ない。配列に追加するには、StringかIntegerに変換してやらなければならない。
list.add( Integer.toString( num ) );
追加だけではない。取り出すときも、再度 int 型に直す必要がある。
int num = Integer.parseInt( list.get(0) );
ただ Object を継承していないというだけで、これは実に面倒だ。ArrayList だけでない。HashMap のキーにすら、int は含めることが出来ない。
プリプロセス式で条件コンパイルが出来ない
C言語にあった、#if や #endif、 #define などのプリプロセス式がJavaでは使えない。とりわけ #if による条件コンパイルは、デバッグ時に役に立つ。
条件コンパイルが使えないということは、デバッグのためのコードをプログラムの内部に含めなくてはいけないということだ。これではメンテナンスが低いし、バグの温床になりかねない。
クラス間の互換性が低い
似たようなクラスがいくつもある割には、それらの間の互換性が低く、かえって扱いにくい。
例えば時刻を扱うクラス。java.util.Date の他に、java.util.Calendar や java.util.Timestamp、java.sql.Date などがある。これらはそれぞれ役割が違うが、相互変換が難しい。Calendar で欲しいのに、Timestamp しか用意できないときなどがある。それらをいちいち変換していくのは、非常に面倒なことだ。SQLとの愛称もある。結局時刻型の全面使用は諦め、素直にlong型で済ませることもある。
投稿者 : 16:27 | コメント (0) | トラックバック (0)
トラックバック
このエントリーのトラックバックURL:
http://totora.jpn.org/mt/mt-tb.cgi/75