static メソッドでよいのでは?

static おじさんと呼ばれる人がいたそうだ、あるいはいるそうです。インスタンスの生成を嫌がって、何でも static メソッド にしてしまう人のことです。static メソッドと呼ぶよりも関数と呼んだ方がよいかもしれません。

インスタンスの生成を嫌がるのは、気持ちはわかります。メモリ管理が GC 任せで、速度にどう影響するかわからないのが嫌なのでしょう。現在では、細かいメモリ管理が本当に必要な場合はほとんどないので、ほとんどの場合インスタンスの生成なんて無視してよいでしょう。しかし、ひとつひとつの処理に対してコスト感覚を持つこと自体はよいことです。問題があるとすれば、その感覚が誤っていることでしょう。

ただ、おそらく static おじさんと嘲笑されたのは、コスト感覚の誤りからよりも、未知のものがわからない、覚える気がない態度からでしょう。いつか私も Java おじさんとか Linux おじさんとか言われるのかなと思うと、笑ってられません。

でも、static おじさんがどうだとか言っていた人は、本当にオブジェクト指向を分かっていたのかと疑問に思ったりもします。

役割駆動設計で巨大クラスを爆殺する - Qiita

この記事にある、コンテキストに対応する役割を振る舞うのに必要な最小限のフィールド、メソッドが定義された動名詞のクラスとは、関数オブジェクトのことではないでしょうか?関数オブジェクトとは、関数をオブジェクトにしたもので、引数に渡したりできる関数のことです。SOLID 原則の最初の一つ「Single Responsibility Principle 単一責任原則」に従っていくとクラスは、ただの関数オブジェクトになってしまうと思います。『Clean Architecture』の単一責任原則の章には下の絵が書いていました。たった一つの仕事しかしない 〇〇er は、〇〇関数と変わりありません。

f:id:fjkz:20181013155919p:plain

関数オブジェクトであれば、わざわざオブジェクトにしなくても、static メソッドでほとんど同じことが表現できます。むしろ static メソッドを使った方が、記法としてシンプルです。引用元の記事を書いた人も、Robert Martin も、static おじさん叩きなんてしてないことは念のためいっておきますが、オブジェクト指向を分かっていると思われる彼らが一周回ってたどり着いたのは、static メソッドと同じものではないでしょうか?

関数オブジェクトだと、引数に値として渡したりできる利点はありますが、コールバック関数をむやみに使う設計はあまりよい設計とは言えません。業務モデルにはほとんど使わないでしょう。また、Java 8 からは static メソッドであっても、値として渡せます。 だったら、もう関数オブジェクトを作らずに、static メソッドでよい。

データ型の表現には、インスタンスを作るクラスを引き続き使う必要があります。しかし、手続きを表現するには static メソッドでよいのです。つまり、static おじさんが正しかったのです。