プログラミング：哲学

インターフェイスの要件は最小であるべきか？

シャノン — Thu, 17 Jul 2008 16:05:00 GMT

なんだかぱっとしないタイトル。
ここで言う「インターフェイス」とは、多重継承できるあの interface じゃなくて、もっと一般的な意味でのそれです。約束事、みたいな。

例えば、メソッドの引数に何かコレクションを受け取るとして、その型はどう宣言すべきか、と。
IEnumerable<T> か、ICollection<T> か、IList<T> か、はたまた T[] か。

極めて単純無思考には T[] 。
しかし、T[] のほとんどの特性は IList<T> も備えているため、俺は個人的に IList<T> を好む傾向にある。
多次元配列なんかは、もはや配列をそのまんま使うんじゃなくて、何らかのクラスを作ったほうがいいと思う。

しかし、ランダムアクセスの必要が無ければ、IEnumerable<T> でも十分ではある。
そういう時、IEnumerable<T> とすべきか否か。

ちょっと引っかかるのは、ICollection<T> や IList<T> は無限リストを許容しないが、IEnumerable<T> は許容するというところ。
ということは、IEnumerable<T> を引数に取るメソッドは、すべからく無限リストに対応すべし、ということになるか？
遅延処理を意図したロジックならいいが、そうでない場合もあるだろう。
IEnumerable<T>.Count() なんかは ICollection<T>.Count でもよかったんじゃないだろうか。無限リストに使ったらオーバーフローしたぞ。
まぁ、ICollection<T> や IList<T> を受け取ったとして、要素数が Int32.MaxValue 個ある場合にちゃんと処理できなければならない、というのもなかなか酷ではあるのだが。

また、これは感覚的な問題でもあるが、用途としては IEnumerable<T> で十分であっても、IList<T> を使いたいという心情もあると思う。
ちょっと前の var 論争でもあった意見だが、「IEnumerable<T> ではコレクションのような気がしない。IList<T> ならコレクションであるという意図が込められる」みたいな。

また別問題ではあるが、独自のデータ構造を作るか否かという問題もある。
例えば、Pair<T, U> という既存の型があった場合、あらゆる2値の組み合わせは Pair<T, U> で事足りるか、ということ。
Pair<T, U> は、それぞれの値の意味を理解しないので、.First とか .Second とかいうメンバ名にならざるを得ない。
人の名前を表すのに、FirstName と LastName というメンバを持つクラスを作るか、Pair<string, string> で済ませるか、とか。
独自のデータ型を作らずに既存の型を最大限活用した場合、

メンバの意味がわかりにくくなる
ジェネリックの入れ子が深くなる

という問題が発生するわけだが、どうよ？　という。

車なんて…っ！

シャノン — Wed, 09 Jul 2008 13:56:00 GMT

思わずこんなタイトルをつけてしまったが、車ではなくてオブジェクト指向のお話。

車はガソリンがなければ動きません（ディーゼル他、非ガソリン車はとりあえず置いといて）。最近高いですね、ガソリン。
ご存知のように、ガソリンにはレギュラーと廃屋ハイオクがあります。
レギュラー用のエンジンにハイオクを入れても大丈夫ですが、ハイオク用のエンジンにレギュラーを入れると壊れてしまいます。

面倒なのでコードは載せません。各々補完してください。

車クラスとガソリンクラスがあります。
車クラスには、ガソリンのインスタンスを引数に取る給油メソッドがあります。
車クラスから、ハイオク専用車クラスを派生させます。
このハイオク専用車クラスの給油メソッドの引数は、多くの言語ではガソリンになりますが、実際にはガソリンから派生したハイオクガソリンを渡さないと壊れてしまいます。

I車インターフェイスではなく車クラスから派生させるのは、レギュラー用エンジンを積んでいる車には（悪質なものでない限り）どんなガソリンを入れても大丈夫だからです。この点において、レギュラー車はハイオク車より抽象的です。
ハイオク専用車も車の一種には違いなく、ハイオクガソリンもガソリンの一種には違いないのに、車とガソリンに結合が関係があるとき、これらを継承関係にするとうまく行きません。

よくある「ペンギンは鳥か？」論によれば、いくつかの結論のパターンがあります。
たとえば、

現実世界がどうであれ、このプログラム中では、どんなガソリンでも給油できるものを車と定義したのだから、ハイオク専用車はその意味では車ではなく、車クラスから派生させることは不適当である
ハイオク専用車の給油メソッドでは、実際に給油されたガソリンの動的な型を判別して、ハイオクガソリンでなければ例外を投げればよい。

というような。

1は、「ペンギンは鳥か？」論でもそうですが、常識的に考えて「そんな馬鹿な」と言いたくなります。
まして、ペンギンと鳥は実際にも姿形も生態も大きく異なるのに対し、今回の例では、より違いが少ないだけになおさらです。
2は現実的な解かもしれません。しかし、極論を言ってしまえば、型のエラーをコンパイル時に検出できないなんて、静的型システムに何の意味があるというのでしょうか？
もちろん、完璧主義に走るべきではなく、完全に検出できないからと言って全く役に立たないわけではないという意見は一理あります。
しかし、完璧を求めてうまく行く方法があるとしたら、それを求めないのは罪というものです。

さて、お題です。
このような状況下でも、静的な型チェックを機能させる方法はあるのでしょうか？

こういう仕様の新しい言語を作ればうまく解決できる
既存の言語にこういう拡張を施せばうまく解決できる
実は拡張しなくても既存の言語でうまく解決できる
そもそも問題設定に無理があって、どうやっても解決は無理、または不要
だから動的言語を使えっつってんだろ
他

既成概念に囚われない答えを募集します。

喜ぶべきか悲しむべきか

シャノン — Sun, 08 Jun 2008 13:03:00 GMT

オブジェクト指向を突き詰めていくと、どうしても動的言語に行き着いてしまう気がする。
考えれば考えるほど、「基底クラスと派生クラスの関係」と「クラスとインスタンスの関係」に違いがないように思えてくる。
「静的型チェック」は「プログラミング」に要請されることではあるが、「オブジェクト指向」に要請されることではないものなぁ。

ぶっくまーく

シャノン — Sat, 10 May 2008 15:44:00 GMT

面倒になったので列挙ストップ。あとは各ページのリンクなりトラックバックなりを辿るべし。
しかし、何が書いてあるんだかさっぱり理解できねぇじゃねーかちくしょうめ。

眠れぬ夜の空想

シャノン — Thu, 01 May 2008 12:09:00 GMT

これはなかなか寝付けない夜にとりとめもなく考えていた空想であり、そのまま考えていては朝になってしまうので強制的に打ち切った思考の断片である。

人間を、年齢層と性別で分けることを考える。

		年齢層
		10歳未満	10代	20代	30代	…
性別	男				A
性別	女		B

この表全体を「人間クラス」としたとき、AおよびBは何か。

まず、年齢層や性別を人間クラスのプロパティとし、AやBが入っている表のセルをインスタンスであると考えてみる。
すると、こうなる。

enum 年齢層 { 10歳未満, 10代, 20代, 30代, 以下略 }
enum 性別 { 男, 女 }
class 人間 { 年齢層 age, 性別 sex }

人間 A = new 人間(); A.age = 年齢層.30代; A.sex = 性別.男;
人間 B = new 人間(); B.age = 年齢層.10代; B.sex = 性別.女;

表の列も行もセルも、すべてクラスであると考えると、こうなる。

class 人間 {}
class 10歳未満の人間 : 人間 {}
class 10代の人間 : 人間 {}
class 20代の人間 : 人間 {}
class 30代の人間 : 人間 {}
class 男 : 人間 {}
class 女 : 人間 {}
class 10歳未満の男 : 10歳未満の人間, 男 {}
class 10歳未満の女 : 10歳未満の人間, 女 {}
中略
class 30代の男 : 30代の人間, 男 {} // A
class 10代の女 : 10代の人間, 女 {} // B

ただし、これは素朴には、こういうことがありうる。

class 矛盾した人間 : 10代の人間, 20代の人間, 男, 女 {}

先にずらずらと列挙した例では、例えば「20代の男」は「20代、かつ、男」であった。
すると、この矛盾した人間は、「10代であり20代、かつ、男であり女」になってしまう。
現在の多重継承が可能な言語では、こういうクラスを作ることができてしまう。
だが、意図したところは、「年齢層から１つ、性別から１つを多重継承する」である。

コンパイルエラーにするにはまだ練り足りないが、もう少しだけ意図を追加してみる。
例えば C# の属性風に。

// 人間の具象派生クラスは、年齢層と性別から１つずつを多重継承すること！
abstract class 人間 {}

[ ClassCategory( "年齢層" ) ] abstract class 10歳未満の人間 : 人間 {}
[ ClassCategory( "年齢層" ) ] abstract class 10代の人間 : 人間 {}
[ ClassCategory( "年齢層" ) ] abstract class 20代の人間 : 人間 {}
[ ClassCategory( "年齢層" ) ] abstract class 30代の人間 : 人間 {}
[ ClassCategory( "性別" ) ] abstract class 男 : 人間 {}
[ ClassCategory( "性別" ) ] abstract class 女 : 人間 {}
class 10歳未満の男 : 10歳未満の人間, 男 {}
class 10歳未満の女 : 10歳未満の人間, 女 {}
中略
class 30代の男 : 30代の人間, 男 {} // A
class 10代の女 : 10代の人間, 女 {} // B

さらに C# の延長として、System.Type から複数の親クラス情報を、カテゴリ別に取得できると想定してみよう。

Type type = typeof( 30代の男 );
Type ageType = type.BaseTypes[ "年齢層" ]; // ageType == typeof( 30代の人間 );
Type sexType = type.BaseTypes[ "性別" ]; // sexType == typeof( 男 );

ここで唐突に、C# から JavaScript にターゲットを変えてみる。
といっても、これまでの流れから明らかなように、JavaScript チックな実在しない空想言語である。

JavaScript では、実行時にプロトタイプを変更することができる。
これは、C# のような静的型付けの言語では、親クラスの変更に相当するだろう。
では、多重継承に相当するように、プロトタイプを複数持つことができたとしたら？　ついでに、それが JavaScript お得意の名前つきマップだとしたら？
こんな形になるんじゃないだろうか。

（面倒なのでクラス定義を一部省略した）
function 人間() {}

function 30代の人間() {}
30代の人間.prototype = new 人間();

function 男(){}
男.protptype = new 人間();

function 30代の男() {}
30代の男.prototypes[ "年齢層" ] = new 30代の人間();
30代の男.prototypes[ "性別" ] = new 男();

この JavaScript モドキのコードと、一番最初に挙げた C# モドキのコードを見比べてみる。
ちょっと変更して再掲しよう。

人間 30代の男 = new 人間();
30代の男.age = 年齢層.30代;
30代の男.sex = 性別.男;

実によく似た形をしている。

…というところまで考えて寝た。

制約

シャノン — Tue, 18 Mar 2008 14:16:00 GMT

「どんなデータでなければならないか」をプログラミング言語で書くのは容易だが、「どんな処理をしなければならないか」を書くのは困難である。
「その処理をした後にデータはどうなっていなければならないか」なら書けるが、それでは「どんな処理をしなければならないか」を完全に代替できない。

System.Drawing.Point

シャノン — Sun, 17 Feb 2008 00:53:00 GMT

２次元座標を表す、おなじみのPoint構造体。
こいつがSystem.Drawing名前空間にあることは、ちょっとした不満である。

理由は簡単で、２次元座標とは、何も描画するときだけに使うものではないからだ。
たとえばControl.Locationプロパティに使われるが、Locationプロパティを設定することは、何かを描画しているという意識なく行われるだろう。
だが、Windowsはウィンドウの移動を裏で描画しているわけだし、また、ピクセル単位での座標指定に使うものであると拡大解釈して、なんとか自分を納得させてきた。

だが、つい先ほど、ひょんなことから、DataGridView.CurrentCellAddressというプロパティを知ってしまった。
この型はPointであるが、単位はピクセルではない。DataGridViewのアクティブセルの行および列のインデックスである。
また、DataGridViewは、この座標を用いて何かを描画することもない。
ここへきて完全に、PointがDrawing名前空間にあることを正当化する理由は消えた。

だが、いくら文句を言ったところで、Point構造体がDrawing名前空間を脱することはないだろう。
だから、ここから先は妄想の域を出ない話だ。

そもそも、Point構造体を、座標の単位を意識せずに、単なる２つの座標のペアとして扱うことは正しいのだろうか。
それとも、表すものの単位ごとに異なるデータ型を用意すべきだったのだろうか。
あるいはまた、２次元座標であるという意味さえ捨てて、Pair<int, int>のようなもので統一してしまうことは是なのだろうか。
なかなか難しい問題ではないかと思うが、どうだろう。

同値関係

シャノン — Tue, 11 Dec 2007 10:38:00 GMT

あるインスタンスnがある。このインスタンスの真の型（動的な型）は問わないものとする。

反射律：nの静的な型がAであるならば、nをAにキャストできる。
対称律：nの静的な型がAであり、これをBにキャストできるならば、再度Aにキャストできる。
推移律：nの静的な型がAであり、これをBにキャストしてからCにキャストできるならば、直接AからCにキャストできる。

この特徴は、特にCOMのQueryInterfaceにおいて顕著である。
余談だが、COMのキャスト規則も書いておく。

反射律：nの静的な型がIFooであるならば、n->QueryInterface( IID_IFoo, &m ); は成功する。
対称律：nの静的な型がIFooであり、n->QueryInterface( IID_IBar, &m ); が成功するならば、m->QueryInterface( IID_IFoo, &o ); は成功する。
推移律：nの静的な型がIFooであり、n->QueryInterface( IID_IBar, &m ) が成功し、かつ m->QueryInterface( IID_IPoo, &o ); が成功するならば、n->QueryInterface( IID_IPoo, &o ); は成功する。
nの型に関わらず、n->QueryInterface( IID_IUnknown, &m ); は常に成功する。
かつ、m の値は何度実行しても必ず同じになる（IUnknown 以外へのキャストの場合は同じになるとは限らない）。
n->QueryInterface( IID_IFoo, &m ); が一度成功したならば、何度実行しても必ず成功する。
逆に、一度失敗したならば、何度実行しても必ず失敗する。

集合の集合　リベンジ

シャノン — Wed, 21 Nov 2007 10:53:00 GMT

以前書いたエントリで、「集合の集合」がよくわかんねぇ、とか言ってた。
で、いろいろな方からヒントを頂いて、正直なところ、「あれ？　俺が悩んでたのはそんなことだったんだっけ？」と思った。

で、昨日のエントリを書いたことで、当初の疑問を思い出した。

クラスとは、インスタンスの集合であるとする。
派生クラスとは、基底クラスの部分集合であるとする。

クラスの継承関係は、基本的には抽象度に着目して行うべきだ。
基底クラスは派生クラスよりも情報量が少なく、抽象度が高い。
これは、別の言い方をすれば「内包が小さく、外延が大きい」とも言う。

では、クラスとインスタンスの関係はどうか？
クラスとインスタンスの関係も、抽象度の違いがあるはずだ。
よく使われるたとえ話に「犬クラスと、そのインスタンスであるポチ」がある。
犬クラスは、個々の犬の名前を捨象している。

ここで「ポチクラスを作ろう」というのではない。逆だ。

昨日の話では、XMLクラスの派生クラスとしてXHTMLやXAMLを置き、そのインスタンスとして、それらの言語で書かれた文書を挙げた。
だが、XHTMLやXAMLといった言語を、XMLクラスのインスタンスとしてもよかったのではないか？　と思うわけだ。
そうしたとき、個別言語は、XMLクラスのインスタンスであると同時に、各文書のクラスでもある。
集合論の言い方をすれば、XMLクラスは「クラスの集合」であり、「集合の集合」であることになる。

現在、主流のオブジェクト指向言語では、クラスのクラスを記述できない。
Java の ClassLoader とか .NET の System.Type は、ある意味で「クラスのクラス」だが、XML の例とは抽象化の方向性が違うように思う。

うまくまとまらない。むーん。

オブジェクト指向バックエンド

シャノン — Mon, 19 Nov 2007 14:19:00 GMT

なんつーか。

数学とか、哲学とか、言語学とか、論理学とか、心理学とか。
そういった学問ってのは、古くは紀元前の昔からあったわけです。
で、極めて大雑把に言えば、それらはある意味、現実世界のモデル化を行うわけです（それ以外にもいろいろやるだろうけど）。

それでですね。
オブジェクト指向っていうのも、現実世界をコンピュータの中にモデル化する手法なわけで。
共通点があるんですね。

別の側面から見てみると、例えばデザインパターン。
Template Method なんてのは、そうと知らなくても使っていたりしますよね。
デザインパターンってのは、要するにノウハウ集なわけです。
デザインパターンが偉大なのは、その暗黙知を明文化して整理して、なにより命名したという点にあります。…が、それは置いといて。

学問とオブジェクト指向の共通点を調べてみると、学問は知らなかったけれど、それに相当するオブジェクト指向上のノウハウは知っていた、とかあるわけですよ。学問版の Template Method みたいにね。
現場で積み重ねた経験と、学問上のセオリーが同じ形をしていた、というか。
そういう時、明文化された学問の方を知っているのといないのでは、出来上がりにちょっとは差が出てくるんじゃないかな？　と思うわけです。

デザインパターンだけ本で勉強しても、現場の経験が無ければプログラムは作れない。
デザインパターンを知らなくても、現場の経験があればそこそこのものが作れる。
デザインパターンを知っていて、かつ、現場の経験があれば、すばらしいものが作れる。
この文中の「デザインパターン」を「諸学問」に置き換えても、同じことが成り立つと思うのですよ。

そういった、オブジェクト指向（に限らなくてもいいけど）に応用できるような学問を、オブジェクト指向に応用するために、という視点で、贅沢を言えば分野横断的に勉強できればナァ…という思いが、もう結構長いこと燻ってまして。
金をためて会社辞めて大学へ行くことを真剣に考えてます。

そういう切り口で書いてあるモノを読んでみたいと思っているのですが、誰か書かない？