オブジェクト指向入門 ([著]バートランド・メイヤー, [監訳]二木厚吉, [訳]酒匂寛/酒匂順子, [版]アスキー出版局)

「Design by Contract」について知るため「7章 ソフトウェア構築への体系的アプローチ」をざっと読み。この本、すでに第2版の翻訳も出ている(手元にもある)けれど、まずは原点である第1版の方から確認。

ちなみに、第1版では「契約による設計(DbC)」ではなく「契約によるプログラミング(Programming by Contract)」と表記されている。むろん、意味するところは同じ。

DbCとは・・・以下の3つの条件を表明(assertion)することである。

• 事前条件 (precondition)
• 事後条件 (postcondition)
• クラス不変表明 (class invariant)

事前条件は、ルーチン(関数、メソッド、などなど)を呼び出す側を束縛するもので、呼び出しても良い状態を定義する。事後条件は、呼び出されるルーチン側を束縛し、制御を呼び出し側に返すときに保証しなければならない状態を定義する。クラス不変表明とはインスタンス(個々のオブジェクト)の状態に関係なく、満たされていなければならない条件のこと。

ごく簡単にまとめると、クラス/ライブラリを提供する側と使う側で決まりを作って守りましょう、ということ。単純に提供する側だけに関係する手法ではない。事前条件の確認は呼び出し側の責任とされている。

Eiffel ではこれらをスマートに記述する文法と、実行時の確実なサポートがあるのかもしれない。C/C++なら(Javaも?) assert マクロで引数チェックのようなテクニック(というかコーディング規約かもね)で実現することだし、xUnit なんかの単体テストで確認する方法もある。クラス不変表明は内部状態へのアクセスが必要だとするとクラスの外部から確認するのは難しいだろうね。となると assert 方式か。言語と環境によってはアスペクトを使うっていう手もある(らしい)。

プレファクタリング -- リファクタリング軽減のための新設計 ([著]Ken Pugh, [訳]木下哲也/有限会社 福龍興業, [版]オライリー・ジャパン) #2

3章を読んだ。ざっとまとめると・・・

アーキテクチャは大事(3.1)。インターフェイスはしっかり決めよう、できれば「Design by Contract」で(3.2)。入力として渡されたデータは検証しないと(これはDbCの裏)(3.3)。暗号のようなコードはやめて(3.4 & 3.5)。コピペすんな(3.6)。記録を残せ、とくに意図/理由/意思を書き残せ(3.7 & 3.8)。いきあたりばったりでエラー処理するな(3.9)。局所的な最適化に夢中になるな(3.10)。(一個飛ばして; 3.11)。ツールはプログラマの代わりにはならない(3.12)。

3.11 は「スプレッドシートの難問」。ここだけ、この章でかなり異質な印象を受ける。他の節ほどわかりやすくない。はっきり言えばわかりにくい。それでも著者の主張を読み取ってみると・・・

ここで言う「スプレッドシートの難問」とは、プログラミングの設計においてしばしば行うことになる選択が、表形式のデータに対して「行」、「列」のどちらからアクセスするかという問題でモデル化できる、ということ。

最初の2つの例(図3-1と3-2)は表形式のデータそのままでわかりやすい。ただ、それがどうした、と思ってしまいがち。一方で「グラフィックス(3.11.1)」と「誰が責任者か(3.11.2)」は、これが最初の2つの例と設計上の選択において、同じ構造を持っているということは直観的にはわかりにくい。文章で指摘されてもわからないかも。それどころか、図3-3のような表に描かれても何が言いたいのか、わからない可能性もある。

繰り返すが、この節の主張は「設計上の選択が、スプレッドシート(表)に行、列のどちらからアクセスするか、という問題と同型である」ということ。そして、正解は状況によって変わるんだということ。普遍的な解答はない、と。

プログラマにできることは、「これは典型的な"スプレッドシート問題"である。今回のシステムに対する○×△という要求を考慮して、ここでは"行"によるアクセスを選択する」という設計における選択の理由(意図)を記録しておくことだけ。そうすれば後からその記録を読んだ別のプログラマが、その意図をより明確に理解することができる。ただし「スプレッドシートの難問」モデルを知っていれば。モデルって言葉がアレなら「パターン」でも良い。

文化としての数学 ([著]遠山啓, [版]光文社文庫)

III 数学はどう発展したか

数学の歴史的発展 (p.148〜p.176)

数学史の時代区分

数学の発生以来の歴史を概観するために、数学史を四つの時代に分け、分け目の標識として三つの著作をあげている:

(1) 古代: 経験的、帰納的。
← (A) ユークリッドの『原論』
(2) 中世: 演繹的であり静的(『原論』の特徴)。アルキメデスはこの枠に収まらない特異な存在。
← (B) デカルトの『幾何学』
(3) 近代: 動的であり帰納的。自然科学と密着していた。
← (C) ヒルベルトの『幾何学基礎論』
(4) 現代: 構成的であり静的。

未来への展望

では、この先もヒルベルト以降の「構成的で静的な数学的構造」が数学の主役であり続けるのだろうか。著者は言う:

・・・近代数学の主役は運動と変化であった・・・いわば時間的であった。・・・これに対して現代数学では運動や変化は背景に退いて、・・・構造が正面に出てきた。それは空間的であるといえよう。・・・実在は空間的ばかりではなく時間的でもあるとすると、それに対応する数学もやはり時間的・空間的でなければならないだろう。そのような数学はいまのところ生まれてはいないが、未来の数学はおのようなものとなるかも知れない。
(p.174)

さらにウィーナーの神経生理学の将来についてのべた文を引用した後で、こう結ぶ:

それ(未来の数学のこと)は開放的で動的であり、しかも構造をもつ生体をモデルとするものであろう。そのとき今日のように「ドライ」な数学ではなく、「ウェット」な数学が生まれてくるかもしれない。

この「数学の歴史的発展」は1967年に発表されたもの。すでに40年以上前の展望だ。最先端の数学がどうなっているかは知らないが、「生体をモデルとする」ような発展はしてこなかったように思う。その代わり、コンピュータという別の動的側面を持つ存在に影響を受けて変わったのではないか?

ヒルベルト以降の数学の歴史はコンピュータの登場をもって区切れる、と考えるのは、数学よりもコンピュータに深く関わっているからだろうか?

会議力 ([著]奥出直人, [版]平凡社新書) #2

著者は会議を以下の3つに大別する。(1) 記録を残すための会議、(2) 通達のための会議、(3) 何かを作り出したり、決めたりする会議。そして、この(3)を「付加価値型の会議(ミーティング)」と呼び、これがプロジェクトを成功させるための秘訣だと言う。(p.204あたり)

以下は、その会議に関する描写:

ミーティングをすると、そのアウトプットを毎回出す。そのアウトプットを使って、また新たにミーティングをし、さらにアウトプットを出すという一連の流れを作る。

これって、うまく行っているときのソフトウェア開発プロジェクトに通じるところがあると思う。

Essentials of Programming Languages -- 3rd Edition ([著]Daniel P. Friedman/Mitchell Wand, [版]The MIT Press)

今日、Amazonから届いた。Wikipedia(英語)にページができるぐらい有名な本(教科書)。EoPL が略称。

Forewordを書いている Hal Abelson って、どこかで聞いたことのある名前だと思って調べたら、SICP の著者の一人だった。Wikipedia(英語)によれば、AbelsonとSussman(SICPの共著者)は Free Software 界隈でも著名らしく、FSFの "Board of Directors" に参加していたとか。MIT Scheme(今は MIT/GNU Scheme)は FSF ができる前から free software だったとのこと。

で、肝心の本の内容なのだけど、Forewordを読んだ感じでは・・・

「プログラマよ、インタープリタを学べ。さすればプログラミングの真髄を得られよう。すべてのプログラムはやがてインタープリタへと至るのだから・・・」

っていう感じ。出てくるプログラムは Scheme で書かれている(R5RS)。順序としては SICP か HtDP (How to Design Programs) を読んでから手を出すべきだろうなあ。じゃあ、SICP を引っ張りだしてくるか。代わりにこれを本棚にしまってこよう。