[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()の実装を必ずオーバーライ
>ドしてください。これらの２つのメソッド間には、等値であると評価されたオブ
>ジェクトは必ず同じハッシュコードを返さなくてはならないという決まりがあり
>ます。」とあるが、実際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か
> ３つのガイドラインがあるが、妥当か？
----------------------------------------
個人的な主観も入るが，
・「ユーザーのデータ入力が適切でなかった」時にRuntimeExceptinを使って逃れる
・「ビジネスロジックのエラーの結果怒る場合」に「Exceptionを直接継承する」
の二つは賛成できない．
----------------------------------------
> 5.2.2 多すぎる例外
> 例外型は1つにして、そのフィールドにIDを設けて例外種類を複数扱えるよ
> うにしているが、妥当か？
----------------------------------------
なんか最悪な気がする．
だから
> 「新しい例外クラスを宣言する場合は、...<略>... 使用すべきです。」
> 「電気通信会社の仕事を...<略>...減らすことができました。」
> の部分を書き換えるように指示があるが、どのような意味だろうか？
この部分がバッサリ削除されると．
例外部分の記述については，なんだかLL的な観点から書かれている気がする．
では，お休みなさい．
--
murayama <locutus@xxxxxxxxxxxxxxxx>