インターフェースについて、「設計書」や「使い方の定義」「約束ごと」といった説明をよく見かけるけれど、どうにも分かりにくいたとえが多い気がする。本質をつかむには、まずその語源に立ち返ってみるのがいいかもしれない。インターフェースとはもともと、あるものとあるものの「境界」を隔てる部分を指す。そして、その存在意義を端的に言えば「交換可能にしておくこと」にある。
交換可能にするためには、当然ながら事前の取り決めが必要になる。どんな形の「つなぎ口」なのか？どんなデータが流れてくるのか？あるいは流れていくのか？そういったことをあらかじめ定義しておかないと、つなぐことすらできない。たとえば家庭用のコンセントを思い浮かべてほしい。あれには電極が2つあり、電気が一定の規格で流れてくる。だからこそ、どんな家電でも差せば動くようになっている。
このとき重要なのが「どちら側に取り付けるか？」という依存性の問題だ。つまり、家電が家の壁（＝電源）に依存しているのか、それとも壁が家電に依存しているのか。私たちは普段そんなことを意識しないけれど、常識的に考えれば壁が固定されていて、そこに家電を差し込む。誰も壁をアイロンやドライヤーに打ち付けたりはしないし、ましてやアイロンを壁に貼りつけて、服の方を動かしてシワを取るような真似はしない。
ところが、ソフトウェアの世界では、この依存関係を逆にしてしまうケースがままある。本来は使われる側（下位の層）に依存するべきではないところが、逆に依存してしまい、まるで壁が家電にぶら下がっているような設計になってしまう。
そこで重要になるのが、パーツごとに役割を明確に分け、関心を分離するという設計の考え方だ。これが、いわゆるレイヤードアーキテクチャである。各層がそれぞれの役割を担い、他の層と明確に線を引くことで、保守性や拡張性が大きく向上する。
ちなみに、コンセントを例にレイヤー構造を説明しようとすると、せいぜい2層くらいにしかならないので、ちょっと無理がある。どうにか無理やり例えるとすれば、「どれだけタコ足配線で家電をつなぐか」みたいな話になるだろうか。でも今にして思えば、コンセントの例はオブジェクト指向（OOP）を説明するにはあまり向いていなかったかもしれない。気づくのが少し遅かったけど……（汗）。
コメント