読書会(Effective Java (Second Edition))第6回議事録

[ 戻る ]


Java読書会 「Effective Java 第2版」を読む回(第6回)議事録

日時 : 2009/1/17(土) 10:00-17:00
場所 : 中原市民館
出席者:石黒、岩室、遠藤、尾関、門脇、高江州、高橋(徹)、高橋(智)、前山、村山、吉本(書記)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

■項目40
 ・「疑わしい場合にはやめる」とはどういう意味か
   →便利なメソッドの効果がはっきりとしない場合は提供を止めるということでは。

 ・「速記」とは?
   →ソースを簡潔に書くということだと思われる。

 ・【誤植】P183 6行目の「セッター」の後に「を」が抜けている。

 ・booleanより2つの要素を持つenumの方を使う。
   →真偽値ではない2値を取る変数をbooleanにすること自体が良くないということ。

 ・staticなnewInstanceメソッドを使うメリットは?
   →newを使うと特定のクラスに縛られてしまう。
   →項目1のネタそのもの。

■項目41
 ・JDKの中には、オートボクシングが導入されて、壊れてしまったメソッドがある。
   →removeなどはオートボクシングが存在しなかった時代のものなので仕様が無い。
   →同じremoveなのに、SetとListで値と位置を要求する仕様も問題。
   →removeAtの方がいいとは思うが、もう変えられなくなっている。

 ・contentEqualsメソッドは、パラメータにインターフェースを使った方がいいという良い例。
   →ハードコーディングされているので、もう直せない。

■項目42
 ・minにMAX_VALUEで初期化しないと、for-eachループが使用できないとはどういうことか。
   →for-eachループは、0番目から始めてしまうので、minの初期値を事前に設定しておかないといけない。

■項目43
 ・toArrayメソッドを使う理由は?
   →値が入っているかもしれないcheeseInStockの配列を返す必要があるから。

 ・配列クラスに最初から空配列のインスタンスを持つようにしてもいい。
   →言語仕様で対応してくれてもいい。
   →nullを返せない仕様になってもいい。
   →そもそもjava.langと違って、java.utilは言語仕様とは一線を画している。

 ・Listのパラメータにクラスを指定するのが面倒。
   →Listはクラスを知らないのだから仕方が無い。
   →new T やT[]が出来ないのと同じ →コンパイルエラーになる。
   →ドットネットでは出来る場合もあるが、デフォルトコンストラクタしか呼べない。

 ・Collections.emptyList()で問題ないのか?
   →Listが戻るはずなので問題ない。
   →オブジェクトが空のListが返るだけなので、呼び元も問題ない。
   →Listをnewして返してもいいのでは?
    →パフォーマンスの問題があるのかもしれない。

■項目44
 ・概要は動詞句となっているが日本語ではどのように書けばいいのか?
   →主語がなければいいのでは。
   →Eclipseでは、「/**」と入力するとドキュメントを補完してくれるが、も補完してくれるのか。

■項目45
 ・特になし

■項目46
 ・for-each文では現在のindexは取れるのか?
   →取れない。
   →知りたい場合は、別に変数を用意する必要がある。

 ・for-each文が入るまで、要素を列挙しないfor文はどうして入らなかったのか?
   →1.5まで、Iterableインターフェースが無かったため。
   →コレクションは元々言語仕様ではなくライブラリ扱いだったこともある。

 ・for-each文をソース1.5、ターゲット1.4でコンパイル可能か?
   →Iterableインターフェースがそもそも存在しないので、コレクションはダメかもしれない。
   →配列は裏でindexに変換されていそうなので、可能かもしれない。

■項目47
 ・Integer.MIN_VALUEでMath.absメソッドを実行するとMIN_VALUEが返るようになっている。
   →MIN_VALUEが32ビットの対称性の外にあるため。

■項目48
 ・0.39999・・・となるのは表示上だけの問題か?
   →実際の値も0.39999・・・で持っているので、処理も正常に出来なくなる。
   →浮動小数点の計算上の誤差が蓄積しているため。
   →CPUによっても動作が異なると思われる。(何ビットで演算されているのかによる。)
   →Javaでは、strict-fpだとCPU非依存で計算される。

 ・PHPやRubyでは浮動小数点はどうなっているのか。
   →PHPでは既に破綻しているはず。
   →Rubyでは、BIgInteger相当のクラスが使われる。
    →小数点があれば自動的にテキストが使われたはず。

■項目49
 ・特になし

■項目50
 ・staticなcompoundKeyのような使い方をする場合はリテラルの方が楽。
   →この項目ではクラスでそれぞれをフィールドとして持つ方法がいいということと思われるが
    大量にある場合はコンストラクタを羅列したくない。
   →やはり使う方ががんばればいいこと。

■項目51
 ・特になし

■項目52
 ・特になし

■項目53
 ・P225のコンパイルエラーはどの部分で出ているのか?
   →newInstanceの呼び出しの部分だと思われる。

■項目54
 ・特になし

■項目55
 ・publicの型を可変にすることは、不必要に多くの防御的コピーが必要になる。
   →immutableかどうかの問題。
   →finalかどうかではなく、ここではセッターを持たせないということ。

■項目56
 ・JavaBeansの場合、booleanを返すメソッドの命名ルールは、isXXでもgetXXでもいいはず。

■項目57
 ・parseIntで例外を返して欲しくない。
   →しかもランタイム例外が返ってくる。

 ・例外的状態ってそもそも何?
   →File.openはともかく、closeは要らないのではないか。
   →処理上での正常、異常の状態はあるが、戻り値でも可能なはずでは?
   →例外を使うべき状態の境界が曖昧。
   →そもそもエラーと例外の境界も曖昧。
   →Javaでは戻り値が1つしか返せないため、例外を使わざるを得ないということもある。
   →回復可能なエラーと不可能なエラーの違いも曖昧。
   →チェック例外とランタイム例外も曖昧

以上
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

次回は項目58から


[ 戻る ]