logo
/
すべての関数は、それを変更する理由がただ1つになるように設計する
Loading...

処理に名前をつける

プログラミングをする上で「コードを共通化する」なんてことは意識しなくていい。それよりも処理に適切な名前をつけることだ。
そのプログラムにおいて「単なる変数の操作」を超えた意味のある処理には名前をつけろ。同じ意味の処理なら同じ関数を使うし、違う処理なら違う関数を使う。
コードが共通化できるかどうかなんて全く関係ない。

関数は再利用のためのものではない

変数、関数、クラス、名前空間等が再利用のための機構だという先入観は一旦捨てろ。それらの真の意義は、「関心の分離」にある。つまり、実装を隠蔽し、その意図を抽象するために存在する。たまに勘違いしてる奴がいるが、別に1回しか使われない関数とか、1行しかない関数はあってもいい。というか、この原則にしたがって設計すると、ほとんどの関数(or メソッド)は数行になる。

関数は内容ではなく目的で作成する

「消費税を加える」「金利を加える」処理は、明らかに単なる算術演算以上の意味のある操作だから、関数化する。消費税を加える箇所では前者の関数を呼ぶし、金利を加える箇所では後者の関数を呼ぶ。それぞれの実装自体は当初の仕様では全く同じになる。 消費税を加える関数を変更するのは、消費税の計算処理が変わったときのみであり、金利を加える関数を変更するのは、金利の計算処理が変わったときのみである。つまり、すべての関数は、それを変更する理由がただ1つになるように設計しろということだ。

結果として

こういうアプローチでプログラムを書くと、ソースコードはあたかもそのアプリケーションのドメイン特化言語で書かれたかのような見た目になる。
また、一つ一つの関数は小さく、理解しやすく、テストやデバッグも容易になる。そして、結果として再利用もしやすくなるし、プログラムの変更も容易になる。