[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 975] Re: TAD 実装方法?
すごく久しぶりの、Aki です。
ちょっとばかり、実家に帰っていました。
で、一ヶ月ぶりにまた、今の生活に戻っています。
いやあ、以前は、(相変わらずの)無責任さで議論を引っかき回していたのですが、B−
freeにたいする基本的な方針を理解していなかったという結論に達してしまい、あま
り得るものがなかった気も、、、。(苦笑)
「OSを作るときは、トップダウンで、最も重要な使用目的から決めて細部に行く」
と思っていたのですが、
「使用目的は非常に広範囲であるとし特定せず、出来る限り可能性の探求を利用者に任
せる」
という方針だと理解しました。
#今度は良いんですよね?
そういう事で、これからは少し、一歩下がって、議論に干渉しようと思います。
そういう事でよろしく。
Ryuichi Naitoh wrote:
> > オブジェクト指向の良さはここなんです。
> > XXをYYするという程度のことならそのまま書けるんです。
> > だから直感的に書けること・すべてに統一されたIFが提供できること。
>
> # 何か飯島さんの文と makoto さんのコメントが噛み合ってないような。。。
>
> このオブジェクト指向の良さというのは、どういうものなんでしょうか?
> 「XXをYYするという」という程度ならば、オブジェクト指向でなくても直
> 感的に書けるような気がします(実際、ITRON のシステムコールの命名方法は
> そうなってます)。
>
> オブジェクト指向を使った場合、非オブジェクト指向の場合と比べてどの辺が
> よいのでしょうか?
>
> p----------------------------------------------------------------------q
> | FROM R.Night |
> | E-mail: |
> | rnaitoh@st.rim.or.jp |
> b----------------------------------------------------------------------d
ということですが、個人的な見解として、
1 部品化
2 より高次の概念の導入
があげられます。
そういう事で下記。
「Object Oriented Programming の安易な (^^; 解説」
プログラムを行うとき、まず細部の構造を部品化しますね。構造をプログラムの形に抽出
するといっても良い。これは、ループを切ったり関数を作るみたく、共通点を探し出すわ
けです。で、C言語の関数の場合は、これ以上の Grouping とでも呼ぶようなものは、
Source File とそれに伴う Linkage 位しかないのですが、Object Oriented の場合、さ
らに処理されるデータに共通項を見いだします。格好良くいえば、関数の呼び出し木をデ
ータを軸に具現化するといっても良い。 でも簡単にいうと次の通りです。
「この関数の呼び出し木Aでは一連のデータ群aを扱うので、データ群aに属する関数
としよう」
という具合です。 関数を処理対象によって Grouping します。
そうすると、「関数と処理されるデータ」という考え方から「ある種のデータと付随する
操作関数」という視点に変わります。 そうなると、「抽出されたデータに対しての操作
はすべて付随関数を通して行う。それ以外からは操作禁止」という考えがでてきます。そ
の最大の利点は debug で、あるデータに問題があった場合、その付随関数に問題がある
と言い切れるわけです。データの異常から調べなければいけない関数を特定できる。これ
が、capsuling という奴で一つの部品を作ったことになります。
この部品を扱うための入力面となる部分は「付属関数」な訳ですから、付属関数の
prototype さえ変えない限り、部品の内部変化の影響を外部に漏らさずにすみます。ねじ
はサイズやピッチなどの規格に適合してさえいれば金だろうと鋼だろうと一応は使うこと
が出来るのと同じです。誰がどうやって何で作ったかなどの情報は隠蔽することが出来る
のです。
内部の隠蔽はより高度な概念を導入可能にします。たとえば、10種類のデータには十種
類の出力の方法があるとしましょう。しかし、細かい出力の手順は内部に隠蔽しておき、
どのデータでも Interface <output> を実装することで「良し」という事にします。関数
だけでこれが出来ないのは、データ中心の考え方がないために、関数名の衝突が起こるか
らです。C や Java だと、Structure Mamber の要領で、
data.output();
などとかけます。これは、プログラマーがこのデータ構造体に ouput 司令を送ると、こ
の構造体が自分で判断して適切な(自分に見合った)出力処理を行うとみることが出来ま
す(Object 指向)。
Programmer --- ( Message:output ) ---> data
もちろん、別の構造体の内部処理(付属関数内)でこの司令を送ることもできるので、次
のようにもかけます。
{ data' の内部
data.output();
}
data' --- ( Message:output ) ---> data
複数の構造体同士がお互いに協調を取り合って物事を進めていくあたりが、OOPと呼ばれ
る所以です。
さらに、いくつかの構造体が同じ入力面(同一名の付属関数)を持つ場合、この共通部分
の抽出も行いたいところです。上記 output() がその良い例です。もしかしたら ouput()
は10種のデータのうち5つが全く同じ内容 (default) の関数かもしれません。特にそ
んなときは、同じ内容の関数を構造体ごとに複写していくのは冗長です。そこで、通常
OOP では、capsuling した部品から property の継承を行うことが出来ます。それは、よ
り高次の概念を持つ構造体「出力可能データ」とでもいうものを想定して、そこから、上
記の data, data' を導き出すことです。
outputable <=== (inherited) === data
outputable <=== (inherited) === data'
data, data' は outputable の「一種」と考えても良いし、「特化したもの」や「改良
版」とも考えることが出来ます。依然、data, data' は outputable の subset ですが、
この場合も隠蔽によって、outputable の Interface の必要な部分のみを継承し、不要な
部分を切り落としたり、不十分な部分を改良したり出来ることに注意します。
こうして高次の概念を導入してくると、これらの概念上の(データを離れた)構造体は、
入力面にも影響を及ぼすことがわかります。次のような入力面は、この継承を持ってしな
ければ大変面倒なことになるでしょう。
window.display ( outputable 構造体の一種なら何でも )
これは、window にある種のデータを表示することを前提にしたwindow という高次概念の
Interfece です。display() は outputable 構造体の一種であるならば、output() を内
部に持っているだろうと仮定し、たぶん、window.display() の内部で
outputable::output() を呼び出すでしょう。
部品の名前と Interface の公開と、至極一般的な使い方(関数呼び出しの方法など)さ
え知っていれば、一応自由に使い回すことが出来るのは、OOP の利点といえるでしょう。
TAD を OOP で画こうというのも、ここが大きいはずです。 window や panel や databox
なども、部品の候補になります。Thread もそうです。Screen や FD や Timer などの実
devices ももちろん候補になります。必要なことは、構造体の種類を分類できることと、
入力面を決定できることです。
極端な話、今までの関数主導型の Programming だと、誰か「神」と呼べる Programmer
の存在がいて、全体を管理・統治しなければいけませんでした。なぜなら、関数の
Interface は関数の改良に伴い変わりやすく、それを呼び出しているすべての部分に影響
が及ぶからです。だから、全体を把握している人間の存在が必要だったわけです。しか
し、データを軸に考えた「データへの Interface」はより安定していて、しかも、OOP は
改良における「データに対する操作の拡張」を部品を組み合わせて新しい部品を作った
り、古い部品を新しい部品の一部として再利用するという手法で可能にします。操作を拡
張したところで、古い部品を使っている部分はそのまま使い続ければいいのです。そのた
め、もはや「神」と呼べる権力者の必要性はかなり低減したと思われます。
以上。
注釈:
今回、OOP のもう一つの大きな流れである「継承に対局する Template」は割愛しまし
た。念のため。
でも、STL (という呼び名は古いか ^_^;)をみる限り、Templateなしに B-free はクラ
ス化しない方が良い気がする。
追伸。
Netscape Communicator の次期版は、Source code を Open にするらしいですね。
そういえば、Java VM も一気に変化する可能性があることも示唆されてますね最近。
こりゃぁ、変化の時期かな。