Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.CheapestOnlineUSpharmacy(2008-05-17 14:27)
2.Kir(2008-05-08 15:52)
3.Hero(2008-05-06 16:49)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
先日はプログラミングに関するインタフェースに ついて、あれこれと話をしたワケだが、今日はそこから少しズームアウトして、インタフェースがプログラムに 占める位置について考えてみようと思う。
■ 「アルゴリズム＋データ構造＝プログラム」という教え
大学に入って最初に受けたプログラミングの授業では、プログラミング言語としてPascalが使われていたのだが、そのPascalの 設計者であるNiklaus Wirthが書いた、「ア ルゴリズム＋データ構造＝プログラム」という本がある。このタイトルを図で表現すると、まぁこんなカンジに なるだろうか。
そのプログラミングの授業では、「アルゴリズム＋データ構造＝プログラム」が参考書籍というか、副読本として勧められていたので、早速 学校の図書室で借りて読んだのだが、そこで提示されていたプログラムリストをいくら眺めても、何をやっているのか理解できない。当時は自分のアタマが悪い せいだろうと思い、そのまま放り投げたのであった。
それからさらに10年以上経ったある日のこと。ふと思いついて「アルゴリズム＋データ構造＝プログラム」を再び読んでみた。今度は少し はなんとかなるだろう…と思っていたが、やはり歯が立たない。ヘンだなとおもってよく見てみると、提示されていたプログラムはグ ローバル変数を大量に使って、 それをいじり回すというスタイルで書かれている、ということが分かった。いわゆる構造化、つまりprocedure（手続き）を使い、プログラムを分割す るという 姿 にはなっているものの、procedure間のデータの受け渡しが全く見えないのだ。
■ 「インタフェース」が欠けているのでは？
プログラムを作るには「アルゴリズムとデータ構造」が必要であることは間違いない。でもそれだけでは足りないものがある。それは一体何 だろう？ということをしばらく（半年ほどか）考えた後に現れたのが「インタフェース」という言葉であった。「アルゴリズム＋データ構造＋インタ フェース＝プログラム」というのが本来あるべき姿なのではないだろうか？
上の図の中で色を付けた部分が、前回のエントリ『「ユー ザ・インタフェース」に対する「プログラミング・インタフェース」という呼び名』で取り上げていた箇所となる。
ではプログラムの構成要素としてなぜ「インタフェース」が必要なのか？
例えば（GoF の）デザインパターンにはアルゴリズムは登場せず（オブジェクト間のやりとりを示したシーケンスは登場するが、これはアルゴリズムと 呼ぶには単純に過ぎる）、またデータ構造も表舞台には登場しない（データ構造は道具として使われるだけであり、最終的にはオブジェクト構造の陰に 隠れてしまう）。だがデザインパターンがプログラムを作る際の考え方の一つとして重要な位置を占めていることは間違いない。
もっと一般化させてみよう。もし、「プログラムにはアルゴリズムとデータ構造があれば良いのであって、インタフェースについては特に考 慮する必要はない」と考えた場合には、一つの関数で全ての処理を行なってしまう、あるいは一つのクラスで全ての処理を行なってしまうようなプログラムとい うものも、アルゴリズムとデータ構造さえしっかりしていれば良いプログラムということになる。しかし現実はそうではない。ある程度以上の規模を持ったソフ トウェアであれば、プログラミング・インタフェースに よる構造の整理は必須のものとなるであろう（例えばそれが無ければテストコードを書くことすら不可能となる）。ユーザインタフェースに関しては改めて強調 するまでもなく、ほとんどのプログラムにおいて考慮の対象となるべき存在である。
■ 今も見られる「アルゴリズム＋データ構 造＝プログラム」という考え方
しかし「プログラムにはアルゴリズムとデータ構造があれば良い」という考え方は、「アルゴリズム＋データ構造＝プログラム」が1976 年に登場してから30年ほど経つ今もなお、散見される。
1つのクラスで長々とではありません。もちろん、MVCを気にかけてオブジェクト分割しています。そういうプログラミングテクニックよりも、アルゴリズムを学ぶことの方が重要だと思います。その辺が作業員と技術者の違いになると 私は 思います。
（スラッシュドット ジャパン: 「まだやります人間対コンピュータのチェス対決」コメント）
コンピュータ上で計算を行うプログラムはデータ構造とアルゴリズムから構成される．
（京都大学工学部情報学科「ア ルゴリズムとデータ構造入門」）
すなわち、アルゴリズムとデータ構造が決まれば、プログラムはほぼ完成したものと言える。
（東北大学「2004 年度前期 IT教育基礎論特論B 第7回: アルゴリズムとデータ構造」）
だがこの文章でも述べたように、プログラムには「アルゴリズム」「データ構造」「インタフェース」の三つを揃えるべきである、という考え方を、そろそろ強調するべきなのではないかと僕は思っている。いかがだろうか。
（ちなみに「アルゴリズム＋データ構造＝プログラム」の最後の章で取り上げられている、PL/0(Pascalのサブセット的な言語)のコンパイラのプログラムリストはここで参照できる。興味のある方はどうぞ）
「アルゴリズム＋データ構造＝プログラム」？ 本当に？ Rogue Enginee...
[http://fukumori.org/diary/20051113.html#t:title=「アルゴリズム＋データ構造＝プログラム」？ 本当に？ Rogue Engineer’s Diary / やさぐれ日記(2005-11-13)]より これは結構面白いな。確かにアルゴリズムとデータ構造だけでも動くプログラムは作ることが出来るのだ..
と書いてから、炎上って言葉は「熱い」からきてるのかもしかして、と思ったけどやっぱ、火事は火事だな。 で、火事ではなく、良い意味で熱いのが福盛さんのところで進行中の 「アルゴリズム＋データ構造＝プログラム」？ 本当に？。 どういう話かの要約は次のであってるか..
via [http://arton.no-ip.info/diary/20051122.html#p02:title] 一晩快眠してる間にこんな熱い事態が。 一点だけ、 Wirth がアレを書いた当時は、単にインターフェース設計がプログラミングの範疇に入っていなかっただけではないかという気がします。 という別の通りすが..
http://fukumori.org/diary/20051113.html#p01 データ構造はもはやプログラミングにおいては主要なトピックでない、という言い方でよいと思います。例えばコレクションオブジェクトがあるとして、それに要素を置き換えたり追加したりしようというときに、実際問題としてど..
いや，そんなタイトルほどすごいことを考えていたわけじゃないんだけど，ここ10年くらいソフトウェア工学って本質的に進歩していないのではないかというそこはかとない疑問がある。あまり単純化すると語弊があるというか誤解を招きそうだが，要するにソフトウェアを作る..
再度、「プログラム＝アルゴリズム＋データ構造＋インターフェイス」について。もう熱くない？ いいの遅レスだから。 (プログラミング)インターフェイスって端的に言うと「名前」じゃない？ Ruby や Java や C# だったら、「プログラム」は「メソッドの中身」＋「クラスの..
アルゴリズム + データ構造 = プログラム
Algorithms + Data Structures = Programs
N.ヴィルト
最近しばらく関数やライブラリのインターフェースについての雑感を書いてきましたが、プログラムに
春休みに入ってからプログラミング関係のサイトを巡ってみたりしてます。授業のある期...
たまに来ますのでよろしくお願いします。
1年ほど前の記事ですが考えさせられる内容だったので特別にとりあげます．プログラミング言語Pascalを設計したNiklaus Wirth氏が1975年に著した『アルゴリズム＋データ構造＝プログラム』注
逐次処理を行うプログラムについては、今でも「アルゴリズム＋データ構造＝プログラム」だと思います。
プログラミング・インタフェースを設けることは、データ構造やアルゴリズムを整理して組織化するための手段なので、基本はデータ構造＋アルゴリズムで良いと思いますよ。「アルゴリズムとデータ構造がしっかりしている」と言えるプログラムは、その規模に応じた適切なプログラミング・インタフェースが存在するでしょう。
ユーザインターフェースは逐次処理を行うプログラムには必要ないですよね。
「アルゴリズム＋データ構造＋インターフェース＝プログラム」、いいですね。インターフェースがキモ、と思われてきたからこそ、オブジェクト指向（とか関数型言語？（笑））が流行っているんですかね。
通りすがりさんの意見はよくわかりませんでした。「「アルゴリズムとデータ構造がしっかりしている」と言えるプログラムは、その規模に応じた適切なプログラミング・インタフェースが存在するでしょう」というのは自明ではない気がします。
はじめまして。
今や嫌われものとなってしまいましたが、ウォーターフォール型の開発では、要件定義の後は外部設計というのを行います。この外部設計というのは、逐次処理でもインタラクティブ操作でも必ず関わりが発生する、対外システムとか、操作する人間に対する外部インターフェースを設計するわけです。
ウォーターフォールでは、アルゴリズムとか、内部のデータ構造は、外部インターフェースが確定した後の、内部設計で考えるものとされています。
というわけで、アルゴリズムやデータ構造の以前の問題として、インターフェースを考えるべきものであるという考え方は、昔からあるんだけど、こういう言葉としては定義されてはいなかったな、と思いました。
アルゴリズムとデータ構造がしっかりしている
⇒アルゴリズムとデータ構造がメンテナンスできる
⇒アルゴリズムとデータ構造が普通の人に理解できる
⇒普通の人に理解可能な大きさのアルゴリズムとデータ構造が、普通の人に理解可能な組み合わせで繋がっている
⇒その繋がりにはプログラミング・インターフェースが存在する
と、無理やりつなげてみました。確かに全然自明ではないですね。
規模に応じた適切なプログラミング・インターフェースが存在しないプログラムは、普通の人に理解できるものではありません。普通の人が理解できないプログラムを、アルゴリズムとデータ構造がしっかりしているとは言えないでしょう。と対偶を考えた方が分かりやすいかもしれませんね。
コメントとトラックバックをいただいた皆様、ありがとうございます。
以下コメントに対し、まとめてお返事を。
ささださん：
> インターフェースがキモ、と思われてきたからこそ、
> オブジェクト指向（とか関数型言語？（笑））が流行っているんですかね。
オブジェクト指向言語と関数型言語(例えばMLやHaskellなど)は、ADT(Abstract Data Types, 抽象データ型)というキーワードでつながっていると言って良いと思います。ADTはつまるところ、データ構造に対して、外部から見た操作方法を明示するためのインタフェースを用意してやろうという考え方であることからして「インタフェースがキモ、と思われてきたからこそ…」というのは妥当な解釈かと。
pekeqさん：
やはりソフトウェアの仕様を記述するにはインタフェースという視点が必要となる、というところに落ち着くのだと思います。
言い換えれば、それが例え仕様書などのトラディショナルなドキュメントであっても、あるいはユニットテストのような、いわば「動作する」ドキュメントであっても、インタフェースが定義されていなければ書くことが出来ないというところが重要であると。
「仕様書には何を書けばよいのだろう」という（ありがちな）悩みも、この視点から攻めてみることで解決により近づくことが出来るのではないかと思う次第です。
通りすがりさん：
プログラムにおいて「アルゴリズム」と「データ構造」は必要条件であることは間違いありませんし、それらの重要性は「インタフェース」が構成要素に加わったとしても一厘たりとも減ることは無いと思っています。
ただし「アルゴリズム」と「データ構造」がプログラムの十分条件であるという（本文中で述べたような、まだ世に残る）主張に対しては、はっきりと異議を唱えておきたい、というのが本エントリの趣旨でした。つまり「インタフェース」は、他の二つの要素に包含されるものではなく、またプログラムの本質的な構成要素として挙げるに足る存在であると。
個別のプログラムについては、これら三つの要素のいずれかの役目が小さくなるということはあり得ると思っています。ただ、プログラムというものを総体でとらえたときには、三つの要素のいずれも欠かすべきではなく、また規模の大きなプログラムではその三つを全て意識しておく必要がある、というのが現状での見解です。
Wirth がアレを書いた当時は、単にインターフェース設計がプログラミングの範疇に入っていなかっただけではないかという気がします。誰か別の人が(別の人でなくてもいいけど、プログラミングとは独立したプロセスで)作ったインターフェースに合わせて動くプログラムを作るのがプログラミングである、という考え方ならば、インターフェースはプログラミングの範疇には入らないわけです。
まあいまどきのプログラミングは、それでは困るようになっているのは確かですね。しかしながら、オブジェクト指向設計みたいな考え方は、やっぱりプログラミングからインターフェースを分離しようとする試みなのであって、今でもインターフェースというのはプログラミングというところからは少し宙に浮いてるような気もします。
ではまず一点目、
> Wirth がアレを書いた当時は、単にインターフェース設計が
> プログラミングの範疇に入っていなかっただけではないかという気がします。
に対する回答から。まずWirthが「アルゴリズム＋データ構造＝プログラム」を書いた1976年の2年前、1974年に発表されている論文、"The UNIX Time-Sharing System"の中にある、APIに関する記述を引用します。
----引用ここから
（…）例えば、ファイルシステムに対するインタフェースは、プログラミングの観点からみて非常に便利なものとなっている。最も下層となり得るインタフェースレベルは、さまざまなデバイスとファイルとの区別、および直接とシーケンシャルアクセスとの区別を取り去るよう、設計されている。
(Dennis Richie "The UNIX Time-Sharing System", VIII. PERSPECTIVE)
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html
----引用ここまで
次にADT(Abstract Data Types, 抽象データ型)を本格的に取り入れた(恐らく最初の)言語であるCLUに関する論文"A History of CLU"から。同論文は1991年のものですが、CLU自体は1974年に登場した言語です:
----引用ここから
(CLUのプログラムライブラリの)description unitには、その抽象化表現(abstraction)のためのインタフェース仕様が格納されていた; データ抽象を対象とした場合の構成要素は、オペレーションの名前とシグニチャ（訳注：引数の数と各引数の型）から成っていた。description unitにはまた、ゼロまたは一つ以上の実装も含まれていた。（最初の、抽象化表現を定義する期間を過ぎると）インタフェース仕様を変更することはできなかったが、新しい実装は逐次追加することが可能であった。
(Barbara Liscov "A History of CLU", pp.16-17)
http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf
----引用ここまで
CLU自体は広く普及するに至りませんでしたが、1974年に発行された、上記の仕組みについて詳細に説明されている論文"Programming with Abstract Data Types"( http://dx.doi.org/10.1145/942572.807045 )は、Dan Ingallsの"The Smalltalk-76 Programming System Design and Implementation"( http://users.ipa.net/dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.html )を始め、以後数多くの論文で参照され、プログラミングに関する研究に大きな影響を与えています。
以上二点だけを見ても、「Wirth がアレを書いた当時は、単にインターフェース設計がプログラミングの範疇に入っていなかっただけではないか」という主張は、妥当とは言いがたいと考える次第です。
また、「アルゴリズム＋データ構造＝プログラム」を書いた当時はインタフェースを意識していなかった（と見られる）Wirthも、その後のModula-2, Oberonといった言語において、明確なモジュール構造とインタフェース記述を取り入れるようになっています。2002年の講演"Computing Science Education: The Road not Taken"にて、Wirthはこれからのプログラミング教育に必要とされる教科書の条件として7つを上げ、その中の5番目の項目で、
----引用ここから
5. This is followed by the notions of information hiding, modularization, and interface design, practiced on exemplary applications.
(Niklaus Wirth "Computing Science Education: The Road not Taken")
http://www.inr.ac.ru/~info21/texts/2002-06-Aarhus/en.htm
----引用ここまで
と述べています。ということで、本エントリの僕の文章はWirthに対する異議なのではなく、1976年当時にたまたま出た、「アルゴリズム」と「データ構造」がプログラムの十分条件であるという（本文中で述べたような、まだ世に残る）主張に対する異議である、ということを再度述べておきたいと思います。
............
さて、次の二点目、
> 誰か別の人が(別の人でなくてもいいけど、プログラミングとは独立したプロ
> セスで)作ったインターフェースに合わせて動くプログラムを作るのがプログ
> ラミングである、という考え方ならば、インターフェースはプログラミングの
> 範疇には入らないわけです。
「誰か別の人が(別の人でなくてもいいけど、プログラミングとは独立したプロセスで)作ったインターフェースに合わせて動くプログラムを作ること」は「プログラミング」ではなく「（ウォーターフォールモデルにおける）コーディング」と呼ぶのが適切であると僕は思います。もしそうならば、「インタフェースは（ウォーターフォールモデルにおける）コーディングの範疇には入らない」ということで特に異存はありません。その後に続く文章も「プログラミング」を「コーディング」に置き換えたならば（ある程度は）妥当なものと思います。(eXtreme Programmingなどのアジャイル型の開発アプローチも考慮すると、ここの議論はさらに複雑になるはずですが、あえて省略 :-)
ですがこれも、本エントリの文章の最後にて僕が述べた
『プログラムには「アルゴリズム」「データ構造」「インタフェース」の三つを揃えるべきである、という考え方を、そろそろ強調するべきなのではないか』
という主張を変えるに足る要素とはならない、と考える次第です。
プログラミング = 「現実の世界と計算機の間のインターフェイスを作ること」
ではないかと思っています。
ちょっと突飛ですが、
「アルゴリズム」=「データ構造」=「インタフェース」
と見ることができる視点もあるような気がします。
モデリングの粒度によって、データがアルゴリズムになったり、その逆もあったりすると思います。
データの構造は、現実の世界とのインターフェイスと見ることができないでしょうか。
本来の話とは違ったことですが、プログラムがどう分析されるものであれ、あの本そのものが難解です。「わかれば簡単なことをいかに難しく書くか」というサンプルに見えます。
んなに難解でしたっけ？
当時、私は計算機とは全く関係ない学科の学生に過ぎなかったんですが、Wirth の本の PL/0 compiler を読んで、再帰降下法のパーサって、1シンボル先読みで対処できる構文木さえ書ければ、こんなに簡単に機械的に書けるのかって、ずいぶん感心した覚えがあります。
くだんのプログラムは、たしかに現代の基準からすると、読みにくいプログラムに入ると思いますが、当時の基準では、別にそれほど読みにくくもなかったと思います。
この本のプログラムが読みづらくなっている原因の一つは、Pascalの言語仕様上の制約として、モジュール固有の変数というものが存在せず、プログラム全体と同じ生存区間を持つ変数が全てグローバル変数になってしまっていることがあります。これは、Pascal ができた当時は、まだプログラミング言語というものが発展途上であり、Wirth の使っているような主記憶せいぜい数10Kバイト程度の計算機では、そういう機能がなくてもそれほど困ってなかったというのが理由だと思います。当時の Pascal は、そもそもモジュールや分割コンパイル機能さえない、ごくごく小規模な言語だったわけですし。
読みづらいもう一つの理由は、グローバル変数をインターフェースとしても利用していることがありますが、これも生存区間がプログラム全体とほぼ同じである状態変数に限ってそういう使い方をしているという点で一貫しているので、不自然ではありません。計算機が遅く、メモリが限られていた頃は、こういうのは結構当たり前でした。
当時はまだ Microsoft の ROM BASIC の全盛期でしたが、その頃の BASIC には、ローカル変数が全く存在せず全ての変数がグローバル変数であり、またサブルーチン機能はありましたが引数は存在せず、引数渡しは全てグローバル変数経由でした。そういうプログラムを見慣れた目にはむしろ、Wirth の Pacal プログラムが遥かに読みやすく感じたことを覚えています。
なお、こういうスタイルがプログラムを読みづらくするので現代的ではないという点には、もちろん異論はありません。
今も手元にこの本があるので、見直してみましたが、特に難解という印象はないです。まあ、今時のプログラマが、こういうプログラミングスタイルを身につけてしまっては困るだろうとは思いますが。
> んなに難解でしたっけ？
copy&pasteするときに、行頭の「そ」が抜けました。失礼しました。:-)
結城と申します。まず、
> プログラムには「アルゴリズム」「データ構造」「インタフェース」の三つを揃えるべきである
という考え方は、有意義だと思いました。ただ、気になることが何点かあるので、思いつくまま書きます。
・「インタフェース」にはそれがつなぐ「複数の何か」が必要だが、その「何か」が「アルゴリズム＋データ構造」ではないか？ （プログラムの粒度）
・あるいはそれは「オブジェクト」か？ （オブジェクトとの関係）
・「インタフェース」を(Design by Contractの)「コントラクト」に読み替えることはできるか？ （インタフェースの範囲）
・「インタフェース」＝「外部に見せているデータ構造の一部」＋「外部に見せているアルゴリズムの一部」ではないか？ （他の二要素との関係）
舌足らずですみません。
初めまして。大学生風情ながらコメントさせていただきます。
プログラムをグラフのように捉えてはいかがでしょうか？
データ構造もアルゴリズムも部品（つまり、点）で、インターフェースが線ではないかと・・・
いや、線ではないか（笑）でも、線と同じようなの位置づけであるように思います。
例えば、脳と社会の構造なんかを比較するように、オブジェクトの中も、プログラム全体もネットワークとして見れるような・・・。
と、すみません。最近ネットワークの本を読んでいるので（笑）
図に関する補足説明と修正について、取り急ぎコメントを。
まず、「アルゴリズム＋データ構造＝プログラム」の原題は
"Algorithm + Data Strucutres = Programs"
と、「プログラム」が複数形になっています。また、本エントリで述べている「プログラム」という記述も、プログラムの単体を指すのではなく、「プログラム」という総体を示してます。したがって、本エントリに示した図は、
「任意の、あるプログラム(A program)において、アルゴリズム、データ構造、インタフェースが並列に存在する『構造』が見られる」
ということを示した図ではなく、
「プログラム(Programs)というものを総体として見た時に、それを構成する『概念』として、アルゴリズム、データ構造、インタフェースの三つが存在する」
ということを示した図である
ということを改めて述べておきたいと思います。あの図はあるプログラム単体の『構造』について述べているのではなく、プログラムを一般に語った場合の構成要素を成す『概念』について述べている、ということです。
ということで、本エントリ中の図の「プログラム」と書かれたノードには、いずれも"(Programs)"という記述をその下に加えるよう、修正を行ないました。
以上、もしかしたら蛇足かもしれませんが。
（ということで）すみません、直接の質問とそれに関係するコメントにだけ、まずは回答を。
結城さん:
>・「インタフェース」にはそれがつなぐ「複数の何か」が必要だが、
> その「何か」が「アルゴリズム＋データ構造」ではないか？ （プログラムの粒度）
>・あるいはそれは「オブジェクト」か？ （オブジェクトとの関係）
とりあえず話をプログラミング・インタフェースに限定して回答します。プログラミング・インタフェースがつなぐのは、プログラムの構成単位(モジュール、クラス(オブジェクトとするべきか)、メソッド、関数など)であり、「アルゴリズム＋データ構造」ではないと考えます。
Tetsさんが
> プログラムをグラフのように捉えてはいかがでしょうか？
と述べているように、例えばUNIXの場合には、あるアプリケーションにおいて
アプリケーションの関数→ライブラリ関数→システムコール→カーネル→デバイスドライバ
という、呼び出しの連鎖が起こるケースがあるわけですが、この例においては、矢印で示しているのがプログラミング・インタフェースであり、これらインタフェースが結んでいるのは関数やシステムコールなどのプログラムの構成要素である、という見解です。
# カーネル、デバイスドライバにまで続く図(?)を勢いで書いてしまいましたが、若干微妙。
# プログラミング・インタフェースのカバーする範囲という議論も含めて
# 見直すべきかもしれません。
# あと、本当は矢印とか線ではなく、面のイメージで書きたいと思うのですが、この辺はまぁ仕方ないか。
上の例だとそれぞれの関数やシステムコール、カーネル等が「アルゴリズム」と「データ構造」を保有している場合「も」あると思います。その場合は呼び出しの連鎖の中で、インタフェース、アルゴリズム、データ構造の組み合わせが繰り返し、何層にも重なり合う構造がイメージできることもあるかも知れません。
# ちなみに本エントリ中の図はプログラムの『構造』ではなく『概念』を示すことを
# 意図したものです。これについてはこのコメントの直前にある、僕のコメントも参照のこと。
しかしオブジェクト指向プログラミングで、委譲(delegation)を使った場合などのように、あるオブジェクトから別のオブジェクトへ、メッセージ(メソッド呼び出し)を右から左へ流す、というケースというのも多く見られます。その場合には「インタフェース」は「アルゴリズム＋データ構造」をつなぐものとはならないことでしょう。
# ここ、UNIXの例からオブジェクト指向の例にいきなり飛ばすのはズルい気がしない
# ではないですが、UNIXにおける同様の例を示すよりも説明が楽なのであえて変えています。
総合的に考えると、インタフェースが結ぶのはプログラムの構成要素（関数やメソッド、オブジェクトなど）であり、その構成要素には「アルゴリズム」や「データ構造」が含まれている場合「も」あると、僕は考えています。
さらに「データ構造」については、プログラミング・インタフェースを通じて（実質上は、ポインタやリファレンスを介した受け渡しではありますが）「流れていく」ことも多いわけです。「つなぐ」対象ではなく、「そこを通じて流れていく」というイメージ。「アルゴリズム」も（関数ポインタやクロージャなどのかたちで）「流れていく」ケースがある、ということで、同様のことが言えるものと思います。
#「流れていく」イメージは、僕の場合、Standard MLなどの関数型言語を使っているときに、
# 特に強く感じられます。
ということで、あらためて最初の問いについてまとめると、
・「インタフェース」が結ぶものは「アルゴリズム＋データ構造」か?
という問いについては否定的、
・「インタフェース」が結ぶものは「オブジェクト」か?
と言う問いについては肯定的、だが「オブジェクト」に限定すべきではない
さらに言うと、「インタフェースが結ぶもの」だけではなく、「インタフェースが流すもの」にも着目すべきである
と言う回答となります。
>・「インタフェース」を(Design by Contractの)「コントラクト」に読み替えることはできるか？ （インタフェースの範囲）
DBC(Design by Contract)の「コントラクト」は「インタフェース」に包含される要素であると考えます。したがって「インタフェース」を「コントラクト」に読み替えられる場合もあり得るとは思いますが、必ずそうであると読み替えることは出来ないと思います。一例を挙げると、関数（あるいはメソッド）のシグニチャはDBCの「コントラクト」がカバーする範囲ではありません。
>・「インタフェース」＝「外部に見せているデータ構造の一部」＋「外部に見せているアルゴリズムの一部」ではないか？ （他の二要素との関係）
上記の問いがもしも
「データ構造」と「アルゴリズム」が先に存在していることを前提として、その一部を「外部に見せる」ための「のぞき穴」としてインタフェースが存在する（さらに言うと、インタフェースが存在しても、しなくても「データ構造」と「アルゴリズム」には何の変化も無い）
ということならば、そのような「インタフェース」のいうものも存在はし得るでしょう。しかし、それ「だけ」が「インタフェース」であるかと問われれば、答えはNoとなります。
一例として、Javaの"Map"インタフェースを実装したクラスとしては、ハッシュを利用した"HashMap"と、ツリーをベースにした"TreeMap"がありますが、仮にあるフレームワーク上でユーザがプログラミングを行なっている場合に、そのフレームワークが特定のメソッドを通じて、"Map"インタフェースを持ったオブジェクトを渡してくるようなケースにおいては、ユーザはその背後にいる実体が"HashMap"であるか、"TreeMap"であるかは気にしない、あるいはすべきでないということになります。
# あえて言うならばパフォーマンスなどの非機能用件が問題となる場合もあるかも知れませんが、
# それはまた別の話 :)
これのようなケースでは、「背後にいる実体」を抽象化するために、インタフェースが新たにアルゴリズム（コード）を追加することもあり得ます。「データ構造＋アルゴリズム先にありき、その後にインタフェースが追加される」ではなく、「あるインタフェースを実現するために、データ構造、あるいはアルゴリズムを追加する」というパターンです。
# う〜む、この段落、"Map"インタフェースだと具体的な例が出しにくいか…
# 本当はもっと良い例を見つけたいところですが、とりあえずこんなところで。
# さらに言うと、問いに対してきちんと答えられているかどうかは少々怪しいかもしれません。
……と、長々と書いてみましたが、いざ説明を始めるとなかなか難しいですね。疑問点がもしあればまたコメントください。
では。
「データ構造＋アルゴリズム」＝プログラムでいいと思います
インターフェイスっていうのは、もっと詳細なレベルでの設計時に検討する内容であって、概念的なレベルで大きな枠にくくれる範疇ではないと思います
多分今日では、インターフェイス＝ヒューマンインターフェイスと、オブジェクトとしての外部仕様＝インターフェイスになると思います
オブジェクトとしての外部仕様＝インターフェイス
これにはアルゴリズムと、データ構造が大きく影響します
基本的には、入力＝＞処理＝＞出力ですから、処理が求めるものを与えなければなりません
インターフェイス＝ヒューマンインターフェイス
これは、プログラムだけの問題でなく、デバイスに依存する部分が大きいと思います
これはプログラミングの世界だけの問題ではなく、機械と人とのコミュニケーションの問題になると思います
ですから、プログラムに携わる人にとっては大切な事は、「データ構造＋アルゴリズム」＝プログラムであると思います
インターフェイスにこだわり過ぎで、小手先のマジックに惑わされると本質を見失います。インターフェイスは個人の好みより、チームのルールや、可視性、読み易さをきちんと定義づけした上で設計されるものであり、データ構造とアルゴリズムが決まれば、必然的にそれらも決められます（＝ほとんど機械的に決める事が出来る）
インターフェイスの良し悪しは、モジュール設計の良し悪しで評価できます。モジュール間の連携（＝インターフェイス）が悪い物はまったく使い物になりません
と、おじさんは思います
しんのすけさんの意見に加え、プログラムも広義な言葉だと思いますので、このあたりをもう少し明確にしないと、ちょっと乱暴なような気がします。
同じような意見を、異なる「プログラム」「インターフェース」を指して議論しているように思えます。
すいません、とあるニュース記事の最近のエントリから飛んできたため、時間軸がずれたコメントを入れてしまいました。流してやっていただければ幸いです。