抽象化についてもう少し補足したいと思います。
ＩＴの世界では、レイヤーという考え方がよく用いられています。同じ概念を意味した言葉としては以下のようなものがあります。
「透過的」とは、その先の実装がどうであったとしても、同じようにアクセスできることです。例えば、Javaで作ったアプリケーションは、WindowsだろうがUnixだろうが同じように動きます。これはJavaVMがそれらのプラットフォームの差異を吸収し、Javaアプリケーションに対して透過的なアクセスを提供しているからです。
「ブラックボックス」とは、入口は見えるが中身が見えないことを意味します。これはいい意味にも悪い意味にもなります。いい意味では中身を知らなくても使えるということです。悪い意味では、中身がわからないので何をしているか不明ということ。あるAPIを使った場合、インターフェースさえわかれば実装がどうなっているか知らなくても、使うことはできます。しかし、問題が起きた場合、実装がわからないので何が原因なのかわからないことがあります。
「仮想」とはヴァーチャルということで、見かけ上ということです。これは「論理」同様「物理」と対比して用いられます。例えば、VPNの場合、遠隔のネットワークに安全に入る技術ですが、これは物理的には別のネットワークなのに、あたかも同じネットワークにいるのと同じ動作をします。仮想メモリは、実際には物理的なメモリは少ないにもかかわらず多く見せる技術です。
「論理的」も「仮想」同様、見かけ上という意味で用いられます。例えば論理削除と言う場合、実際にはデータは削除されていないのに、削除フラグなどを使うことで、使う側から見るとあたかも削除されているかのように見せることです。一方、物理削除とは実際にデータを削除することです。論理・物理という言葉は、論理構造と物理構造という形で使われたりもします。
見かけ上という場合、TVの画面と走査線の関係が思い浮かびます。ＴＶの画面は人間から見るとアニメーションのように一枚一枚の絵が連続しているように見えますが、実際には走査線が左から右にそして上から下へビームを発射しているだけで、人間の視覚の残像によりあたかも絵に見えるのであって、見かけと物理的な現実は異なっています。
また例えば、データベースで表に値を格納する際、ハードディスクに表があるわけではありません。実際の格納の仕方は異なります。
コンピュータはオン･オフ、0/1で構成される世界だといわれますがここでも仮想化が用いられています。実際には0/1と綺麗に分かれるわけではなく、電圧の範囲で0/1を決めています。さらに0/1は8つにまとめられてbyte単位で処理され、それにコードを割り当ててマシン語が構成され、さらに上にOSや高級言語が出てきます。高級言語で話をしている間は実際の物理的なあり方から離れ、かなり抽象化しているのです。電圧の高低でしかないものが、いろいろなことができるようになったのは驚異的ですが、そこには仮想化の考えが大きく寄与しています。
また例えば、ネット上で振込みという行為をする場合、移動するのは情報であって、物理的にお金が移動するわけではありません。物理的なお金の移動は、おそらく非同期で行われているのでしょう。
このように見かけと実際は異なります。
「インターフェース」は、入り口であり、見かけであり、実装は別に存在します。何かの機能を提供するシステムがあるとき、多くの場合、API（アプリケーション・プログラミング・インターフェース）が提供されます。このAPIがC言語向けに提供されている場合、C言語からそのAPIを使ってそのシステムを使うことができます。Java用のインターフェースが提供されていなければJavaから利用することはできません。このようにAPIはアクセスする窓口となっています。
これらのインターフェースが連なって、レイヤーをなしています。ある層は自分より上の層に対してインターフェースを提供し、また自分の下の層に同じインターフェースでアクセスします。自分と接していない層に対しては感知しません。
ネットワークではレイヤーの考え方が重要になっています。OSIで規定しているところによれば７層で構成されます。実際にはTCP/IPでは５層で説明されます。
こうすることで、自分と接するところ以外は関与する必要がなくなり、接するところもきちんと規格化されているので、役割・責任をはっきりさせることができるのです。
それは人間の組織も同様でしょう。社長は、役員や部長しか見えません。部長は下は課長クラスしか見えません。課長まで下がってようやく、平社員と接します。すぐ下のレイヤーしか見えませんし、通常はそのインターフェースで十分で、その下と関わる必要はないのです。
また、インターフェースのメリットとして、規格の統一や、さらに下に既存のものがある場合でも中間層が際を吸収して、上位層のインターフェースに合わせて互換性を保つことができるのです。
呼び出し側から見れば、そのインターフェースにあわせてアクセスすればいいということで、その先のことを心配しなくてもいいですし、呼び出される側は、そのインターフェースに合わせて実装すればよく、何が呼び出してくるかは意識なしなくてもよいのです。
また、インターフェースに適合するものなら交換可能であるため、状況に応じて、あるいは性能を向上させるために、交換することも可能です。
Webアプリケーションでは、最初のインターフェースは、ユーザインターフェース（UI)です。ここではブラウザ上に表示される画面になります。ユーザはその先で何が行われているかは普通意識しません。ユーザがこのUIで行った操作は様々な層を通過して、サーバ側のインターフェースへ伝えられます。アプリケーション側では、フレームワークのインターフェースからHttpRequestのオブジェクトを受け取り、内容に応じて処理を行った上で、HttpResponseオブジェクトにしかるべき結果をセットして返します。途中の層では、両側のインターフェースを持ち、片方からデータを受け取り、もう片方のインターフェースに合わせてデータを送ります。このようにインターフェースはあちこちで使われています。
オブジェクト指向設計、デザインパターンで重視されるのは、インターフェースでプログラミングすることです。実装への依存をなくし、インターフェースのみに依存するようにします。ここで言うインターフェースとはJavaのInterfaceで、実装とは実装クラスのことですが。こうしておくと、実装クラスを交換したとしても、呼び出し側は一切何も変える必要がないということになります。インターフェースを間に挟むことで、呼び出し側と実装クラスの間の直接の依存を防ぐことができるのです。
ここまで抽象化、インターフェースの大切さについて述べてきましたが、インターフェースさえしっかりしていれば実装はどうでもいいというわけではありません。実装は重要です。問題があったとき調べる際には、実体、具体的なものが必要です。ソースを探る際、オブジェクト指向では抽象化が多く使われるため、どこで具体的な処理を行っているのかを追いかけるのが大変だったりします。散々たらいまわしにされた挙句インターフェースや抽象メソッドに行き当たり、設定ファイルを探し出して具象クラスを調べる羽目になったり、迷子になってしまったり、たどり着いたと思ったらそこには何もなかったりなんてこともあります。実装が隠されているのは利点である反面、こういう問題もあります。利点の裏返しに何が入るかわからない、実行時でないと制約が守られているかどうかわからないという問題点があります。