2004BlogリファクタリングデザインパターンCommentsTweetPocket『『リファクタリング―プログラムの体質改善テクニック』の続編になっています。例のごとく、自分で読み直したときにどんな場合にどのリファクタリングが使えるかのメモにしようと思ってます。そのつど更新していくつもりです。(最終更新日:2004/10/29)本家サイトはこちらになります。カタログ一覧あります。Composite場合別リファクタリングカタログカタログ名のリンクをクリックすると、別ウィンドウで本家のイメージ図が開きます。一緒に見るとイメージがわくかも。パターンを用いることによって重複コードを減らすことができる。オブジェクト生成をポリモーフィズムで行うことで、オブジェクト指向っぽくなります。このリファクタリングを行った後のコードは、サブクラス間で重複した同じようなコードがなくなります。パターンはよく同時に使われます。Constructorsコンストラクタで似たような処理が重複している場合、このパターンで重複を除去できる。Composite一つのオブジェクトもしくはオブジェクトのコレクションを処理するコードが散らばっているような場合に、重複を除去できる可能性がある。Composite階層関係にあるサブクラスで、個々のクラスがコンポジット関係にある場合、実装はほとんど同じである場合が多い。そのようなときに使える。Adapter異なったインターフェースを持つからという理由で、単に違うオブジェクトを処理するのなら、Adapterと統一のインターフェースを利用して、共通のロジックを除去出来るかもしれない。場合に条件句で何の処理も行わない場合が多くある時、このパターンで重複が減らせるかもしれない。Method長くて理解しにくいメソッドがある場合、処理を構成する部分をわける。処理を区切るときの注意点として、同じ処理の詳細レベルになるようにメソッド化することがあげられる。メソッドや小さな処理単位のメソッドが非常にたくさんできる。リファクタリングを用いて、クラスを分けるなどして対応するとよい。Parameter情報を変換していく作業がある場合、処理を構成する別々のメソッドを定義して、処理の順番で一つの情報を構成するようにする。文など)によって処理を分岐させるようなコーディングは、ハードコードになり、新しい条件が付け加わったりリクエストが増えたりした場合に、修正が追いつかなくなる。パターンを用いるとよい。クラスを作ることで対応できるようになる。パターンを利用してデータを集めるようにする。パターンで置き換える。このパターンを使う動機の一つとしてこのようなことがあげられる。条件分岐のロジックを書く場合というのはよく、アルゴリズムを決めるためということが多い。Methodパターンを用いてこのロジックの部分をシンプルに、分かりやすくすることが出来る。パターンを使ってロジックをメソッドに分割すると、小さなメソッドがたくさん出来てしまう。Decoratorクラスの核となる責務を装飾するようなコードは、条件句で装飾をするかどうかを判断するのではなくて、装飾するコードをDecoratorクラスに委譲するようにする。Decorator(装飾するクラス)とDecoratee(装飾されるクラス)は同じインターフェースを持つ。オブジェクトのクラスが一致するかどうかを判定するような場合(instanceof演算子を使う場合)は注意する必要があります。Decorateされたインスタンスは、Decorateeと同じインターフェースを持ちますが、通常は継承関係にはないので、クラスが一致することはありません。クラスの同一性に依存するようなコードがクライアントにない場合にのみ、Decoratorパターンを使います。クラスは状態(フィールド)を持たない方がいいです。クラスは不必要な状態(フィールド)があったとしても、継承せざるを得なくなるからです。Stateオブジェクトの状態遷移が複雑になるとき、Stateパターンを使って状態遷移を簡略化する。状態遷移のロジックというのは、さまざまなところに重複ロジックが散乱することが多い。状態遷移のロジックを他のクラス(Stateクラス)に移動させることで、コードがシンプルになる。Methodパターンを適用する。Strategyパターンは、考え方の違いである(最終的なクラス図はほとんど同じ形)。Stateパターンは、状態クラスのインスタンス間で状態遷移のロジックが簡単になるように使われる。Strategyパターンは、ストラテジークラスのインスタンスにアルゴリズムの実行を委譲(delegate)する目的で使う。クラスを作って、型の安全性を保証したほうがよい。パターンを使うといいかもしれない。使うとクライアントはシンプルになる。クラスを用意することで、実装を知らずにクライアントは構造を組み立てることが出来るようになる。クライアントをCompositeの詳細から切り離したいCompositeパターンとBuilderパターンは同時に使われることが多い。理由は2番の動機のように、クライアントがCompositeの詳細を知らなくてもすむようにしたいから。Methodsクラスにコンストラクタがたくさんあり、プログラマーがどのコンストラクタを呼べばよいのか分かりにくい場合にこのリファクタリングが使える。用意したほうが良い理由は、メソッドに名前が付けられるから、どんな処理が行われるのか名前から判断できるから。Factory色々なクラスにインスタンス生成の情報が広がってしまっている場合、単一のFactoryクラスを作成することでシンプルになるかもしれない。インスタンス生成の役割は色々なクラスに広がるべきではない。今回のようなaStringNodeインスタンス生成の方法をaParser、aStringParser、StringNodeに散らばらせるのではなく、NodeFactoryを導入しインスタンス生成と設定をカプセル化すべき。(クラスには単一の責務のみを持たせるべきだから)生成するインスタンスがロジックによって違ってくるような場合、AbstractFactoryパターンを使ってFactoryを分けることで対応できるようになる。aParserにインスタンス生成の責務を負わせていると、条件分岐のロジックが重複してしまう可能性が高い。メソッドを用意して抽象に依存させるようにする。