Gobble up pudding

プログラミングの記事がメインのブログです。

MENU

プログラムのインターフェースは必要か

スポンサードリンク

f:id:fa11enprince:20200628230343j:plain
ふと、いろんな記事を見ていて、インターフェースは必要かっていうのがあった。

Java インターフェース メリット わからない - 社内se × プログラマ × ビッグデータ

どういうものかは分かりますが、メリットについては何も分からないです。
処理を具体的に書かないと、何の役にも立たないのに、何でそんなことをするのか?という疑問が残ります。

というような記載を見つけました。 こういう風に思うのは正常だと思います。
いや、当然必要だけど、JavaとかJavaとかJavaとか過剰に使いすぎてるのでは?と思ったところがあったので…。RubyとかPythonってinterfaceないっすよね(そのかわり別にいろいろ後付けで実装差し替えなど動的言語ならではのことができますが…)。 なんかほら、StrutsでDIが積極的に取り入れたときに、あの汎用性重視のやりすぎ感。それに近いものを感じるわけです。結局歴史的には設定より規約(CoC)に流れていき、汎用性が高いけれども一方でとても面倒なXML地獄、いい加減、毎度おんなじテンプレみたいな呪文をひたすら書くということから解放されたのだ(しかも間違ったら意味不明なミスに遭遇するし、XMLなので静的チェックもかけにくい)…。

自分が思うにインターフェースにするメリットは

  • テストクラスを書くときに簡単に実装をダミーに差し替えれる
  • 大規模開発しているときにとりあえずこれをこういう形で呼べばいいというのを利用側に宣言できる

というのだけに尽きると思います。
ただ、フレームワークを作っている側だともっと恩恵があって、
これ以上にメリットがあってあとで丸っと実装を差し替えたりしても後方互換性がとりあえずインターフェースだけ変えなければ保たれるとかあると思うのですが…

Javaの話でいえば特に昔のSpring Frameworkとかの慣習だと何でもかんでも実装とインターフェースを分けて書きますが、正直アプリレベルの上位レイヤーでそれをやるとやりすぎ感があったりするような気がします。ぶっちゃけフレームワークの上位のアプリレベルだと別にインタフェース書かなくてもいいんじゃ?という気がします。テストフレームワーク(JUnitとかその他)でもMockでいろいろ差し替えようと思えば差し替えられるので。あれですね特にServiceクラスで見るFooServiceFooServiceImplとか。 正直、インターフェース書いてオーバーライドするのがだるい…アプリレベルならその手間があるならインターフェース書かなくてもいいんじゃ的な…。メリットよりだるさが上回ります。 小規模~中規模とかで自分が全部掌握しているようなプロジェクトだとインターフェースはほぼ意味をなさないんじゃないかと。
一方抽象クラスでポリモーフィックに作ろうとするとabstractメソッドは便利なんですがinterfaceってなんか中途半端というか。

といいつつ、Spring Bootでは慣習に倣いServiceとServieImplは分けています…。辞めようかなと思った今日この頃。なんでかって?テストクラスをpackage privateにすれば簡単に差し替えれるから。 そもそもSpringでDIする場合は@Autowiredでそのクラスを書き換えれば疎結合は維持されるので(ただし、呼び出し元の書き換えが発生しますが…)、余計メリットを感じないわけです。 そもそもクラスの名前がイケてなかった。あとで書き換えたい…ってときは結局インターフェースにしても意味ないですので…ということで、アプリなどの上位レイヤーばかり書いていると、メリット薄いかもしれないです…。 フレームワークはフレームワークでインターフェースないとしんどそうですが、処理を追うときに、実際にはどの実装使ってんのよ?っていうのが追うの辛いという…。