🏗️

インターフェースはどこにあるべきか?

2022/02/23に公開約2,300字

モバイルアプリ開発においても、スタブを使ってユニットテストを行ったり、モジュール間を疎にするためにインターフェースを用いて抽象に依存するということは一般的な開発手法になっているかと思います。

最近のアプリ開発のトレンドとしてモジュール分割があり、インターフェースはどのモジュールに配置するのがベストなのか? について、これから考えられていくと思っています。

いくつかの考え方を紹介してみます。

インターフェースと実装を同じモジュールに配置する

これが一番よくあるケースだと思います。アプリ開発は小規模~中規模が多いため、ほとんどの場合、これでも特に問題にはなりません

単純に実装できるながら、いくらかの欠点は抱えてはいます。

  • ViewモジュールをビルドするのにRepositoryモジュールのビルドを通す必要がある
  • Repositoryの実装を別のモジュールに単に置き換えることができない(密結合している)

たとえば、改善されたrepository2のモジュールへ置き換えることを考えてみます。

同じインターフェースファイルを新しいモジュールにコピーする必要がある上に、しかもViewは旧モジュール内のインターフェースを参照しているので、View側も変更しないと新しいrepository2モジュールを使うことはできません。

インターフェースはそれを使用するモジュールに配置する

インターフェースをViewモジュールに移動することでこの問題は解決できます。

新しいrepositoryの実装が出たら、新モジュールに切り替えるだけで良くなります。

しかしながら、Viewモジュール内にRepositoryモジュールのインターフェースがあるというのに違和感を覚えるかもしれません。実際、依存するモジュールの種類が増えたら、それだけViewモジュール内のインターフェースは増えていくことになります。

インターフェースだけのモジュールを切り出す

これはStairwayパターン[1]と呼ばれている手法です。

Mermaidではうまく表現できていませんが、このモジュールの分け方を行うと抽象と実装が階段状になるのがその由来です。(類似品にStairway to Heavenパターンがありますが、別物です)

それぞれのモジュールを別の開発チームが担当するような大規模開発においてとても有効な手段ですが、中小規模のモバイルアプリだとオーバーエンジニアリングになりかねず、必ずこれが正しい、というものでもありません。


脚注
  1. C#実践開発手法~デザインパターンとSOLID原則によるアジャイルなコーディング ↩︎

Discussion

ログインするとコメントできます