[jfriends-ml 10279] Re: Effective Java 第 5 回議事録

[YAMASHIRO Shunsuke <felio@xxxxxxxxx>]

山城です。

読書会、お疲れさまでした。あの後実家に帰らなければならなかったので呑みに
は参加できず、残念でした。

> 項目38
> ■  昔はFQCNは大文字で書いていたが、いまは全て小文字

JP.gr.java_conf... というように最初だけ大文字だった記憶があります。古い
規格(?)のようですので、もう考えなくてもいいようですね(^^;

そのほかに、JUnit は junit というパッケージを使っているけどいいのか? と
いう話がでましたね。有名になったらこっちのもの、ってのも頂けない気がする
のは私だけでしょうか...。

> ■  ハンガリアン表記は、C#はハンガリアンは推奨していない。
> 　　FQCNでしか本当の形はあらわせないのでオブジェクトに
> 　　ハンガリアンするのはもうあきらめましょう。

つまり、これは「ボタン」といってもいろいろあるので、

  ok_button

としていても不明瞭なので、

  ok_java_awt_Button
  ok_java_swing_JButton

としなければならなくなる、って話ですよね。やはり通用するのは C のような
オブジェクト指向でない言語なのかもしれませんね。

> ■  com.speed()は field直結であることがイメージできない
>  　 com.getSpeed()なら fieldに対するgetterであると感じられる。
>  　 この例はよろしくない。

でも、国産の Ruby などでは get を省略することが多いようです。それは フィー
ルドに readable, writable フラグをつけられるようなものがあるからというこ
ともあるのですが。

> ■  asXXXX()は使わない。 toXXXXX()と区別つかない。

ここ、高橋徹さんと中華料理屋に行く途中に会話しているうちに、意味の違いが
ある気がしてきました。

 'to' は変換で、'as' はviewだと書いてあったように、

 * 'to' で変換したものをいじっても、元のほうには影響を与えない
 * 'as' で変換(?)したものをいじると、元のものには影響を与える

ということだと思います。java.util.Collection#toArray は得られた配列に対
する操作は元の Collection へ影響は与えませんが、java.util.Arrays#asList 
は得られた List への操作は元の配列へ影響を及ぼします。

> 項目39
> ■  P160上、この推奨利用方法は、スレッドセーフではない、これでいいのか
> 　for (Iterator i = collection.iterator(); i.hasNext();) {
> 　 Foo foo = (Foo) i.next();
>   ............
> 　}
(snip)

外部からいじられてしまうことが前もって予期されるときに、

 try{
  ...
 }catch(ConcurrentModificationException e){
  ...
 }

のようにして、それなりの措置をすればいいと思っていたのですが、
ConcurrentModicationException って RuntimeException を継承していたんです
ね。つまりチェックされない例外。これはキャッチされることを望まれてなくて、
しかも復旧不能を意味しているんですよね。readonlyなら問題ないかなぁとも思っ
ていましたが、怖いのでつかうのやめます(笑)

> 製品版にするときはスタックはファイルに落として画面は、「混雑しておりま
> す」くらいにしておいてトボけるのが吉。

(笑)

> ■　P182. double-checked lokingがなぜ動かないか。
>  private static Foo foo = null;
>  public static Foo getFoo() {
>   if (foo == null) {             <---- A
>      synchronized (Foo.class) {
>      if (foo==null)
>      foo = new Foo();
>      }
>   }
>   return foo;                    <---- B
> }
> 
> fooはまだ出来上がってはいないが、nullではなくなっている時、Aは不成立して
> B点で不完全なfooが返っていく。という理解であったが。
> しかし、そのうちfooは完成してしまうのでは？

'そのうち' は完成するかもしれませんけど、'そのまえ' にさわれれると困っちゃ
いますよね。だからだと思います。

ちょっと最後に。

CloneNotSupportedException がなぜ RuntimeException を継承したものではな
いのかについて考えてみました。確かに

  hoge.clone();

とかいたもので、しかも hoge#clone が Object クラスのもののままであったな
ら所謂 'バグ' なので RuntimeException を継承してあるべきです。

でも、reflection 経由になると 場合によっては catch 出来て復帰できる可能
性を残したほうが幸せになることがあるのかも...と思いました。

#うーん、3点(自己採点)
-- 
YAMASHIRO Shunsuke <felio@xxxxxxxxx>