awesometaro

interfaceは不要なのか

Zennを読んでいたら以下の記事が目に止まった。 クリーンアーキテクチャは変更コストが高い! YAGNI原則を適用して軽量化する

一般的にクリーンアーキテクチャは変更のコストが小さいと言われているので、気になって読んでみた。

おそらくアーキテクチャを考えた人がドメインの変更よりもフレームワークやインフラの変更を過大評価してしまったからだと思います。 バージョンアップするごとにドメインの内容は毎回変化しますが、フレームワークやインフラが変更されることは滅多にありません。 たとえば、ほとんどのファイル形式は上位互換です。 なのに、非依存にするために、依存性逆転の原則(と呼ばれる)冗長な『インターフェース』(原則ではない)を書くから、コストが高くなってしまうのだと思います。

これは同意する。 Ruby on Railsも多分、この理由でデータベースなどは密結合しているのだと思う。 一方で、過去にphpのpdoからDBIに変更したプロジェクトの経験があるが、この場合ではインフラ自体も差し替えられるようになっていればなあ、と思ったことがある。

たとえば、外側のクラスのメソッドが追加されたら、インターフェースにも同じようにメソッドを追加しなければなりません。 メソッドの引数の数が増えたら、インターフェースにも同じように引数の数を増やさなければなりません。 このように『二重管理』が発生してしまうことが煩雑さの原因です。

二重管理を発生させないようにするにはどうすればいいのでしょう。 それは TypeScript の import type 文や、Python の TYPE_CHECKING を使うことです。

非依存にするなら Java で考案されたインターフェースを書く習慣はやめるべきです。

これが煩雑だったから、ダックタイピングという考え方が生まれたのではないかと思う。 TypeScript の import type 文や、Python の TYPE_CHECKINGも型システムをハックしている感があり、抜本的な解決策ではない。 この煩雑さは”型付き”言語のデメリットであり、rubyなどの型をつけなくていい言語であればこの煩雑さは生まれないと思う。 Ruby on Railsを使えってことか。