2008年第1四半期購入本リスト

雑談 本

2008年の1〜3月に購入した本です。Totalで72冊，10万ちょっとでした。「王様の仕立て屋」を1〜17巻まで揃えたために，去年の平均と比較すると冊数は多めで平均単価は下がり気味です．
仕入れも大目ですが，3月末に10冊ちょい一気に購入したため在庫も大目というところでしょうか．

ちなみに，「SEのための「どこでもやれる力」のつけ方」が2冊あるのは誤植ではなく，立ち読みして良さそうだと思って買ってから放置していたら，もう一度立ち読みして良さそうだと思って買ってしまったものです*1．


しかし，年間10^2の単位で本が増えていくと，そろそろ本気で本の収納スペースが枯渇してきました．昔の本を処分するしかないかも．

                                                                                                    • -

4-2-3-1　サッカーを戦術から理解する
ウチのシステムはなぜ使えない　SEとユーザの失敗学
おもてなしの経営学　アップルがソニーを超えた理由
Ruby on RailsによるWebアプリケーションスーパーサンプル
SEのための価値ある「仕事の設計」学　決定版!!顧客満足度No.1となって開ける突破口から窺われた「人生設計」の肯綮
SEのための「どこでもやれる力」のつけ方　管理者としてもフリーとしても大成できる自立と協調の極意
日本のソフトウェア産業がいつまでもダメな理由
アジャイルプラクティス　達人プログラマに学ぶ現場開発者の習慣
EngineerMIND vol.9
開発の現場　特別版 vol.002
IT技術者としていきぬくための十ヶ条
絵で見てわかるOracleの仕組み　アーキテクチャと動作を徹底図解
王様の仕立て屋15
王様の仕立て屋17
王様の仕立て屋14
王様の仕立て屋16
3時間で「専門家」になる私の方法
ケースで学ぶ意思決定の手法　定量分析実践講座
BEST SOFTWARE WRITING
王様の仕立て屋9
王様の仕立て屋10
王様の仕立て屋11
王様の仕立て屋12
王様の仕立て屋13
情報処理技術者試験対策書　データベース2008　徹底解説本試験問題
ベテランが丁寧に教えてくれる　データベースの知識と実務
STUDY HACKS!　楽しみながら成果が上がるスキルアップのコツと習慣
本質を見抜く「考え方」
実践的データモデリング入門
視点をずらす思考術
SEからコンサルタントになる方法
「食い逃げされてもバイトは雇うな」なんて大間違い　禁じられた数字（下）
国語算数理科しごと　子供と話そう「働くことの意味と価値」
ニセ科学を見破る思考実験　白い仮説黒い仮説
はじめての課長の教科書
ビジネスの基本を知っているSEは必ず成功する
C言語デバッグ完全解説　プログラムが動かない理由
すごい「議論」力
お金持ちになりたかったら財布は持つな。
SEのための「どこでもやれる力」のつけ方　管理者としてもフリーとしても大成できる自立と協調の極意
夢中の法則　集中力がアップするしくみ
ドキュメントハックス−書かない技術　ムダな文書を作り方からカイゼンする
上級の時間術
美容院と1000円カットでは，どちらが儲かるか？
文字コード超研究
王様の仕立て屋5
王様の仕立て屋6
王様の仕立て屋7
王様の仕立て屋8
開発の現場 vol.11
EngineerMIND vol.8
カリスマ・コンサルタントの稼ぐ20超思考法　仕事と人生に効く「問題解決力」が身につく20の方法
効率が10倍アップする新・知的生産術　自分をグーグル化する方法
1週間で実践論理的会話トレーニング
プロ弁護士の思考術
思考の整理学
「残業ゼロ」の仕事力
悪玖夢博士の経済入門
決算書の暗号を解け！　ダメ株を見破る投資のルール
詳解 Oracleアーキテクチャ
王様の仕立て屋1
王様の仕立て屋2
王様の仕立て屋3
王様の仕立て屋4
構造化ユーザインタフェースの設計と評価　わかりやすい操作画面を作るための32項目
48のキーワードから学ぶ実践プロジェクトマネジメント
ユーザビリティエンジニアリング　ユーザ調査とユーザビリティ評価実践テクニック
提案・開発・トラブルに勝つ！SEのための聞く技術
こんなSEはいらない
コンピュータシミュレーション
独習アセンブラ
リファクタリング　プログラムの体質改善テクニック

*1:しかも多分同じ店で

「a」は「一つの」ではない

雑談

前回のエントリの補足．Microsoftの翻訳文書*1を誤読したという話だが，では原文*2だったらそんな誤読は起きないのか．
訳文で「呼び出し元」を「呼び出し先」と読み違えていたわけで，迂闊な我輩としては原文の「calling」を「呼び出し先（called)」と読み違える可能性は十分ある．


しかし，原文の「a thread」を「どこか一つのスレッド」と誤読することはない．なぜかというと，「a」はどこか1つのという意味には成り得ないからだ*3．英語を勉強し始めて最初の方に習う「a」の直訳「一つの」を杓子定規に適用すると誤訳となるケースは多い*4．「a」は「どこぞの馬の骨とも知れない何か」につく冠詞ではなく，「存在するのが自明なある一つのもの」につく冠詞である．
よって，「a thread」という文からは「存在することは自明だしわざわざ強調して言うまでもないスレッド」というニュアンスが読み取れる．このケースで存在することが自明なスレッドは「呼び出し元」か「呼び出し先」のどちらかしかない．


では，「a thread」が「呼び出し元スレッド」を指してるのか「呼び出し先スレッド」を指しているのか意識して前の方を読み直してみれば「the calling thread」と書いてあり，前出のスレッドは呼び出し元であることがちゃんと分かる．
日本語の文章を誤読した時には，「1つのスレッド」を「どこか1つのスレッド」と読み取ってしまい，消去法で後の文章を「呼び出し先スレッド」と誤読したのである*5．


別段，英語万歳日本語だめだめというわけではないが，複数の意味に解釈できる変な訳文よりは人が書いた原文を読んだほうがわかりやすいという話でした．っつか，

このスレッドが終了するのを待機します。

　　　--from Java document(Thread.join)
って書いてくれれば何の迷いもなかったのだが・・・．

*1:1 つのスレッドが終了するまで呼び出し元のスレッドをブロックします

*2:Blocks the calling thread until a thread terminates

*3:その場合は「any thread」となるはず

*4:同様に「the」を「その」と訳すのもそうかも

*5:なぜかというと，スレッドオブジェクトに対するインスタンスメソッドの呼び出しで呼び出し先のスレッドに言及しないことがあるはずがないからである

fatalなmistake

C# Tips

C#でスレッドの制御がどうもうまく動かないと思っていたら，どうやら致命的な勘違いをしていたようだ．


Thread.joinは「コールした先のスレッドが終了するまで現状のスレッドを待機する」メソッドのはずなのだが，「どれか一つのスレッドが終了するまでコールしたスレッドを待機する」と誤解した．ちなみに，誤解の元となったMicrosoftのドキュメントの解説文がこれ，

1 つのスレッドが終了するまで呼び出し元のスレッドをブロックします。

一応，呼び出し元ってきちんと書いてあるところを見逃したのが原因なのだが，なんとも解釈のし辛い文章だ．ちなみに，英文だとこう．

Blocks the calling thread until a thread terminates

確かに直訳だとそうなのだろうが，この場合のa threadを1つのスレッドと訳すのは勘弁してくれ*1．

*1:これからはMicrosoft技術ドキュメントの怪しい解説は素直に原文に当たることにします

Debug.Assertの遅延評価

設計 C#

以前にC#によるDesign by Contractのやり方を紹介した．簡単におさらいしておくと以下のように実装する．

  using System.Diagnostics

  public class Foo
  {
    public void Bar(object baz)
    {
      Invalid()  //不変条件
      //事前条件
      Debug.Assert(baz != null);

      //処理
      //・・・

      //事後条件
      Debug.Assert("処理の結果・・・");
      Invalid()  //不変条件
    }
  }

  //不変条件
  protected void Invalid()
  {
    Debug.Assert(...);
    ...
  }

これで，コンパイル定数にDEBUGが定義されているときのみ，Contractのチェックが行われる．リリース時にはDebug.Assertのコードが評価されないため，速度の劣化の心配もない*1．


さて，以前遅延評価をネタにしようとした時に問題としてあげたのが，Debug.Assertの先行評価である．Debug.Assertはリリース時には評価を行わないことで速度の劣化を防ぐのだが，上記コードの

  Debug.Assert(buz != null)

の部分でbuz != nullが評価されてしまうと，その分速度の劣化へとつながってしまう．この程度の評価ならたいした事はないかもしれないが，ちりも積もれば山となることもあるし，評価によってはそれ自体それなりの負荷がかかるケースもある*2．


そこで，Debug.Assertの引数部分を関数でクロージングし，デバッグ時のみそれを評価するようにして遅延評価を実装してみる．

using System;
using System.Diagnostics;

namespace Sample
{

  public delegate Boolean Assertion();
  
  public class LazyDebug
  {
    public static void Assert(Assertion func)
    {
      #if DEBUG
        Debug.Assert(func());
      #endif
    }
  }
  
  public class LazyEvaluation
  {
    public int LazyAssert()
    {
      int i = 0;
      LazyDebug.Assert(delegate() { return ++i == 1; });
      LazyDebug.Assert(delegate() { return ++i == 1; });  //(*)Debag時にはAssertに引っかかる
      return i;
    }
    
    public static void Main()
    {
      LazyEvaluation le = new LazyEvaluation();
      
      Console.WriteLine(le.LazyAssert());
    }
  }
}

上記コードは，デバッグでは(*)行でAssertに引っかかり，エラーを発行する．しかし，リリースでは正常に動作し，画面には0が表示される．すなわち，Assertのみならず ++i == 1 も評価されていないことが分かる．また，(*)行をコメントアウトしてデバッグで実行すると，画面には1が表示される．デバッグとリリースで評価が異なるため取り扱いに注意は必要だが，デリゲート内部にどんな処理を書いてもリリース時には実行されないため，思う存分条件のチェックを入れることができる．


・・・とは言うものの，この程度の評価だと実は上記のコードは全く無意味だったりする．実は，C#のDebug.Assertは既に遅延評価(のようなもの)が実装されているからだ*3．
確認のために，以下のコードを実行してみよう．

using System;
using System.Diagnostics;

namespace Sample
{
  public class LazyEvaluation
  {
    public int DefaultAssert()
    {
      int i = 0;
      Debug.Assert(++i == 1);
      Debug.Assert(++i == 1);  //(*)Debag時にはAssertに引っかかる
      return i;
    }
    
    public static void Main()
    {
      LazyEvaluation le = new LazyEvaluation();
      
      Console.WriteLine(le.DefaultAssert());
    }
  }
}

先ほどのコードと同じように，デバッグでは(*)行でAssrtに引っかかり，リリースでは画面に0が表示される．実際のところは遅延評価というより，リリース時にはDebug.Assertの行を引数ごと取っ払ってコンパイルしているのではないかと推測される．


というわけで，Booleanの比較のみで十分ならわざわざ小細工を労するまでもなく真っ当に使用すればよい．が，ここまで考察しといてその結論ではちょっと癪なので，小細工を入れてみる．

using System;
using System.Diagnostics;

namespace Sample
{

  public delegate void Assertion();
  
  public class LazyDebug
  {
    public static void Run(Assertion func)
    {
      #if DEBUG
        func();
      #endif
    }
  }
  
  public class LazyEvaluation
  {
    public void LazyAssert()
    {
      Invalid();  //不変条件
      LazyDebug.Run(delegate() {
        //事前条件
        Debug.Assert(...);
      });
      
      //処理
      //.....

      LazyDebug.Run(delegate() {
        //事後条件
        Debug.Assert(...);
      });
      Invalid();  //不変条件
    }
   
    //不変条件
    public void Invalid()
    {
      LazyDebug.Run(delegate() {
        Debug.Assert(...);
      });
    }
    
    public static void Main()
    {
      LazyEvaluation le = new LazyEvaluation();
      
      Console.WriteLine(le.LazyAssert());
    }
  }
}

上記のように条件の評価そのものではなく条件を評価する一連の行をクロージングしてやれば，それ自体がリリース時には評価されなくなる．評価するものを取得するためにロジックが必要な場合などに若干の効果を発揮することもあるような気がする．デリゲートによる見栄えの悪化や若干の行数の増加，見慣れぬやり方強制等のデメリットをカバーできる価値があるかどうかは疑問が残るところではある．

*1:最も，Design by Contractの機能が言語に組み込まれているものと比較すると多少の見栄えの悪さは否めない

*2:特に不変条件と事後条件のチェックはまともにやると概ねそうなりがち

*3:このネタを書くまで全く気がつかなかった．Microsoftのヘルプはいつもながら重要な事項が抜けてないか？ある意味トラップになりかねんぞ．

2007年MVB　−　エンジニア部門

雑談 本

去年買った本を一覧にしてみたが，見返してみるとまだ読んでない本が結構あることに気が付いた．興味自体はすでに過ぎているのでしばらく（又はほとんど）読まれることはないと思うが，それもまた投資である．


去年買った本で最も良かった本の一つがこれ．

我らクレイジー☆エンジニア主義 (講談社BIZ)

我らクレイジー☆エンジニア主義 (講談社BIZ)

必ずしも有名ではないが，どこか突き抜けた熱いエンジニア達のインタビュー集である．
彼かが心底自分たちの仕事（研究・趣味と置き換えても良い）を夢中になって，楽しんでいる様子がわかり，読むたびにエネルギーが沸いてくる本である．
自分も彼らのように夢中になって何かをやり抜く，それはきっと楽しいことだと思い返すために，常に手元に置いておきたい．

2007年購入本リスト

雑談 本

2007年に買った本のリストです．マンガ，ラノベ含めて191冊でした．去年が大体130冊前後だったから，1.5倍にいかないぐらい増えてますね．消費した金額も同じぐらい増えてます．ヨーロッパで2週間ぐらい遊べるぐらいかな？


にしても，去年の本の冊数と金額はたしかmixiに書いてたと思うんだが，検索不能．検索できないんじゃあんまり書いてる意味ないよなぁと思わなくもない．

                                                                                                    • -

朝11時までメールは読むな！　「後悔しない決断」の技術
非属の才能
不完全性定理　数学的体系のあゆみ
「財務３表のつながり」で見えてくる会計の勘所
レバレッジ勉強法
やりたいことは全部やれ！
Rubyアプリケーションプログラミング
考具　考えるための道具、持っていますか？
詳解Tcl/Tk GUIプログラミング
大前流心理経済学　貯めるな使え！
Rubyを256倍使うための本　界道編
ネーミングの掟と極意
Engineer MIND vol.7
初心者のためのLinuxコマンドリファレンス
プログラミングASP.NET2.0
Ajax on Rails
仕様変更なんて恐くない！　ビジネス環境の変化に強いデータベース設計
ゲームで極める　シェルスクリプトスーパーテクニック
便利なツールEmacsらくらく入門
プロとしてのPL/SQL入門
入門 GNU Emacs 第3版
SVG Programming: The Graphical Web(Professional Design Series)
ASP.NET AJAX入門　待望のAJAXフレームワークリッチクライアント開発。
ネットワークはなぜつながるのか　知っておきたいTCP/IP、LAN、光ファイバの基礎知識
Debian辞典
そこが知りたい最新Webアプリ開発のお作法　アーキテクチャと開発プロセスの正しい理解
開発の現場 vol.010
計画の科学　どこでもつかえるPERT・CPM
プリンシプルのない日本
戦略論　戦略コンセプトの原点
お金の使い方でわかる　大人の「品格」
ハッカーと画家　コンピュータ時代の創造者達
涼宮ハルヒの陰謀
涼宮ハルヒの憤慨
涼宮ハルヒの分裂
経営入門
だらしない人ほどうまくいく
涼宮ハルヒの消失
涼宮ハルヒの暴走
涼宮ハルヒの動揺
ロウアーミドルの衝撃
勝つDBエンジニアのキャリアパス　データベーススキルの磨き方と活かし方
ハッピィ・エンジニアリング　新しいシステム開発の処方箋
涼宮ハルヒの溜息
涼宮ハルヒの退屈
涼宮ハルヒの憂鬱
涼宮ハルヒの溜息
涼宮ハルヒの退屈
涼宮ハルヒの消失
アート・オブ・SQL　パフォーマンスを引き出すSQLプログラミング手法
プログラマー現役続行
いちばんやさしいPMBOKの本
オブジェクトデザイン　ロール、責務、コラボレーションによる設計技法
問題プロジェクトの火消し術　究極のプロジェクト・コントロール
困ったときの50のテクニック　SEとして生き抜くワザ
標準C#入門
失敗学　デザイン工学のパラドクス
反社会学講座
ファミリーコンポ 8巻
ファミリーコンポ 13巻
Visual StudioとASP.NETによる業務システム開発方法　実践！ソフトウェアアーキテクチャ
誰でもわかるセキュリティ設計　すぐに役立つ5つの業務別セキュリティ構築ガイド
Itアーキテクトのためのシステム設計完全ガイド2008　今知っておきたい技術・製品・方法論
通勤大学実践MBA　決算書
アカウンティング入門
会計力と戦略思考力
通勤大学MBA15　統計学
通勤大学MBA4　アカウンティング
水はなんにも知らないよ
日本人は、なぜ同じ失敗を繰り返すのか　撤退戦の研究
ブラックジャックによろしく11巻
ブラックジャックによろしく12巻
ブラックジャックによろしく13巻
食い逃げされてもバイトは雇うな　禁じられた数字<上>
「計画力」を強くする　あなたの計画はなぜ挫折するか
基礎から学ぶSEの会計知識
基礎から学ぶSEの金融知識
外資系トップの仕事力
営業センスは捨てろ!　業績をあげるための逆転の発想
その道のプロが教える　秘密の勉強法
無理なく続けられる年収10倍アップ勉強法
外資系トップの仕事力
はじめてのASP.NET 2.0プログラミング　Visual C# 2005編
チーム　ハックス　仕事のパフォーマンスを３倍に上げる技術
開発の現場 vol.009
数学ガール
レバレッジ・シンキング
７つの習慣
世界一やさしい問題解決の授業
上級の勉強術
パッケージから学ぶ4大分野の業務知識
Seasar2で学ぶDIとAOP　アスペクト思考によるJava開発
Spring2.0入門
JavaからRubyへ　マネージャのための実践移行ガイド
ソフトウェア開発に役立つマインドマップ　チームからアイデアを引き出す図解・発想法
業務に使えるAjax
脳は直感している　直感力を鍛える７つの方法
The Ruby Way - Ruby道への招待
増殖改訂版 Java言語で学ぶデザインパターン入門　マルチスレッド編
地球の歩き方 '06〜'07 香港マカオ
ひるむな！上司 二人以上の部下を持つ人のために
Engineer MIND vol.4
アジャイルプロジェクトマネジメント 最高のチーム作りと革新的な製品の法則
アプリケーション開発を成功に導く システム基盤の構築ノウハウ
使いやすさのためのデザイン ユーザーセンタード･デザイン
豆蔵セミナーライブオンテキスト2 UMLモデリング
5つの図で整理する 自分の考えをまとめる技術
ビジネスの常識"を疑え！"
小富豪のための香港金融案内
パイロットが空から学んだ危機管理術
パイロットが空から学んだ一番大切なこと
ビックコミックオリジナル
Ruby on Rails入門 優しいRailsの育て方
お金の聖書 幸せで豊かになる力が、絶対身につく本
デザイニング・インターフェース　パターンによる実践的インタラクションデザイン
ゲーム開発で学ぶAjax入門
なぜあの人は会社を辞めても食べていけるのか？　会社にいても、飛び出しても、うまくいく人の考え方･仕事のやり方
ものを考える人
「話す」「書く」「聞く」能力が仕事を変える！　伝える力
ジュワッと！100スキCOOKING - 100円ショップの小さな鉄のフライパン
Prost! vol.1 - 家メシ。旅メシ。男メシ
お金の聖書 幸せで豊かになる力が、絶対身につく本
Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック
自分の小さな「箱」から脱出する方法
人材要らずの営業戦略
アート・オブ・プロジェクトマネジメント　マイクロソフトで培われた実践手法
実践!問題解決法
ビジネス力の磨き方
決定版!「ベンチャー起業」実践教本
開発の現場 vol.008
システム分析・モデリング100の処方箋
人を動かす
質問力 論理的に｢考える｣ためのトレーニング
お金の聖書 幸せで豊かになる力が、絶対身につく本
JUnitによるテストファースト開発入門
なぜ、仕事ができる人は残業をしないのか？
問題は、解いてはいけない。
プロマネはなぜチームを壊すのか　知っておきたいプロジェクトのヒューマンスキル
ウエブユーザビリティの法則　ユーザに考えさせないためのデザイン・ナビゲーション・テスト手法
開発の現場　特別版vol.001
Ｄ言語パーフェクトガイド
道具としてのファイナンス
会計を使って経済ニュースの謎を解く
プレリファクタリング　リファクタリング軽減のための新設計
「おもしろい」のゲームデザイン A Theory of Fun for Game Design　楽しいゲームを作る理論
プロエンジニアが走るとき、跳ぶとき　10のハードル
エンジニアが30歳までに身につけておくべきこと
つっこみ力
MBA ENGLISH 経済・会計・財務の知識と英語を身につける
なぜあの人の解決策はいつもうまくいくのか？　小さな力で大きく動かす！システム思考の上手な使い方
プロジェクトを成功させる現場リーダーの技術
SEのためのOracleチューニングハンドブック
続門外不出のOracle現場ワザ
プログラミングでメシが食えるか！？　成功するプログラマーの技術と仕事術
この「聞く技術」で道は開ける　一番いい考えを引き出すノウハウ
我らクレイジー・エンジニア主義
今、松下幸之助ならどうする？　危機・逆境を好機に変える成功法則
マネジメント改革の工程表
Subversion入門
できる人ほど脳内シミュレーションをしている仮説力
アメリカで百戦錬磨の日本人弁護士が教える負けない交渉術
頭がよくなる「仮説力」のススメ
男の本懐　本音を通す生き方
Railsレシピ
DBスペシャリストを目指すSEのための基礎からわかるデータベース構築ガイド　実践から学ぶ、DBスペシャリストの仕事のすべて
データベース新たな選択肢[リレーショナルがすべてじゃない]　New Choice of Database "Relational can't do everything"
バグがないプログラムのつくり方　JavaとEclipseで学ぶTDDテスト駆動開発
Design by Contract: By Example
プロフェッショナルの条件　いかにして成果をあげ、成長するか
スピードハックス　仕事のスピードをいきなり3倍にする技術
「会社学」のすすめ
体系的に学ぶデータベースのしくみ
ソフトウェアテストPRESS Vol.4
[情報処理教科書]テクニカルエンジニア（データベース）2007年度版
72のキーワードから学ぶ実践データベース
マトリックスで考える人は仕事ができる　魔法の思考ツールで集中トレーニング
BPMがビジネスを変える
とことんやれば、必ずできる　創造力が目を覚ます
他者から引き抜かれる社員になれ
NGN時代のネットワークエンジニア入門
プロとしてのデータモデリング入門
１００倍の利益を稼ぎだすビジネス書「多読」のすすめ　レバレッチ・リーディング
おとなの男のルール　男はちょっと硬派がいい
開発の現場 vol. 007
金持ち父さんの起業する前に読む本〜ビッグビジネスで成功するための10のレッスン
知的ストレッチ入門〜すいすい読める　書ける　アイデアが出る
CodeZine傑作選 vol.1
EnginnerMIND vol.2
RailsによるアジャイルWebアプリケーション開発
金持ち父さんの予言　嵐の時代を乗り切るための方舟の造り方
開発の現場 vol. 005

インターフェイスの継承

C#

前回のエントリの引きはとりあえず置いといて，全然別のネタだったりする．
とりあえずネタ元のソースから．*1

using System;

namespace Sample
{
  //継承元IF
  public interface IFoo
  {
    void Foo();
    void FooVar();
  }
  
  //継承先IF
  public interface IVar : IFoo
  {
    void Var();
    //継承元のIFを改めて定義するときはnewキーワードが必要（らしい）
    new void FooVar();
  }
  
  //IVarを継承しているので，Foo, Var, FooVarの定義が必要
  class MainClass : IVar
  {
    public void Foo()
    {
      Console.WriteLine("Foo");
    }
    
    public void Var()
    {
      Console.WriteLine("Var");
    }
    
    public void FooVar()
    {
      Console.WriteLine("FooVar");
    }
    
    public void FooVarFunction(IFoo foo)
    {
      foo.FooVar();
    }
    
    public static void Main()
    {
      MainClass m = new MainClass();
      m.Foo();
      m.Var();
      m.FooVar();
      m.FooVarFunction(m);
    }
  }
}


C++からOOPに入り始めた者としてJavaのInterfaceに触れたときに，(静的型付言語の)振る舞いの抽象化はこの機能で極まったと感じたものであった．*2ところが，最近C#を触っているうちに，InterfaceからInterfaceへの継承ができないかと考えるようになった．で，思いつきで上記のコードを書いてみたらどうやら思ったとおり動くらしい．ちなみに，.Netのバージョンは2.0で，Javaでこんな表記ができるのかどうかは不明だったりする．

上記コードの説明としては，FooVarというメソッドを宣言しているIFooをIVarが継承している．IVarが改めてFooVarメソッドを宣言するときには，newキーワードを付けて宣言する．このIVarを継承するクラスはFooVarを実装する必要があり，IFooに代入してFooVarメソッドを実行することができる．


さて，上記のコードを実現するだけならば，IVarを階してIFooを継承しなくても，MainClassがIFooとIVarの2者を継承するだけですむ．このように，Interfaceが複数継承できる以上，上記のようなInterfaceからInterfaceへの継承がどういう意味を持つのだろうか．
と，問題だけ掲げた時点で今日のエントリは終了したりする．


まだ，我輩にも思いつきの段階なので，後日検討してからアップします．

*1:今回はちゃんとコンパイルして実行してるので，コピペして動くソースである

*2:勿論C++でも純粋仮想関数のみの抽象クラスを多重継承して同じことはできるが，洗練されていたとは言いがたい．(C++のやり方があくまで継承という枠に縛られるように感じるのに対して，Interfaceは振る舞いの保証という側面から関係を見ることができる．