横流しブローカーの除去(Remove Middle Man)

◯ リファクタリングすべき時 クラスが単純な委譲をやり過ぎている。 ◯ リファクタリングした方がいい理由 委譲オブジェクトに追加するメンバが増えてきた際、サーバーに委譲メソッドを追加する負担を抑えるため。 ◯ リファクタリングコード refactor(remove…

委譲の隠蔽(Hide Delegate)

◯ リファクタリングすべき時 クライアントがオブジェクト内の委譲クラスを呼び出している。 ◯ リファクタリングする理由 変更の影響が及ぶのがサーバーまでに限られ、クライアントには影響が及ばなくなる。 ◯ リファクタリングコード refactor(hide delegat…

クラスのインライン化(Inline Class)

◯ リファクタリングした方がいい状況 クラスが大した仕事をしていない。 ◯ リファクタリングコード refactor(inline class) ◯ テストコード # rspec describe Person do let(:person){ Person.new } describe 'telephone_number' do before do person.offi…

クラスの抽出(Extract Class)

◯ 適用すべき時 2つのクラスで行うべき仕事をしている1個のクラスがある。 ◯ リファクタリングした方がいい理由 クラスが大きすぎると、簡単に理解できない ◯ リファクタリングコード refactor(extract class) ◯ テストコード # rspec describe Person do …

フィールドの移動(Move Field)

適用すべき時 フィールドが、自分のクラスよりも他クラスからよく使われている。 リファクタリングコード(1) refactor(move field) リファクタリングコード(2) refactor(move field)<自己カプセル化フィールドの使用> テストコード describe Account…

メソッドの移動(Move Method)

◯ 適用すべき時 メソッドが、自分のクラスよりも他クラスの機能を使ったり、他クラスから利用されたりする。 ◯ リファクタリングした方がいい理由 メソッドを移動すると、クラスは、関連する機能を簡潔に実装した単純なものになる。 ◯ リファクタリングコー…

evalを実行時からパース時へ(Move Eval from Runtime to Parse Time)

◯ 適用すべき時 evalを使わなければならないが、evalの実行回数を減らしたい。 ◯ リファクタリングコード refactor(move eval from runtime to parse time) ◯ テストコード # rspec describe Person do before do class EmployeeNumberGenerator; end end …

動的レセプタの分離(Isolate Dynamic Receptor)

◯ 適用すべき時 method_missingを使っているクラスが容易に書き換えられなくなってきている。 ◯ リファクタリングコード 動的レセプタの分離(Isolate Dynamic Receptor) ◯ テストコード #rspec describe Recorder do let(:recorder){ Recorder.new } descr…

Replace Dynamic Receptor with Dynamic Method Definition

適用すべき時 デバッグが大変なmethod_missingを使わずに、動的に定義したいメソッドがある。 リファクタリングコード(1) method_missingを使わない動的な委譲 テストコード(1) #rspec describe Decorator do let(:post){ Post.new } let(:decorator){…

Dynamic Method Definition

◯ 適用すべき時 動的に定義すれば、もっと簡潔に定義できるメソッドがある。 ◯ ポイント コードの重複が出てきた場合は、動的定義に切り替える 動的定義にすると、メソッド定義での誤りが減る 「動的メソッド定義」の最大の目的は、読みやすくメンテナンスし…

Remove Unused Default Parameter

◯ 適用すべき時 引数がデフォルト値を持っているが、その引数を指定せずにメソッドが呼び出されることはない。 ◯ ポイント ソフトウェアでは、使われていない柔軟性は悪である。 (使われていない)柔軟性は、メンテナンスのために時間を食い、バグが入る余…

Introduce Named Parameter

◯ 適用すべき時 呼び出しているメソッドの名前からは、使われている引数の意味が簡単に推測できない。 ◯ ポイント 引数リストをハッシュに変換し、ハッシュキーを引数の名前として使う 処理が委譲されているオブジェクトの公開インターフェースを明快にする…

Introduce Class Annotation

◯ ポイント 宣言的な構文でコードの目的が明確につかめる場合に適用すると、コードの意図を明確にできる ◯ リファクタリングコード refactor<introduce class annotation(クラスアノテーションの導入)> ◯ テストコード search_criteria_spec.rb※参考資料…

Extract Surrounding Method

◯ ポイント ユニークなコードが中央にあるメソッドを抽出する時に適用する インフラストラクチャコード(ex. コレクションを反復するためのコード)を隠して、ビジネスロジックを前面に押し出すことができる ◯ リファクタリングコード refactor(Extract Sur…

Replace Loop with Collection Closure Method

ポイント ループを取り除いてコレクションクロージャメソッドを使うと、コードをたどりやすくなる。 コレクションクロージャメソッドは、コレクションの中を行き来したり、派生コレクションを作ったりするためのインフラストラクチャコードを隠してくれる 複…

アルゴリズム変更

ポイント 複雑なアルゴリズムから単純なアルゴリズムに変更する 大きくて複雑なアルゴリズムを取り替えるのは難しい アルゴリズムを変更しやすくするために、出来る限りメソッドを分解しておく必要がある リファクタリングdiff refactor(substitute algorith…

メソッドからメソッドオブジェクトへ

ポイント ローカル変数がじゃまをして、「メソッドの抽出」を行いにくい場合に適用する ローカル変数は、メソッドオブジェクトの属性になる メソッドオブジェクトにすると、引数渡しの心配をせずに「メソッドの抽出」を行えるようになる コード 6.9-after · …

引数への代入の除去

ポイント 引数への代入を安易に行うと、引数自体が変更されているのかどうかを気にする必要が出てくる →rubyの場合、値渡しなので引数自体は変更されない プロダクトコード(ruby) before class Order def discount(input_val, quantity, year_to_date) inp…

リファクタリングしてみた(ハギスの移動距離)

適用したリファクタリング名 一時変数から問い合わせメソッドへ(Replace Temp with Query) 条件文の分解(Decompose Conditional) プロダクトコード(ruby) before class Haggis def initialize(primary_force, secondary_force, mass, delay) @primary_…

Extract Method(メソッドの抽出)

所感 プロダクトコード Introduce Explaining Variable(説明用変数の導入)と同様に、プロダクトコードが読みやすくなった。また、「base_price」のロジックを再利用できるようになった。 テストコード Introduce Explaining Variable(説明用変数の導入)…

Introduce Explaining Variable(説明用変数の導入)

Product Codeがちょっと読みやすくなったか。Test codeの改善はあまり期待できなさそう。 ◯ Product code(ruby) # before class Order attr_accessor :quantity attr_accessor :item_price def initialize (quantity, item_price) @quantity = quantity @ite…

Replace Temp with Chain(一時変数からチェインへ)

テストコードがすっきりしました。 before:add_option(arg) →after:and(arg)before # product code(ruby) class Select def options @options ||= [] end def add_option(arg) options << arg end end # test code(rspec) describe Select do let(:select)…

「シンプルな設計」を目指す上で必要な感覚

リファクタリングは、柔軟性を犠牲にせずに設計を単純化に導く。 (中略) 簡単にリファクタリングできるものがどのようなものかについての感覚が身につけば、柔軟な解について考えることさえなくなる。必要なときが来れば、リファクタリングできるという自…

一時変数から問い合わせメソッドへ(Replace Temp with Query)

一時変数は、無用に多くの引数(パラメータ)をやり取りする原因になるという点で、ない方がよい。 一時変数がなぜそこにあるのかは、すぐにわかりにくくなってしまう。 一時変数を取り除けば、データをいかに仕分けしていくかではなく、コードが何をしよう…

2/21(今後やりたいこと)

・自分のために、ブログを書く まずは、自分の頭の中を整理するために、ブログを書く習慣をつける。・「何を作るか?」をその背景を基に考える癖をつける 言われたものをそのまま作るだけのプログラマーは、あまり付加価値が高くない。「言われたものに、ど…

忘れ物に気づくためのシステム

<参考記事> タクシーのkm、車内画像比較して忘れ物発見撮影システム開発 http://www.nikkei.com/article/DGXNASGF0202Y_T00C13A9MM0000/忘れる「前提」で開発したところが憎い。タクシー業界でははじめての試みということらしく、今後が楽しみです。電車…

「おもしろい・理解しやすい」英語学習サイト

「英語のおもしろそうな動画が見つからない」 「字幕なしの英語の動画を見ても、ほとんど理解できない」 「なんとか英語を聞き取れても、その単語の意味がわからない」そんな悩みを持っていた時に出会ったサイトが、「EEVideo」でした。 EEVideo(http://www…

余裕を持ってらくらくと勝つために必要な「準備」

『余裕を持ってらくらくと勝つ』 なんとも心地よいフレーズです。ただ、このフレーズを現実のものにするためには、徹底的な「準備」が必要。 これが、今読んでる「孫子に学ぶ12章―兵法書と古典の成功法則」の第2章目「勝算なきは戦うなかれ」から得た気づき…

「戦わずして勝つ力」と「負けない力」を身につける

今日から「孫子に学ぶ12章―兵法書と古典の成功法則」という本を読み始めました。 まず第一章「戦わずして勝つ」を読んで感じた事を残しておこうと思います。この章を読んでいて気づいた事は、『戦いにはコストが伴う』という事です。 武器を使った戦い、いわ…

お金に振り回されないための、お金の下ろし方

"財布の中にお金がなくなったら、ATMでお金を下ろす"私は半年程前まで、上記のようなお金の下ろし方をしていました。しかし、今は全く別の下ろし方をしています。 下ろし方を変えた理由はただ一つ。「ATMの残高が、意図せずどんどん減っていった」からです。…