refactoring

Author: tam315

books/refactoring.md

@@ -941,7 +941,7 @@ describe('', () => {
 
 - if や switch では複雑になりすぎる場合に利用を検討する
   - オブジェクトの種類によってコードのいたるところで条件分岐が散在している場合など
-- (読んだけどやはり時代遅れ感)
+- (読んだけどやはり時代遅れ感あり。fp ではどうやるんだろう)
 
 ### 特殊ケースの導入
 
@@ -968,10 +968,50 @@ describe('', () => {
 
 - 問い合わせは蓋然性が高く、どこにでも移動でき、テストも用意
 - 値を返すにもかかわらず、観察可能な副作用があるメソッドがあったら、必ず分離する
-  - 観察可能 = 例えばデータ取得時にキャッシュ層で値が変わるのは観察不可能なので OK
+  - 観察可能 = 例えばデータ取得時にキャッシュ層で値が変わるのは観察不可能なので許容される
 
 ### パラメータによる関数の統合
 
-- ほとんど重複コードだけど使われている定数がちょっと違うだけの関数群は、定数をパラメータで与えることで、統合せよ
+- ほとんど重複コードな関数群があって、違いは使われている定数がちょっと違うだけの場合は、定数をパラメータで与えることで関数群を統合せよ
 
 ### フラグパラメータの削除
+
+- フラグパラメータ（フラグ引数）は使うな
+- 理解しにくいから
+- 特に bool リテラル値は最悪
+  - ただし bool がデータ型として与えられている場合はフラグ値とはみなさない場合もある
+- フラグ引数が多すぎる場合は問題を整理できていない可能性あり
+
+### オブジェクトそのものの受け渡し
+
+- オブジェクトから数個の値を抜き出して関数に渡しているなら、オブジェクトそのものを渡す
+- ただしこのリファクタをしたくないこともある
+  - 例えば依存関係をもたせたくない場合など
+  - そういうときは「特性の横恋慕」が疑われるので、ロジックの場所を移すべきではないか、考えてみるとよい
+
+### 問い合わせによるパラメータの置き換え(またはその逆)
+
+- （順）パラメータで渡すまでもなく問い合わせで計算可能なものは、削除する
+- （逆）関数内部で行われている問い合わせを、パラメータに置き換える
+- どちらがいいかは状況による
+- 一つ言えるのは、参照透過性(パラメータが同じなら結果が同じ)は大事だということ
+- よくあるパターンは、参照透過性を持つ純粋関数群を作っていき、それらをラップして副作用のある関数と組み合わせて使うというもの
+
+### setter の削除
+
+- 不要な setter は消して可能な限りイミュータブルにしようね
+
+### ファクトリ関数によるコンストラクタの置き換え
+
+- コンストラクタはいろいろな制約があるからラップして使え、とのこと
+- (時代遅れ感)
+
+### コマンドによる関数の置き換え
+
+- クラスを使うことで、入れ子関数と同じようなことを実現する
+- (入れ子関数でよくないか？)
+- 「関数によるコマンドの置き換え」という逆パターンもある
+
+## 継承の取り扱い
+
+(省略)