-・重複した条件記述の断片の統合catch文(ケース)の中に例外が多いとエラー処理が複雑になる。2)処理はシンプルにしている。⇒スイッチ文のバターンがあると良い。⇒ここのサンプルについて例が多いと良い。-・制御フラグの削除1)構造化プログラミングではreturnは一つしか記述しなかったが、ここでは途中でのreturnを許している。2)フラグ減らす効果がある。⇒言語としてコンパイル時にチェックしてくれるとうれしい。-・カード節による入れ子条件記述の置き換え1)if文内の条件の変更時にドモルガンの法則を使っている。⇒条件式を修正したときに間違えそう。-・ポリモーフィズムによる条件記述の置き換え1)switch文の中のgetTypeの表記に誤りがある。P258よりメソッド「getType()」であることがわかる。2)継承ではなくインターフェースでもいいのでは?⇒P259L1「男の子が昆虫を殺す方法」・・・例えの意味がわからない。-・ヌルオブジェクトの導入1)80を超えるNullオブジェクトとは、カスタマークラスのNullチェックをしていたのをオブジェクトにしているのではないか。このようにNullオブジェクトがあるのはビジネスロジックとDB(実装)と切り離しているのではないか。⇒Nullオブジェクトを扱うのは使い方の概念が難しい。-・表明(アサート)の導入1)JDK1.3までのため。JDK1.4からは言語にAssertが追加され不要。〔自分の意見・決心などを〕人前にはっきりと示すこと。⇒「オブジェクト指向の世界で最も重要なのはインターフェースです。⇒Googleでメソッド名(クラス名)を検索して、検索結果が多いと比較的一般的な名前と判断できる。*.javaを行う場合は出ない。⇒ポリモーフィズムがある場合の引数の削除の場合は100%変更結果は保障されない。継承ではなくインターフェースがよい。-・問い合わせと変更の分離1)テスト操作・・・問い合わせ。⇒サンプルのメソッドを置き換えているの「deprecated」とかの記述がない。・明示的なメソッド群による引数の置き換え1)静的に決まっているもののみに使える。無理にFactoryPatternにしなくても良いのでは。・オブジェクトそのももの受け渡し1)オブジェクトそのももの受け渡しを行う際には、オブジェクトのメソットがリードオンリー宣言がされていないと、マルチスレッドで動作している場合では参照先で書き換える危険性がある。⇒状態を変更しない宣言(const)が欲しい。getPrice()が最後にprivateになっている。⇒Rangeパターンのような小さなパターンからanalystパターン、Enterpriseパターンのように業務全体の範囲を示すパターンがある。メソットを摘出してくれるツールとしてJTest、JLint(free)、PMD?(free)がある。⇒CVSを自動で夜間JTestを実行して、朝に担当者に修正しなさいとメールを出してくれる機能がほしい。⇒JDK1.5のリリースは夏ぐらい(らしい)。