オブジェクト指向入門
紀伊國屋書店


9784875021384
Amazon.co.jp

2006年03月13日
川俣晶の縁側ソフトウェア技術雑記total 3648 count

メイヤー先生の『オブジェクト指向入門』を拾い読みする

Written By: 川俣 晶連絡先

 時間がないので要点だけ書きます。

 手元にある本なので、檜山さんが以下で紹介した箇所だけ読んでみました。

ウィンドウを多重継承で実現 §

(10.4.2) もし多重継承が存在せずこの中(檜山注:複数の親クラス候補)のどれか1つを選ばなければならないとしたら、それは母親と父親の1人だけを選ぶことと等しい。

 ここは、ウィンドウシステムのウィンドウは、ビジュアル、テキスト、ツリーの3つのクラスを多重継承しなければシンプルに表現できないと主張しています。

 でも、この主張は妥当ではないですね。テキスト情報はウィンドウにとって必須の機能ではないし、ウィンドウオブジェクトが持つ必要があるのは通常子ウィンドウのリストであって、ツリーではありません。孫は子に問い合わせれば分かるから。

 しかし、一方的にメイヤー先生の主張が間違いかというと、そうではありません。

 そういう実現方法もありだよね……と考えたとき、そこに別種の合理性があるように感じられます。

 その印象は、次の部分を見たときに、炸裂します。

定数だけのクラスの継承 §

(13.2) 単一継承の環境では、EDITOR_CONSTANTSなどの定数定義のためのクラスは“本当の”親と親権を争うことになってしまうだろう。

 グローバルな定数を定義したクラスを使うには、それを継承しなければならないから、多重継承は必須なんだよ……と言っています。

 この主張は、今時のよくあるオブジェクト指向プログラム言語とは相容れません。要するに、他クラスがpublic宣言した定数を参照することは容易であって、定数参照程度で継承しなければならない理由はないからです。

 そういう意味で、メイヤー先生の主張は強引すぎます。

 が、しかし、理がない訳ではありません。

 というか、凄い合理性をこの例から見出してしまったのです!

 つまりですね。

 この方法論を選択する場合、定数はpublicスコープではなく、protectedスコープに記述されることになります。その結果、あるクラスから参照可能な定数は、そのクラスが継承しているクラスに記述された定数だけになり、その条件に該当しない定数は一切参照することができません。

 これは、ソースコードから無用の複雑度を取り除いたり、誤った記述を事前に排除するために効能があることだと思います。

 たとえば、仮想キーの番号の定数定義クラスと、制御文字の番号の定数定義クラスがあるとします。両者は似ていますが、厳密に同じではありません。

 他クラスのpublic定数を参照するモデルを使う場合、仮想キーを処理するクラスから制御文字の番号定数を参照しても、何らエラーになりませんが、プログラムとしては誤りです。

 しかし、継承によって定数を参照するモデルを使う場合、仮想キー番号クラスだけを継承して仮想キー番号を使うことを明示的に示したクラスからは、制御文字番号クラスのprotected定数は参照することができません。つまり、制御文字の番号定数を参照する誤ったソースコードはコンパイル時にエラーとなり、その時点でバグの存在を検出することができます。

 つまり、継承を1つ書き足すという僅かな手間で、特定の種類のバグの可能性を根絶することができます。しかも、ソースコードの複雑度も低減され、ソースを読む負担も軽くなります。

 おお、なんてラクチン! 私はラクチンが大好きです!!

 ちなみに、これは2003年10月30日に私が書いたプログラムの複雑さとは何か?の以下の不満に対応するものとなります。

(引用始め)

 では、このようなモジュール化プログラミングは実践できるでしょうか。

 C言語を使うと、ある程度実践できます。(時間があれば次に書く……かもしれないコンテンツで具体的なやり方を解説します)

 JavaやC#のような系列の新しい世代のプログラム言語では、たぶん、実践できません。

 それはなぜか。

 モジュールはクラスに相当すると考えた場合、明示的な参照設定ができないからです。これらのプログラム言語は、(大ざっぱに言えば)同じプログラム内のpublicな構成要素に全てアクセスできます。それを制限することはできません。C#の場合、アセンブリを単位にしてアクセスを制限することができますが、制御単位が大きすぎ、かつ、別のアセンブリに単体テストを書き込む場合、アセンブリ内のみにアクセスを制限すると、テストから呼び出せなくなってしまうので、あまり実用的ではありません。

 というわけで、実は万事解決オッケーだぜ!という結論にはならないわけです。

 専門家がどのように考えているか分かりませんが、実はこのへんが個人的な不満点であったりします。

(引用終わり)

本当に頭の良い人の書いた本は、たとえ結論が間違っていても読む価値があるのだ §

 本当に頭の良い人の書いた本は、たとえ結論が間違っていても読む価値があると思っています。

 より具体的に言えば、他人の受け売りではないことを、自分の頭で考えて抜いて、それを他人に理解可能な表現手段で提示するという条件を満たしている本は、そこから良い刺激を得られる可能性が常にあるということです。

 逆に、単に他人の受け売りの「正しい結論」だけが書いてあって、その正しさの理由を示すプロセスが存在しない本は、たとえ結論が正しくても読む価値はありません。というか、そのような本の結論は、実は「正しくない」という可能性の方が高いような気がします。受け売りは情報の劣化を伴うので。

余談 §

 ちなみに、昔、コリン・ウィルソンの本を時々読んでいたのは、そのような理由によります。大学時代、趣味とも勉強とも仕事とも(笑)直接関係ない分厚いハードカバーの本を2冊買っているのですが、その1冊が「ゲーデル・エッシャー・バッハ」で、もう1冊がコリン・ウィルソンの「ミステリーズ」だったりします。「ミステリーズ」の結論を支持する訳ではありませんが、明らかに事実ではない情報が事実として一人歩きするプロセスを理解するための「ミーム」のような概念を把握する下地を作ってくれた本と言えるかもしれません。

Facebook

キーワード【 川俣晶の縁側ソフトウェア技術雑記
【技術雑記】の次のコンテンツ
2006年
03月
17日
なぜインクリメント演算子++は必要なのか? なぜこれを必須の存在と見なすのか?
3days 0 count
total 11380 count
【技術雑記】の前のコンテンツ
2006年
03月
10日
実は昔から持っていたメイヤー先生の『オブジェクト指向入門』
3days 0 count
total 7420 count

このサイト内の関連コンテンツ リスト

2003年
10月
30日
プログラムの複雑さとは何か?
3days 0 count
total 5922 count
2006年
03月
17日
なぜインクリメント演算子++は必要なのか? なぜこれを必須の存在と見なすのか?
3days 0 count
total 11380 count
2013年
12月
11日
川俣晶の縁側過去形 本の虫感想編
コリン・ウィルソン訃報
3days 0 count
total 5857 count


オブジェクト指向入門
紀伊國屋書店


9784875021384
Amazon.co.jp

このコンテンツを書いた川俣 晶へメッセージを送る

[メッセージ送信フォームを利用する]

メッセージ送信フォームを利用することで、川俣 晶に対してメッセージを送ることができます。

この機能は、100%確実に川俣 晶へメッセージを伝達するものではなく、また、確実に川俣 晶よりの返事を得られるものではないことにご注意ください。

このコンテンツへトラックバックするためのURL

http://mag.autumn.org/tb.aspx/20060313160626
サイトの表紙【技術雑記】の表紙【技術雑記】のコンテンツ全リスト 【技術雑記】の入手全リスト 【技術雑記】のRSS1.0形式の情報このサイトの全キーワードリスト 印刷用ページ

管理者: 川俣 晶連絡先

Powered by MagSite2 Version 0.34 (Alpha-Test) Copyright (c) 2004-2018 Pie Dey.Co.,Ltd.