読書会(リファクタリング - プログラミングの体質改善テクニック)第7回議事録

[ 戻る ]

2003年 5月17日 リファクタリングを読む会 第7回
議事録「リファクタリング」第12章 P370 〜 第15章 P412
　　　Refactoring Home Page のリファクタリングカタログ
（http://www.refactoring.com/catalog/index.html）から新たに追加された１３の
リファクタリング(newマーク)
出席者 山本、高橋(智)、角野、百瀬、内脇、宮元、村山、布留川、金井、高橋
書記   角野

■第１２章大きなリファクタリング

●プレゼンテーションとドメインの分離

・P370 ４段落目
２層というとは、結局どちらかに含まれるのでは。
DB側にロジックを持たせるような場合は、ストアドプロシージャやトリガーを
使うということか。

・P372 ３段落目
package java.sql を見つけて判断するのは実に単純な方法ですね。
しかし、java.sql.Timestamp等のデータクラスは、そのままプレゼンテーションでも

使いたいことが多いので、package java.sql を簡単には除けないのでは。

●階層の抽出

・P376 バリエーションがはっきりしない場合の手順の３番目の意味
まず、条件分岐を持つメソッド全体をサブクラスをコピーする。
サブクラスには、そこに必要な部分のみを残し、後は取り除く。

・P376 バリエーションが明白な場合について
P34〜P51の例(料金計算の条件文をポリモーフィズムに置き換える)が例になってい
る。
Stateパターン、Strategy パターンで対処することは自然に考えやすい。

・P378 複数の分類条件について
条件（本文では障害者特約と法人契約）が排他的でない場合は、
組み合わせ爆発をおこさないか。

・実際の現場では、フラグを導入して条件分岐して対応するのは簡単なので、
こういうケースはかなりある。とくに、複数のプログラマーが、
さまざまな意味でフラグをどんどん導入するので、わけがわからないコードに
なっている。

・特に、同じ意味の条件分岐が、複数メソッドに散らばっている場合には、
このリファクタリングは有効ではないか。

・すべての条件分岐に対してこのリファクタリングを行う必要があるのか。
「仕事をしすぎているクラス」かどうかの判断がまずあるとおもう。

・togather control centerには、クラスの複雑さを判断する機能がある。
外注からの納品のチェックに使えるかも。

■読書会の本について
Javaを直接取り上げた本に限定しているわけではなく、
投票で決まったものを読むことにしています。
Java以外の言語でかかれたものでもJava置き換えて議論すればよいと思います。

■第１３章　リファクタリング、再利用、現実

●現実性チェック

・P380 「現実性チェック」第１段落第２文
そうした製品には、呼（→呼び出しの意味か）の処理に対して信頼性....

●開発者が自分たちのプログラムをリファクタリングしようと思わない理由

●リファクタリングをする方法と場所を理解する

・P383 16行目
実用的な自動化ツールは果たしてあるのか。

●C++プログラムのリファクタリング
・この文章は、どこかほかの本/雑誌からもって来た文章のように感じる。

・言語の特徴とリファクタリングを支援するプログラミングスタイル
Smalltalk とC＋＋の比較について書かれていて、Javaは意識されていない。

・リファクタリングを複雑にする言語の特徴とプログラミングスタイル
第２段落　エイリアシングの意味について
ポインタをint型、void*型ヘ変換されると参照関係は追いかけられず、
リファクタリングの障害になる。

●リファクタリングで短期的な利益を享受するには
短期的な利益はこれで得られると主張してるとは思えないがどうだろう。

●ソフトウェア再利用および技術移転に与える影響
第４段落第１文
「釣鐘型」について
国や業界によって、左、中、右の分類の割合が異なるという話がある。
JavaやJavaのリファクタリングツールが出てくることで、
真ん中の人たちにもリファクタリングは普及しつつあるとおもう。

■第１４章　リファクタリングツール
●リファクタリングツールの実践的規範
P406
・取り消し(undo)
リファクタリングの過程で途中のステップの状態に戻せる機能がほしい。
・ツールとの統合
Eclipse にリファクタリングがついているわけですね。

・設計書との同期をとる作業がリファクタリングの障害のひとつになっている。
　公共事業、大きな会社での受注では、詳細設計書の変更にも承認が必要で、
　リファクタリングのコストが大変。
　コードから生成されるJavaDoc のようなものはだめか。
　（エクセルフォーマットを要求されることもある）

・Delfi のリファクタリングツールがほしい。
　
■第１５章　部品から全体へ
（記録者：角野は予習していなかったので議論が十分に理解できずに
　正確に記録できていません。ごめんなさい。フォローお願いします。）

■Refactoring Home Page のリファクタリングカタログ
（http://www.refactoring.com/catalog/index.html）から新たに追加された１３の
リファクタリング(newマーク)

●Convert Dynamic to Static Construction

・Mechanics 1行目の意味
このリファクタリングによる変更を１箇所にするため、オブジェクトが生成される
を１箇所にまとめるということ。

●Convert Static to Dynamic Construction

・Dynamic Constructionの目的は生成オブジェクトのクラスへの静的な依存関係を
持たせたくないため。

・リファクタリング後のコード３行目
DataProvider dp = (DataProvider)
    Class.forName("org.davison.data.jdbc.JDBCProvider").newInstance();
コード中のclass.forName () の引数に直接クラスの静的文字列ではなく、
変数として渡すほうが例として自然ではないか。

・Example 12行目
Here I have chosen to convert them to the equivalent Java Errors in order to

maintain the interface.
the interface とはこの処理が書かれたメソッドのシグニチャにあわせるため。

●Extract Package

・Motivation ４行目
The structure produced here is also one that is recommeneded for use with
the Abstract Factory pattern. Indeed this is how the example I have provided

is structured.

Abstruct Factory パターンを導入しやすくなるという意味ではないか。
パッケージ内で暗黙にアクセスできるので、パッケージを分けることで、

・クラス名にJDBCをつけるひつようはないのではないか。
パッケージ名がクラス名の頭についているようなものもよく見かける。
それほど、複数のパッケージに同名のクラスもあるので、おかしくはないとおもう。


・Additional Commentの第３パラグラフ
Then I work on the extracted package. This may compile fine, the problem
lies if you have a class in the extracted package referring to a class in
the original package. I move it back if I can. If not I use Extract
Interface to create an interface which captures the way the classes in the
extracted pacakge refer to the original class. I then place the extracted
interface in the extracted package.

依存関係から必要だったら、Extract Intercea/Extract Superclass にする
必要がある？（宿題です。）

●MoveClass

・Eclipse では、クラス名の文字列リテラルのチェックできる。

●Reduce Scope of Variable

・C言語の経験者のなかには、メソッドの先頭ですべての変数宣言するひとがいる。
・パフォーマンスについて
　条件分岐によって不必要な初期化が除けるので、パフォーマンス的にも意味があ
る。

●Remove Double Negative

・Mechanics 7行目
Consider using Substitute Algorithm if the positive form is difficult to
understand.
分岐条件を示すメソッド名を反対語(positive form)で表現しにくい場合には、
もとのアルゴリズム自身を変更するという意味ではないか。

◎ここからは高橋さんが各リファクタリングの簡単な説明があった。
●Replace Assignment with Initialization
●Replace Conditional with Visitor
●Replace Iteration with Recursion
●Replace Recursion with Iteration
●Replace Static Variable with Parameter
●Reverse Conditional
●Split Loop

■次回からのテキストは英文ですが、読書会の進め方について、
　アイデアがあれば、メーリングリストに書いてください。

[ 戻る ]