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

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



References: <35217B4F.43E9561C@bridgew.edu> <19980401130915I.night@soft.hitachi.co.jp>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

読んでいて思うのは、Object Oriented への見方の違いです。
そう言った見方が出来るんだなぁと、感心しました。



Ryuichi Naitoh wrote:

> > 後者を選択するなら、とりあえず、完成はぐっと近くなるでしょうね。
> > # 逆に前者を選択したら、大変でしょうねぇ。
> > OO云々の話は「すぎたこと」として、OOを期待している人達に対しては「また今度ね。」という話
> > になるだけです。
> >
> > その辺の方針をはっきりしておくことが大切なんだと思います。
>
> 私が、「ぢゃオブジェクト指向はやんぴね。今後はオブジェクト指向のことは
> 言わないでね」とは言えるわけですが、そういうトップダウンなことはやりた
> くないです。
> だから、オブジェクト指向で行こうと行っている人のメイルにコメントして、
> オブジェクト指向で作るときの問題点を上げてオブジェクト指向に行くことに
> 反対しているわけです。

すごく、よく分かります。:-)で、近い内に、はっきりすると良いですね。


> > 僕がOOのよい点と思うのは、outline からどんどん細部に詰めていけると言うところです。
> > Design が top-down なんですよ。
>
> うーむ、逆では?

ここです。ここが、僕を驚かせた見方の違いですよ。(^_^;

> むしろ、オブジェクト指向というのはボトムアップの考え方にもとづいて考え
> られたと思います。
> つまり、プログラムを作成するときに、既存クラスの再利用を行うことによっ
> て生産性を向上させるという考えです。

これは、C++ で果たせなかった夢でしたね。code の部品化というのは、長年の programmer の夢であっかと
聞きます。
# 最近は、STL を見ても、少し進歩が見られるようですが。


> これは、昔の Smalltalk を見れば分かりますよね?
> もともと、Smalltalk を使う人というのはプログラムの経験がほとんどないと
> いうことを想定していました。そういう人がプログラムを簡単に組めるように
> するために、オブジェクト指向という既存のソフトウェアの再利用を簡単に行
> えるような仕組みを考えたわけです。また、その再利用のために、クラスブラ
> ウザのようなツールも作られたわけです。

Smalltalk は当にその通りですね。

> 問題は、トップダウンの場合、プログラムの再利用性が落ちてしまうというこ
> とです。詳細化の段階で機能を特化していってしまうので、他の用途へ使うこ
> とが難しくなってしまうのです。これだと、新たにプログラムを作るたびに、
> また一から作る必要があるので、同じようなプログラムを作ったことがあって
> も、手間が全然減らないことになります。

ここをOOは、克服しようとしたのだと思います。

汎化は template で。
特化は inheritance で。

段階別に class 分けし、特化する機能を継承で対応しつつ、応用の利く class の再利用性を維持しました。



> ただ、最近(でもないか)出てきているオブジェクト指向「設計」は、全体像か
> ら考えて詳細化へと向っているので、トップダウン的な考えになります。ただ、
> オブジェクト指向設計の考えの中心はトップダウン的に設計する、というもの
> ではなくオブジェクトというモノで設計していくところです。むしろモデル化
> の技術と言った方がいいかもしれません。

model をつくり、その内部を構成していく。僕が top-down というのもこの点です。部品がまずあって組み立
てていくというのもOOPですが、全く部品のないところから部品の設計をしていくのもまたOOPですね。

前者が、おもに、App の構成時に威力を発揮する(なぜなら、App はOSの部品を組み合わせて作ると楽だか
ら)のに対し、OS自体の構成や非常に大きな project を成そうと言うときは、後者が威力を発揮します。

> つまり、処理としての抽象化ではなく、オブジェクトというデータ + 処理と
> いう単位で設計して方法論です。とはいえ、オブジェクト指向設計法は、多く
> の人がそれぞれ違った方法論を提唱していて、どんどん変わって(改良されて?)
> いくので説明するのは難しいです。

発展途中ですね。ある意味、哲学入ってます(笑)。

> B-Free OS の設計については、中心核、周辺核という抽象的な構造をまず考え
> て、各モジュールの中身を具体的に考えていくという方法をとっています。む
> しろ設計方法としては、トップダウンになりますよね?

ここで直面している問題は、中身を決めるのに、何処から決めていったらいいかという事ですよね。利用者に
近い方から詰めていくのか、中心核の方から詰めていくのか。僕は、前者を top-down。後者を bottom-up と
言いたいなぁ。

# すこし、意味合いが違うけど。

> 今は周辺核の詳細を詰めている段階というわけです。問題は、周辺核がどのよ
> うな API を提供するかで、BTRON1 で行こうというのは決まっていますが、実
> 際に具体的な引数などを決めるところで、つまづいているというところです。

決まっているのなら、OOは遠いですね。BTRON2で行こうと言うなら近いですが。


> OS の場合、ボトムアップ的な設計方法というのは、難しいと思います。Linux
> の場合、最初 CPU の機能を確認するようなプログラムを作って、そこから OS
> に発展していったそうですから、ボトムアップ的な設計方法で作ったと言えな
> くもないです。

そうなんですか!>linux

# いろんな事を知るなぁ。>この ML


> > OOというのは、module より一つ level の高い抽象化なんです。
> > 全体を大きな固まりでとらえて、その間の関係を調べて、実装で達成しなければいけない goal を見つ
> > けだしていく。
>
> こういう考えかたこそ、オブジェクト指向では「ない」、それ以前の設計法で
> さんざん唱えられてきたものです。

追加しましょう。その固まりの軸になるのは、「処理対象」です。


> なぜか最近書店で昔からの設計法に関する本が減ってきているみたいで、設計
> 法といえば、オブジェクト指向関係ばかりになっているように思います。
> そのせいかトップダウン設計法についてもオブジェクト指向設計から出てきた
> ものと勘違いしている人も出てきているかもしれません。しかし、抽象から具
> 象へと進んでいくトップダウン設計法は、むしろプログラムの設計方法として
> は、一番古いもののひとつです(もう 20 年くらいたっているんじゃないかな?)。

うーむ。僕は、同じ「抽象から具象」でもその課程に置ける視点の位置が違うのだと信じているのですが。

>
>
> <つづく>
>
> 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

  <res つづく>

-Aki.