[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1238] Re: b-free:1205について のコメント (1/2)(Re: オブジェクト指向のOSへの適用)



References: <3521D114.5F9A4254@bridgew.edu> <19980401170830U.night@soft.hitachi.co.jp>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

どんどん話は先に進んできているようですが、私はゆっくり歩いていこう(にや
り)。

# こらこら、schedule の話は何処へ行った。(^^;;;

Ryuichi Naitoh wrote:

> オブジェクト指向設計とオブジェクト指向言語をごっちゃにしているからでは?
> もともと、オブジェクト指向というとオブジェクト指向言語のことを指してい
> たと思います。

うーむ。そんなに離れた物なのかなぁ???
僕にはよく分からない。

 
> C++ という、クラスライブラリについては不十分な言語を例に上げるのはアレ
> では?  どうも C 言語と比べて C++ は宴Cブラリ化というのを考えていない
> ように思えます。どうも、小手先の便利さに引きずられて機能強化をしている
> 感じです。

これは、C++ の設計者にかなり失礼ですね。(^_^;;;
僕は、Java よりずっと orthogonalな言語だと思いますがね。
表現力もあるし、機能を追加するときも十分な試行錯誤と policy みたいな物の
上になり立っていると信じています。


# ただ、例外処理用の code だけは未だに
# 「美しくない」と思ってしまうのですが(暴)。



> > > 問題は、トップダウンの場合、プログラムの再利用性が落ちてしまうというこ
> > > とです。詳細化の段階で機能を特化していってしまうので、他の用途へ使うこ
> > > とが難しくなってしまうのです。こ黷セと、新たにプログラムを作るたびに、
> > > また一から作る必要があるので、同じようなプログラムを作ったことがあって
> > > も、手間が全然減らないことになります。
> >
> > ここをOOは、克服しようとしたのだと思います。
> >
> > 汎化は template で。
> > 特化は inheritance で。
> 
> えーと、template はオブジェクト指向ではなく、別の概念だと思います。
> たとえば、ADA (古い方)にも同じ機能はありました。ADA がオブジェクト指向
> かどうかは意見が分かれるかもしれませんが、template についてはオブジェ
> クト指向の機能には含まれないでしょう。

template によって、algorithm を object から分離できたというのは STL を見
れば明らかですね。
template はOOを支援します。

 
> > 段階別に class 分けし、特化する機能を継承で対応しつつ、応用の利く class の再利用性を維持しました。
> 
> うーん?
> これだと、ある特定の機能を果すプログラムを作るときに、完成後は流用でき
> る汎用クラスが残ることになりますが、これって本当に実現されていますか?
> 抽象的なクラスを作るときに、よほど注意しないと他のプログラムへ流用でき
> るクラスを作るのは難しいと思いますが。

Night さんは、部品化と再利用を非常に重要視していますが、継承の意義はそれ
だけではありませんよ。
Java の interface にその特徴が現れています。
継承によって、ある対象への操作を分類できるんです。
「この対象に対するこの操作は、この性質から来ている」
と言う感じに述べることができる。

「この性質」を分類すると言うことは即ち、抽象 class を作るという意味もあ
る。
すると、Object とは、性質を抽出した物と言うことができる。
だから、class は type なんです。

対象(の外観)を分析するときに、対象の持っている性質を分類することから始
めるのは基本です。その性質をよりどころにして、code を書きます。すると、
その対象を処理するときに、性質を軸に考えるので、ずっとすっきりとした
program を書くことが出来ます。

その辺良いですか?

> 余談:
> 機能を特化しトいくならば、親クラスの機能のうち不必要なものが出てくると
> 思います。明示的に機能を継承「しない」という指定ができる言語ってどこか
> にないんでしょうか? 別に使わなければいいんですけどね。

二つあります。
一つは、隠してしまうこと。C++ なら private や protected で継承できます。
一つは、置換してしまうこと。仮装関数とは常に新しい物一つしか存在しない関
数です。

 
> データフロ[ダイアグラムにしてもオブジェクト指向設計にしても、モデルか
> ら実際のコードに落とすということについては、あまり助けにならないような
> 気がします。人間の技量にかかわる部分が大きいので。モデルからの具体化の
> 部分を何とかしないとあまり労力の低減にはならないですね。

それが変化してきたから、最近OO設計がもてはやされているのではないのかな
ぁ。

OO設計では具現化の仕事が楽になった変わりに、model を作る仕事がより正確
さを要求されるようになったんではないでしょうか。

だって、具現化って言ったって、、、。

interface は、object 間のやり取りで決まってしまうし。
内部の context は、「何処に属しているか」で決まってきてしまうし。
すると、method は、自然に決まってくると思うなぁ。

# いままで、自然に決まってこなかった経験はない。

 
> 結局、プログラミング能力の高いプログラマに頼らざるを得ないという。。。

これは、何処へ行ってもそうです。
「不動の定理」と考えて良いでしょう。^_^;;;
後、付け加えるとすれば「能力の高く比較的暇な programmer」でしょうね。
なぜなら B-free は趣味の範疇を越えることが出来ませんから。

まあ、僕は programming 能力としてはアマですが、それでも、まとまった時間
があれば手伝いたいとは思っているんですけどねぇ。

この夏12単位とって秋学期に12単位とると、卒業まで残り少なくなって、
homework/exam に追われることが無くなる気がするんだけど、、、。ホンとそう
なると良いなぁ(弱気)。でも、何かにつけて B-free と結びつけて行動するよ
うには考えているんですけどねぇ。

# と、私事を書いてしまう(苦笑)。


 
> OS で、オブジェクト指向と言った場合、普通は設計技法としてオブジェクト
> 指向を使ったことを言うのではなく、アーキテクチャとしてオブジェクト指向
> 的になることを言うと思います。

でしょうね。
だから「新しい!」

> これくらいならば、オブジェクト指向設計を使ってもあまり効果はないでしょ
> う。それに、OS の場合、ソースとしての量は本体よりもデバイスドライバの
> 方が多くなってしまうと思います。

Device Driver とかも、class 化して、動的に生成/登録/削除とかできると楽
しいんですが。:-P

 
> 使用者側というのを API と考えると、B-Free では、API を BTRON1 のものを
> 使うことにしていますから、トップダウンで設計していることになりまキね。



 
> > > 今は周辺核の詳細を詰めている段階というわけです。問題は、周辺核がどのよ
> > > うな API を提供するかで、BTRON1 で行こうというのは決まっていますが、実
> > > 際に具体的な引数などを決めるところで、つまづいているというところです。
> >
> > 決まっているのなら、OOは遠いですね。BTRON2で行こうと言うなら近いですが。
> 
> うーん?
> 今さら、そういうことを言われても。。。
> BTRON2 については、新規性というのはありますが、まだまだ研究中のものだ
> と判断して、BTRON1 にしました。結構、BTRON1 ならば資料があったし。
> (というより BTRON2 の資料が少なすぎる。実質 1 冊しかないんだから)

何せ、ずいぶん昔だったし。(苦笑)
# でも、今でもあんまり昔と変わらないか。

> BTRON2 については、坂村研(というより、越塚先生か?)で研究を続けている
> そうなので期待しましょう。多分、BTRON 4 として出てくるんでしょう。

そうですね。

 
> たしか、history メモがあって、1991 年までの Linux の発展過程を Linus
> さんが書いています。このとき、i386 の機能を学ぶときに CPU のタスク機能
> を使ったプログラムを書いたのがはじまりだったと思います。
> (Linus さんが CPU の勉強をしたときの副産物が Linux だったわけですね)

能力の高い programmer というのは、時々すごい事を副産物でやってしまう物で
すね。^o^!


 
> > > > OOというのは、module より一つ level の高い抽象化なんです。
> > > > 全体を大きな固まりでとらえて、その間の関係を調べて、実装で達成しなければいけな「 goal を見つ
> > > > けだしていく。
> > >
> > > こういう考えかたこそ、オブジェクト指向では「ない」、それ以前の設計法で
> > > さんざん唱えられてきたものです。
> >
> > 追加しましょう。その固まりの軸になるのは、「処理対象」です。
> 
> うん?
> 「処理対象」を中心として考えるということは、データフローによる設計方法
> のことを重要視しているわけですか?
> 
> # とボケてみる :-)

Data flow か。
そういえば、全然違う話だけど、Dataflow Machine について research して論
文を書いたけど、最後までまとまらなかったなぁ。また、今度書き直さなきゃ。

# と、話をそらせてみる。:-P

まあ、実際、data の flow をみたら、OOになら無いのは当たり前ですが。
data のあり方(性質)を見るとOOになるかな。


> > うーむ。僕は、同じ「抽象から具象」でもその課程に置ける視点の位置が違うのだと信じているのですが。
> >
> 
> 視点の位置は違うかもしれません。しかし、違うか轤ニいって開発効率が上が
> るかというと、その辺は疑問です。
> 抽象的なモデルから具体的にソースプログラムまで落とす方法は、あまり進歩
> していないように思います。

そうですかぁ???
そんなに、OOって、ちゃっちい物でしたっけぇ?
^^;

> 
> p----------------------------------------------------------------------q
> | FROM R.Night                                                         |
> | E-mail:                                                              |
> |         rnaitoh@st.rim.or.jp                                         |
> | Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
> b----------------------------------------------------------------------d


-Aki.