インターフェイスってナンダ？ - PART2

正しい作業分担

２つのサブシステムがファイルを通してデータをやりとりするとき、ファイルフォーマットを隠蔽するためにはモジュールを次のように分割しなければなりません。

• データ送信側モジュール（サブシステムＡ）
• データそのものを表現するモジュール（ファイルフォーマットを隠蔽している）
• データ受信側モジュール（サブシステムＢ）

• 将来的な変更を容易にする・・・
  ファイルフォーマットが変更されたときに、データの論理構造に関する変更がないならば、その影響が及ぶ範囲は真ん中のモジュール内部だけ
• 構造が単純化する・・・
  送信・受信それぞれのサブシステムの製作者は、データの論理構造だけ考えれば良いので

さて、もし作業者が２人だとしたら、どちらが真ん中のモジュールを作るかでもめるでしょうか？実際には、誰が真ん中を作るべきかはハッキリ決まっています。スキルの高い人です。

一般的に言って、サービスを提供される側よりも提供する側のモジュールの方が、作るのに技術的センスを必要とします。なぜかというと、「どれだけ使いやすいインターフェイスにできるか」が勝負だからです。上の例の真ん中のモジュールは、両サブシステムから利用されます。そこで、この部分のインターフェイスが明確であるほど、それぞれのサブシステムの実装が楽になるし、作業効率も良くなるし、コードの質も高くなってメンテナンス性が増すのです。

このように、プロジェクトチームで作業分担を決めるときは、サービスを提供する側のモジュールにスキルの高い人材を割り当てるようにするのが成功の鍵になります。将来的に変更される可能性が高い部分や機種依存の部分などのような、実装を隠蔽して使いやすいインターフェイスを考案しなければならない箇所はスキルが必要だし、全体をつなぎ合わせるメインルーチンは意外に簡単に作れることが多いでしょう（メインルーチンはサービスを一方的に提供される側ですね）。もちろん、サービスを提供する側とされる側に分割すること自体にもセンスが必要なので、スキルがある人が全体のデザインをするというのも重要です。

他の場合

さて、ここまでファイルフォーマットを隠蔽するという例で説明してきましたが、通信プロトコルの例でも同様にできます。もちろんそれ以外にも、至る所で同じ考え方が通用します！「アクセス関数」のデザインの仕方を自分なりに一般化して、どんどん実践してみてください。また、アクセス関数によってうまく実装を隠蔽した例がないか、身のまわりで探してみてください。これがうまくできるようになれば、作業効率はずいぶんアップします。

あるプロジェクトで、似たような動作をする複数のプログラムを作らなければならなかったとします。そういうときは、似ている部分や同じ部分をサブルーチンにして、ライブラリか何かにしますよね。ところが、サブルーチン化が禁止されているプロジェクトがあるという話をときどき耳にします。