[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 12321] Re: ズームイン Java(5/13) 予習



村山です.

適当にコメント追加.
寝ぼけ眼でざっと見ただけなので,あまり見直してません.

----------------------------------------
>P93(4.2.1)
>「equals()をオーバーライドする際には、hashCode()の実装を必ずオーバーライ
>ドしてください。これらの2つのメソッド間には、等値であると評価されたオブ
>ジェクトは必ず同じハッシュコードを返さなくてはならないという決まりがあり
>ます。」とあるが、実際equals()を実装する時に、trueを返す直前に両者の
>hashCode()の値が一致しているかを確認するコードの追加を強制できないだろう
>か? assertを使うべき?
----------------------------------------
可能かもしれないがコスト高.むしろFindbugsの出番だと思う.

いずれにせよ,この辺を実装する人はEffectiveJavaを再確認すべし.
セマンティクスの定義の問題なので,Findbugsのようなツールを使っても
完全にはチェックできない.

----------------------------------------
>P96(4.2.2)
>Errataのページを見ると、
>「Remove the following sentence
>Generally, algorithms higher than O(n) are not feasible as solutions to
>practical problems」
>
>とあるが、どのような意味だろう?
----------------------------------------
O(n)より大きい計算量だと現実的でないというが,実際には問題が複雑な
場合は一般のソートのようにO(n log n)が最低ラインなものや,それ以上と
いうものも多い.有限要素法,気象シミュレーション,巡回セールスマン問題
などでは多分もっと大きい.

計算量がO(n)〜O(n^2)以下で済むのは比較的簡単な問題に対してだけで,
世の中には多項式オーダーでも計算できないような問題はいくらでもある.
そうでなければモンテカルロ法とかSA法(焼き鈍し法)とか遺伝的アルゴ
リズムとかの存在意義がない.

----------------------------------------
>P100(4.2.4.1)
>  Errataのページを見ると
>  「[98] Figure 4-3 
>    Replace entire figure with this one -
>	http://examples.oreilly.com/hardcorejv/Hashtable.png 」 
> とあるが、図の変更にはどのような意味があるのだろうか?
----------------------------------------
普通はそういう風に実装するってだけでは.

たとえば
public int hashCode(){ return 1; } // 最悪
の場合は論外にしても,

// indexはインスタンスが生成された順に,
// 1から100まで順に付けられる.
public int hashCode(){ return index; }

のような場合に,修正前は最悪な結果を生むことがあるが
修正後の方はそれなりに動く.

----------------------------------------
>P109(4.5.2)
>「Jakarta CommonsのLangライブラリには、高品質のハッシュコードを容易に作
>成するユーティリティが含まれています。http://jakarta.apache.org/ でこの
>ユーティリティを調べることを強くお薦めします。」
>とあるが、いったいどのようなユーティリティだろうか? 私は知りません。(^^;
----------------------------------------
org.apache.commons.lang.builderパッケージの
EqualsBuilderとHashCodeBuilderかな?
#手元のオンラインマニュアルによる.
#今の最新パッケージでも同じかどうかは未確認.

Jakarta Commons CookbookのP10,
1.6,Automating hashCode() and equals()参照.

----------------------------------------
>P115以降(5章以降)
>  try/catchのcatchの変数に final が付いてコードで書かれているが、この
>  final にはどのような 意味(利点)があるのだろうか? P56(2.3 finalパラメー
>  タ)と同様に解釈して良いか? 推奨される
>  書き方なのか?
>  例: try {
>        ...
>      } catch (final Exception ex) {
>        ...
>      }
----------------------------------------
あまり深い意味はないと思う.

----------------------------------------
>P124〜P125(5.2.2)
>  Errataのページを見ると
>  「新しい例外クラスを宣言する場合は、...<略>... 使用すべきです。」 
>  「電気通信会社の仕事を...<略>...減らすことができました。」 
> の部分を書き換えるように指示があるが、どのような意味だろうか?
----------------------------------------
要するに,
「一個の万能例外クラスを作るよりは,各例外が表す概念ごとに
 異なるクラスを一つずつ作りましょう.」
という,ごくありきたりの解説をしているだけだと思う.
#これもEffectiveJavaにあったような...

----------------------------------------
>P133〜P134
>  Errataのページを見ると
>  「しかしながら、これでもまだ例外に...<略>...変数を使用すればよいのです。」
> という部分をばっさり削除するように指示があるが、どのような意図だろうか?
----------------------------------------
#原書エラッタ<129> Last Paragraph 云々

例外を握りつぶしているからでは?普通は推奨されないはず.

----------------------------------------
> 5.1.2 RuntimeExceptionのサブクラス
>   検査例外をcatchして非検査例外RuntimeExceptionに乗せ換えてthrowしてい
> るけど、これってよいのか?
----------------------------------------
状況による.普通は余り好ましくなく,例外的に許されることもある.
#これに関係する話もEffectiveJavaに載っていた気がする.

----------------------------------------
P122
> 5.1.3 ExceptionかRuntimeExceptionか
>   3つのガイドラインがあるが、妥当か?
----------------------------------------
個人的な主観も入るが,
・「ユーザーのデータ入力が適切でなかった」時にRuntimeExceptinを使って逃れる
・「ビジネスロジックのエラーの結果怒る場合」に「Exceptionを直接継承する」
の二つは賛成できない.

----------------------------------------
> 5.2.2 多すぎる例外
>   例外型は1つにして、そのフィールドにIDを設けて例外種類を複数扱えるよ
> うにしているが、妥当か?
----------------------------------------
なんか最悪な気がする.

だから
>  「新しい例外クラスを宣言する場合は、...<略>... 使用すべきです。」 
>  「電気通信会社の仕事を...<略>...減らすことができました。」 
> の部分を書き換えるように指示があるが、どのような意味だろうか?
この部分がバッサリ削除されると.

例外部分の記述については,なんだかLL的な観点から書かれている気がする.



では,お休みなさい.

-- 
murayama <locutus@xxxxxxxxxxxxxxxx>