>>79
というか歴史的には逆だ。interfaceをクラスでシミュレートというより
元々クラスの制限版がinterface。
理論上もinterfaceのはクラスの特殊なものと考えていい。

オブジェクト指向の基本である「データの隠蔽」によって
クラスにはそれ自身、またはその子孫のクラスのインスタンスのメソッドが利用する
内輪向けの「インターフェース」と一般外部向けの「インターフェース」ができる。
（protectedを考えるときは内輪向けをさらに二つに分けて考えているわけだ。
Javaの場合はさらにパッケージ内向けの「インターフェース」を表現する
デフォルト・アクセスというのもある。）
内輪向けの「インターフェース」のほうがデータの配置・表現など
実装の詳細により深くかかわるから当然複雑になる。
よってその継承をキチンと実装するメカニズムの実現はより大変になる。
（脱線だがこれはデータ隠蔽も一種のポリモルフィズム
と捉えることもできるという考え方。
同一のオブジェクトにクラスの内と外を表す二つの型＝「インターフェース」が
結び付けられていると考えるわけ。）

C++のような多重継承は理論上可能であるし、
モデルを表現する能力を考えた場合有用でもあるが、
必ずしもその実現は簡単ではないしプログラマにわかりやすいとも限らない。
そこでJavaでは外部向け「インターフェース」だけを表現する、
クラスよりも簡単な仕組みとしてinterfaceを作った。
そして多重継承はinterfaceだけに制限することにした。
この決定によっていくらか表現力を失う代わりに
より実装しやすく簡潔で分かりやすいようにしたわけだ。
これは実用上、多くの場合はそれで十分だという観察に基づいている。