読書会(リファクタリング - プログラミングの体質改善テクニック)第4回議事録
[ 戻る ]
2003年 2月22日 リファクタリングを読む会第 4 回
議事録 第８章(p169)より
出席者 高橋智 宮本 村山 門脇 大昌 新井 根本 福嶋 高橋徹 三間
第８章
■ 自己カプセル化はすべきかどうかの判断材料。
カプセル化したい動機
遅延初期化したいフィールドある時。
サブクラスが取り出しメソッドを変更したいとき。
しかしＡＷＴのソースコードでさえ内部にスーパークラスの
フィールドに直接アクセスしている。
必ずしも自己カプセル化は必須ではない。
注意点
Ｊａｖａの格言:クラス初期化中内部ででセッターを使うな、
制御がほかに移るかもしれないから。
■ オブジェクトによるデータ値の取り替え
■ 値から参照への変更
■ 参照から値への変更
■ オブジェクトによる配列の置き換え
■ コンポジションから参照に変換
■ 観察されるデータの複製
静的なディクショナリ レジストリオブシェクト とは？
-> java.util.dictionary
値から参照への変更は、ＥＪＢ化したほうが自然な流れでは？
値オブジェクトを作るくらいならEJB化したい。
不変なバリューオブジェクトとは、いったい何か。
オブジェクトによる配列の入れ替え
逆のリファクタリングはない。
IntervalWindow
Observerとは・・・
setMethod -> notify -> updateの流れ
これは無限ループになりえる →同じ入力値ならnotifyを
呼ばない、とかで対応可能。
実装には注意が必要。
Observableを使う。
Swingの方がコンボボックスとかにクラスが分かれているので、作りやすい。
AWT --> SWT に行く。
EJB + flush で、つくれるか。
addListenerとかはある。
■単方向のリンクの双方向への変換
使う場面あるのか？最初からEJBエンティティービーンとして作れば
おのずと双方向リンクとなり問題にはならない。
またeualsメソッドに対して、JVMをまたいで有効にオブジェクト比較が
可能なのでなるべくここは比較する可能性のあるオブジェクトはEJBにしたい
lookup table持てばそれで解決するばす。
多対多の関連の場合はvisitorパターンで解決するらしい。
--> 多分このパターンには別な名前がついている "Double Dispatch" では？
アナリシスパターンにも同じアイデアが書いてあって、しかも概念のみなので
読んでもわかりにくい。
■双方向関連の単方向への変更
■フィールドのカプセル化
■シンボリック定数によるマジックナンバーの置き換え
定数だけ書き換えてもantは反応しない、そのクラスしか書き換えない
最適化が効いてクラス内部にとりこまれる。
finalをはずしたらクラス内にもフィールドを持てる、
コーディング規約的にはgetterで書くべき。
静的な値であってもgetter必要、
たとえば税率、季節や州で変わったときに変更させたい時に有効。
getterもなるべくファナライズしておいた方が良い、
サブクラスで置き換えるかどうかは設計次第。
でもstaticは、置き換え不可能なので困る、こういう時は自己カプセル化すべき。
static finalにしたら遅延初期化は不可能inline化できない。
フィールドにも getter setterをつける
■コレクションのカプセル化
■データクラスによるレコードの置き換え
こればＴＣＰヘッダーの解読みたいな、
バイト列の処理をどんなときにするかの話、らしい。
■クラスによるタイプレコードの置き換え
値オブジェクトは変更不可能な値を持つだけのクラスであることはありえる。
自分で持つときは、インナークラスで持つか、無名クラスはほかから見えない。
構造体のようなクラスの処置。
■サブクラスによるタイプコードの置き換え
ここは一発インナークラスを使って対応すべき。
ここで Factory State Strategy の各々の使い分けを考察したいが
■その他
今はホームページでjfriendsの過去ログは公開していない、
いずれCross Site scriptingに対して耐性のある形で公開したい。
enterprise Architectは２万円にしては、かなりイケそう、30日トライアルが
ダウンロード可能、詳しくはDP/ML か www.sparxsystems.com あたり参照、
Use Caseとは別にAnalysisというclass図っぽい企業モデリングもあり。
以上
根本和郎 記
[ 戻る ]