名前は使われる場面で使い方を指示したり制約したりするような意味合いを名前で表現できるとよい名前になります。
表現しているクラスだったり変数の実装を見ながらつけると名前をつけるもの自体を中心においてそれを説明する名前になります。良い名前にしたいなら、そのオブジェクトやメソッド、変数が使われる場面で、どのように使うと読みやすいか、ミスしやすい部分をミスしないように導けるかを気にしながら、使う人へメッセージとなるような名前をつけます。
これを実装ではなく意図に名前をつけると呼んでいます。CODE COMPLETE 上巻の 11.1.2 に『問題指向の名前』という半ページくらいの文章があり、 How でなく What に名前をつけるという主旨のことが書いてあるのが元ネタ (の一つ) です1。
意図
というすばらしい語彙は Kent Beck が Smalltalk Best Practice Patterns というこれまたすばらしい本に Intention Revealing Names という話を書いているということを以前一緒に働いた Java エンジニアに教えてもらって以来、気に入って大事に使っています2。
何が起こっているのでしょうか? それはコミュニケーションです。最も重要なのは、一行だけのメソッドでも、意図を伝えるために存在する価値があるということです。
Footnotes
-
昔の CODE COMPLETE には
よい名前は How でなく What を表す傾向がある
と書かれていて、とくに訳されていなかった。自分で解釈を進めた結果、What
を表す (=問題指向の名前) とは目的や意図に名前をつけるということだという理解をしていた。「それはなにか」という目的や意図を表現するもの
を指し、問題領域の概念そのものという意味での『もの』へ名前をつけるのが良い。なお、第二版では手段 (How) でなくもの (What)
と How と What にも訳があてられている。 ↩ -
書籍に書いているのは Intention Revealing Selector や Intention Revealing Message として載っています ↩
@gfx から
というつっこみを受けたので「たしかにたしかに」などと思って返事して、あらためて CODE COMPLETE の文章を読んでみた。
以下、引用。
11.1.2 問題指向の名前
覚えやすい良い名前は、一般に、解決策ではなく問題を表現している。良い名前は、 方法 (how)ではなく もの (what)を表すことが多い。一般に、名前が問題ではなく計算の一部を表すとしたら、それは もの ではなく 方法 を表す。そのような名前は避け、問題そのものを表現する問題指向の名前を付けよう。
社員データのレコードには、
inputRec
またはemployeeData
という名前を付けることができる。しかしinputRec
は、計算の概念である入力と記録とを意味するコンピュータ用語である。employeeData
の方は、計算ではなく問題に言及しているので良い。同様に、プリンタの状態を表すビットフィールドに名前を付けるとしたら、printerReady
は問題指向だがbitFlag
はコンピュータ的である。財務アプリケーションでは、sum
は問題指向だがcalcVal
はコンピュータ的である。ということで、CODE COMPLETE の文章が言いたいのは what は問題指向で もの についての名前をつけようという主張なのは、そのとおりなので訳がいまいちかのような物言いは修正することにする。
一方、自身が行き着いた今の解釈として、ものへ名前をつけるよりも自分がそれをなにととらえたか、どういう位置付けとしてモデリングしたかを表現する
へ名前をつけたほうがよいと考えているという点はメッセージのメインの部分なので取り下げずそのまま主張したいでのそのように文章を変えてみた。