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

[b-free: 1242] Re: b-free: 1205 についてのコメント (2/2)




隆一です。


From: makotan@a2.mbn.or.jp
Subject: [b-free: 1240] Re: b-free: 1205   についてのコメント (2/2)
Date: Thu, 2 Apr 1998 23:08:14 +0900 (JST)

> 
...[snip]...
> > 
> > 提案するのはいいことだし、どんどんして欲しいと思うんですが、それを実現
> > することに対して、あまりに naive な意見が多かったのではないかと思いま
> > す。
> 
> これって結局はオブジェクト指向に対して詳しい人がいない(もしくは話に参加
> していない)ということなんですよね。

うーん、makotan さんはオブジェクト指向に詳しくないのですか?

もっとも、詳しいことと、実現性を考えることとは別のことなので、オブジェ
クト指向に詳しいからといって B-Free でどういうように実現すればいいかを
考えないと、提案したものの実現できないということになりそうです。



> > > 前にも書いたのですが...オブジェクト指向は十分に利点があります。
> > > だからこ最新技術と言われている技術の多くに使われているのだと思います。
> > 
> > えーと、確かにオブジェクト指向が十分に利点があるというのは、何回も書か
> > れていますね。でも、これって全然オブジェクト指向が優れているという理由
> > になりません。最新技術の多くに使われているというならば、ちゃんと具体例
> > を出さないと。たとえば、OS だったら、これこれこういう OS に使われてい
> > るとか。
> 
> BeOSはオブジェクト指向OSとして有名ですよ。
> すでにIntelプラットフォームでリリースされています。

BeOS については、オブジェクト指向 OS というより、開発環境としてオブジェ
クト指向がはじめから提供されている、ということではないでしょうか?
(そういう点では NeXT もそうでしたね。もっとも NeXT 自体は成功したとは
言い難いですが)

OS のアーキテクチャとしては、BeOS は、マイクロカーネル方式をとっており、
一番下にマイクロカーネルがあり、その上にサーバが載っている形式になって
います。API はサーバの上の層としてインプリメントされています。
Hurd などと同じアーキテクチャでしょう。

どこまでが OS で、そこからがそうでないかは一概には言えないと思いますが、
クラスライブラリが揃っているという点では、BeOS はオブジェクト指向技術
を使っていると思います。しかし、BeOS でのオブジェクト指向は、たとえば、
Chorus や Spring などのオブジェクト指向 OS とは意味が違うのではないで
しょうか?

でもまぁ、これらのことは細かいことですね。
結局、私の言いたいことは、理由も言わずにこれを使えとか言わないで、とい
うことだけなんです。どんなに利点があったとしても、それを説明していただ
かないと使うのに二の足を踏んでしまいます。BeOS でオブジェクト指向を使っ
ていることによりどういう利点があり、そしてそれは B-free OS にも使える
ものなんでしょうか?



> > 設計技法については、オブジェクト指向とついたものだけではなく、構造化設
> > 計とか複合化設計とか、データ中心設計とかあったわけですが、それらと比べ
> > てオブジェクト指向はどういう風に優れているのでしょうか?
> 
> 構造化設計と複合設計ってほとんど同じものだと思いますよ。
> それぞれが協調しあえるものです。
> どれか一つを使えばソフトウェア開発の全ての問題が解決するのではありません。

むむ。ということは、オブジェクト指向開発技法と構造化設計技法の両方を使
えということですか?
両方の技法は混合できるものなんでしょうか?

事例を調べても、そういう話はあまり見ないですね。

# だから、失敗しているソフトウェア開発が多いのか :-)



> ただ、データ中心設計はOS開発には向いていないと思います。
> これは構造化”分析”を実際の業務で使っている人と話していたときの話ですが、
> 
> ここからNiftyのとあるフォーラムからの引用です。


> >>最近のこのフォーラムのOOとデータ中心などの分析手法の話に少しだけ参加し
> >>ながら思っていたことですが、オブジェクト指向分析の利点は設計情報をプロ
> >>グラム化して使い回せる事とコンポーネント化することでプログラムの再利用
> >>性が比較的簡単あがることじゃないかな?っておもいました。
> >
> >私もそのように考えています。組立・保守フェーズでのオブジェクト指向
> >の威力には目を見張るものがあります。そして、制御システムなどの限定
> >された対象の分析手法としても有効であろう、とも考えます。けれども、
> >これを業務支援システムの分析・設計の枠組みとして拡張する試みがうま

えーと、この文のどの個所がデータ中心設計は OS 開発に向いていないという
ことを示唆しているのでしょうか?
オブジェクト指向が再利用、部品化に向いているというのは、私もそう思って
います(というのは、[b-free 1208] で書いていますね)。

# この文の続きが気になるのですが、「業務支援システムの分析・設計の枠組
# としても拡張する試みがうまくいっていないのは云々、」と続くのでしょう
# か? 


> OS開発という非常に特殊な開発においてどの技法”だけ”が優れているというよ
> うな考え方をするのではなくて、いろんな技法の利点を上手に組み合わせてそれ
> らを活用できればいいなと思います。

私は、オブジェクト指向開発は OS には向いていないのではないか、というこ
とを書いただけです。OS の開発に向いている特定の技法があるということは
考えていません。

むしろ、ソフトウェア開発の技法の優劣については重要な問題ではなく、ボラ
ンティアベースのプロジェクトでどうやって、開発していけばいいのかという
プロジェクト管理の方が問題だと思っています(というか、スケジュール問題
と書いたのもそこが問題だからです)。

にしても、

> OS開発という非常に特殊な開発においてどの技法”だけ”が優れているというよ
> うな考え方をするのではなくて、いろんな技法の利点を上手に組み合わせてそれ
> らを活用できればいいなと思います。

というのは、ずいぶん玉虫色な書きかたですね。

いろいろな技法の利点を上手に組み合わせる、というのはたしかに理にかなっ
ているように思えますが、実際には相当経験をつまないと無理でしょう。
特に、makotan さんが「非常に特殊」というほどの OS の開発において、複数
のソフトウェア開発技法を経験することは難しいのではないでしょうか?


> > 今、オブジェクト指向設計技法を提唱している人の中には、旧来の設計技法の
> > 提唱者だった人もいるのですが、なぜオブジェクト指向設計へ移ったのでしょ
> > うか? もし、旧来の設計技術に問題があって、オブジェクト指向設計に移っ
> > たならば、同じようにオブジェクト指向設計にも問題があって、更に別の設計
> > 技法に移ることがあると思いませんか?
> 
> 移った人は複数の開発手法を知っていてそれを自由に使い分けることができるは
> ずです。

うーん、どうも「複数の開発手法を組み合わせる/使い分ける」という考えが
先にあるみたいですね。

移った人というのは、プログラム開発をしているわけではなく、プログラム開
発のための技法を研究している人です(だから、提唱している人と書いた)。
たしかに、自分で開発技法を提唱するくらいですから、プログラム開発技法に
ついては詳しいと思います。しかし、実際のソフトウェア開発において、複数
のソフトウェア開発技法を使い分けるということとは別の話です。


> 現在のオブジェクト指向技術にはすでに問題があることは確認されているます。

ふむ、技術的な興味から質問するのですが、オブジェクト指向技術にはどうい
う問題が確認されているのでしょうか?


> だからといって次の技術がでてくるのを待つのは不自然です。
> それは、船も車も飛行機も使われているのにあえて次の乗り物を待つようなもの
> です。

このメイルの前の文でも書きましたが、私の言いたいことは、オブジェクト指
向はバラ色の技術ではなく欠点もあるのではないか、ということです。
プログラム開発技法についてオブジェクト指向より優れたものができるだろう
からそれを待とう、ということを書いているのではありません。

プログラムする人をどうやって増やすかという問題を無視してオブジェクト指
向技術を使おうというのは、言ってしまえば、どこに行くかも決めないで、使
える乗り物があるから乗ってしまえ、というようなものです。そういう点では、
オブジェクト指向以外の開発技術を使おうというのも同様です。

繰り返しますが、一番の問題はどういう技法を使おうということではなく、
どうやってプロジェクトを運営して行くべきか、ということです。
プロジェクト運営という点では、ボランティアベースで OS 開発を行うという
のは、誰もどうやっていくのがいいか方法を知らない分野のものです。



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