プログラミング：哲学

汎用型を使うときはちょっと注意して欲しい

αετος / aetos — Fri, 06 Feb 2009 16:20:00 GMT

コードを抽象化して汎用的な部分を切り出す。
基本的にはいいことなのですが、過ぎたるは及ばざるが如しということわざもあります。

Web時代の分散オブジェクト指向？

αετος / aetos — Fri, 02 Jan 2009 00:19:00 GMT

注：これはまとまっていない思考の断片である。

オブジェクト指向とは、端的に言えば、現実世界に存在する何らかの対象を、プログラム上に抽象化して表現する手法である。
抽象化というのは、対象が持つ無限の性質のうち、関心のある一部だけをとりあげることだ（残った無関心な部分を捨てることを「捨象」と言い、抽象と捨象は常に表裏一体である）。

たとえば、りんごオブジェクトがどのような特性を備えるべきかは、どんなシステムを作ろうとしているかによる。
果物屋の会計システムだったら「商品」の特性を持つべきかもしれないし、植物図鑑のシステムだったら「バラ科の植物」の特性を持つべきかもしれない。

これまで、この「システム」は閉じたものだった。
これが開かれるとき、何が起こるだろうか。

例えば、本を抽象化した本オブジェクトを考える。
これには様々な特性――内容、分野、著者、ページ数、出版社、etc――がある。
従来のオブジェクト指向では、本のどのような側面に着目するかによって、必要な情報セットを自分で定義していた。

昨今、本の情報を扱うWebサービスを立ち上げようと思ったら、Amazonを利用するのが王道ではなかろうか。
Amazonのサービスから取り出せる本の情報は、Amazonが管理しているものだけである。それは、本をオンライン上で販売するために必要な情報と言っていい。
Amazonのデータベースが広く公開されることで、様々な新しい可能性が拓けてくるのは周知の通りだろう。
ここで、Amazonを通じて売買するものという以外の側面から「本」を捉えることが、当然可能である。
すなわち、Amazonから取り出せるデータだけでは足りなくなってくる。

要するに、「本」というものを抽象化するにあたって、複数の視点があり、それらが協調して、インターネットという単一のシステムを構成することが現実的になりつつある（この巨大なシステムは決して完成することが無く、情報セットは絶えず変動し得る）。
この時、「本」はどのような特性を持っていて、それはどこのサービスから取り出せるか、また、他のどの情報と連携しているかといったようなメタデータが必要になってくる。

というようなのを織り込んだ体系があっても面白いなぁ、と思った、2008年最後の夜だった。

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

シャノン — 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 ); が一度成功したならば、何度実行しても必ず成功する。
逆に、一度失敗したならば、何度実行しても必ず失敗する。