と社内のチャットに書いたら、それは「"脳死Getter" は駄目」なのか、それとも「脳死 "Getterは駄目"」なのか、という良いツッコミを受けた。

脳死こそが悪である

どちらでも完全に意味が通る。こと設計に関しては、脳死することが絶対に最悪なのだ。脳死してGetterを作ることも、脳死してGetterを一律禁止にすることもだ。

Getterにはちょっとした思い入れが僕にはある。大学の授業でオブジェクト指向を学んでいて、そのときはJavaが題材だったのだけど、「public fieldを直接公開すると後から内部構造を変えられないのに対して、Getterにしておけば後からデータの持ち方変わっても振る舞いを変えずにすむ」という説明を聞いて、心の底からなるほどなぁと思った。これは今思い返しても本質的な納得だったと思っている。プログラミングの設計では、将来の拡張に耐えうるかどうか、というのが非常に重要な視点だからだ。

しかし、現代ではGetterが当たり前になりすぎて、脳死してGetterを生やす人が多くなった。というかその授業を受けたのは12年前だけど、その時すでにEclipseにはクラス内のprivateフィールドに一括でgetterを生やせる機能とかあったし、脳死してGetter使う人は当時から多かったのだろうと思う。

じゃあ、こんどはGetterを禁止するべきなのだろうか。否。Getterが間違った使われ方をすることが多いからといって、Getterを禁止するというのは、新たな脳死だ。上に書いたように、Getterにはもともと設計上の意味があったのだ。間違って使われやすいからといって、脳死して「禁止」したら、今度は別の間違った何かが出てくるだけなのではないか。(実際に、「Getterは禁止」という字面通りに受け取った結果、わけのわからない設計になっている事例は存在する。)

Getter廃止論

ここまで書いていきなり逆のことを書くようだが、Getterという言葉をそもそも積極的に使うべきではないのかもしれない、と思っている。Getterという言葉を廃止するということなら個人的には賛成かもしれない。

今やほとんどのオブジェクト指向プログラミング言語において、フィールドをそのまま公開するのが当たり前に行われることはない。最初に書いた、「public fieldをそのまま公開せずにメソッドにくるむ」という文脈については、もはや忘れられても良いのだろう。

一方で、Getterっていうのは基本的に、内部にデータが先にあって、それの公開するメソッドを生やしましょう、っていう考え方だと思う。実際は逆に考えるべきだ。外から見てどういうインターフェイスが必要かを考えて、それが内部のデータとたまたま一致するならGetterになる。そういうインターフェイス中心の考え方を推進すべきというのは一理ある。Getterという言葉はその邪魔になるだろう。

一応書くと、あくまでGetterという言葉をわざわざ持ち出す必要がないという提案であって、getHogeという名前のメソッドが悪いとか、そういうことを言うつもりは毛頭ない。

脳死こそが悪である(再)

「Getterを見ると臭いがする」ならこれもわかる。いわゆる設計原則とか、経験則とかは、補助輪として有用である。ただし脳死、テメーはダメだ。

あわせて読みたい