staticメソッドは善？悪？

※staticメソッドでもいいですし、静的メソッドでも、静的関数でもよいです。

新人の時に、staticメソッドはあんまり良くないよ～、マルチスレッドとかできないよ～、みたいな話を聞きました。それ以来、staticメソッドはあんまり使ってこなかったのですが、最近、特にRust使い始めてから、staticメソッドの利点も見えてきました。

Rustだと、メソッドの第1引数がselfじゃない場合、staticメソッドってことになります。たたし、staticというキーワードは使わず、関連関数などと呼びます。つまり、selfを書くっていう面倒なことをやめたら、staticメソッドになるわけです。推奨されることはラクな書き方ができるようになっているのが、最近のプログラミング言語なので、メリットもあるのかな、と察した感じです。

関連関数っていう呼び方も本質を言いえているような気もします。つまり、関連しているだけで「そのクラスのメソッドでないといけない」ということもない、ということです（ワタクシ的解釈）。

たとえば、staticメソッド20個、非staticメソッド20個で構成されたクラスと、40個全て非staticメソッドで構成されたクラスがあったとします。機能は同じです。どちらがいいですか？

メソッド40個となると、割と大きいクラスです。こんな感じでクラスの実装が膨れてくると、クラス分けようかな、って考えたりもします。C#だとpartial classとか、Rubyだとopen classとか、単純にクラスの実装を分割できる方法もあります。一方で、Javaではinterfaceのデフォルト実装的なのもあります。もちろん、継承や委譲を使う手もあるでしょう。

こういうのとはやり方は違いますが、40個のうち20個をstaticにしたらどうでしょうか？たとえば、そのクラスが直接保持しているものをいじるメソッドは非static、そうではない、一時的に生成する変数やインスタンスをいじるようなメソッドはstaticとすればどうでしょうか？こうすれば、クラスに直接変更を加えるメソッドを20個に限定できるってことです。すると、どこでクラスが持ってるものが変更されてるのか、見通しが良くなる気がします。その上で、汎用的な処理だったら、staticメソッドから、Utilityクラスにさらに切り出してもいいですしね。

マルチスレッドとか、それでまずいことがあったら、その時に考えればいいかな、と。

まとめ

クラスが直接持ってるわけではないものをいじるだけなら、staticで十分なことも結構あるかも。。むしろ、そのほうが、見通しが良くなったりする。困ったら、その時、考える。