[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1319] Re: b-free:1205について のコメント (1/2)(Re: オブジェクト指向のOSへの適用)
References: <35232BE4.692CEC89@bridgew.edu> <19980402182808A.night@soft.hitachi.co.jp>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
# ふたつめ。
Ryuichi Naitoh wrote:
> > > > 段階別に class 分けし、特化する機能を継承で対応しつつ、応用の利く class の再利用性を維持しました。
> > >
> > > うーん?
> > > これだと、ある特定の機能を果すプログラムを作るときに、完成後は流用でき
> > > る汎用クラスが残ることになりますが、これって本当に実現されていますか?
> > > 抽象的なクラスを作るときに、よほど注意しないと他のプログラムへ流用でき
> > > るクラスを作るのは難しいと思いますが。
> >
> > Night さんは、部品化と再利用を非常に重要視していますが、継承の意義はそれ
> > だけではありませんよ。
> > Java の interface にその特徴が現れています。
> > 継承によって、 る対象への操作を分類できるんです。
> > 「この対象に対するこの操作は、この性質から来ている」
> > と言う感じに述べることができる。
>
> 話がずれているなぁ。
>
> 私は、鈴木さんの書いた
>
> 「応用の利く class の再利用性を維持」
>
> に対して、そういうクラスを作るのは、あらかじめちゃんと考えてないとでき
> ないのでは? ということを書いただけです。再利用性については、私が書い
> たことではなく、鈴木さんが書いたことなんですが。
何を持って、再利用と言ったら良いんでしょうか、、、。
たとえば、window を抽象しましょうか。で、この class を継承すると window
が生成できるとしましょう。そういう事ですか?
この点、(たぶん多重に)継承する class に window という特性を与えて
window として使えるようにすると言うことが、僕が書いた「性質を分類して実
装できる」という話です。
> つまり、あるモノの性質を表現する抽象クラスを多く作って、その抽象クラス
> を組み合わせて新しいクラスを作るということをして、プログラムを作るとい
> うことですか?
Abstract class になるかどうかは時と場合によるでしょうが(abstract である
必要がないときもある)、基本的には色々な性質を持つ object を重ね合わせ
て、その上にその object 独自の部分を載せながら新しい object を構成すると
いうのが、C++の手段だと思います。
> こういう考えを押しすすめると、Flavors でのクラス構成になりそうですね。
> Flavors では、抽象クラスを組み合わせることによって新しいクラスを作る、
> ということがクラス継承の軸になっていますから。
> もっとも Flavors のいうクラス(フレーバ)は、型なんだろうか? うーん。
型 → type → 種類/種別/性質。
と、言葉遊びしてみる。:-)
でも抽象化されていない object は、性質と言うより本当にOOPで働く
object になりますね。
お互いに、message をやり取りするような。
Typed Lanugage の場合、message をお互いに送りあえることを保証するのに、
type を使っているんですね。
さもないと、message を送れない相手に送ってしまった場合に実行時検査しなく
ちゃいけなくなる。
そう言う意味でC++のとった手法というのはOOPで必然の機能ではなく、静
的型検査か動的な message の受信検査かの選択肢の内の一つと言うことになり
ますね。
動的な(実行時の)受信検査をする language(i.e.Smalltalk) だと、すると、
そんなに上記のような抽象と重ね合わせの手法はとらないと言うことかな?
> で、何でこういうことをするかというと、差分プログラムのためです。
> 結局、クラスの再利用のために行なっているわけですね。
ということで、型検査の為も大きいですね。:-)
> しかし、多重継承がない Smalltalk のようなオブジェクg指向言語もありま
> す。そういう言語では、鈴木さんの書いたことをするのは難しいでしょう。
これも、型検査が大きいと思います。
型検査が必要ない場合、もっと自由に class 階層を決められるでしょうから、
より単一継承でも思ったような処理が出きるのでしょう。
> > 二つあります。
> > 一つは、隠してしまうこと。C++ なら private や protected で継承できます。
> > 一つは、置換してしまうこと。仮装関数とは常に新しい物一つしか存在しない関
> > 数です。
>
> Private や protected で継承しても、親のクラスの要素は残ってしまいます
> よね? たとえば、親クラスのメソッドの中で、その引きつぎたくない機能を
> 使っていうことはできてしまう。
??
でも、その次の class には行きませんよね。
Function override というのもありますよ。
これも、非公開継承と似てますが。
> 置換するということは、親の性質を別の物にするということで、継承しないと
> いうのとは別の話だと思います。
いえいえ置換というのは性質を別の物にするわけではなく、より適切な物にする
と云うものです。
たとえば、ある class で表示をするための method を作った場合、それはその
class 特有ですから派生させたときに置き換えますねぇ。
そういう事です。
> 考えていたのは、複数のクラスを多重継承したときに、自分にとって都合のい
> い機能だけを親からもらうということです。で、そのためには、不要な機能は
> もらわないようにする必要があると。
> あまり本題とヘ関係ないですが。
え?でも、この意味だと、必要な機能のみを引き継ぐというのは継承と少し意味
合いが違いますね。
継承すると言うことは親の性質を引き継ぐという事で親の性質の一部分のみを引
く次ぐ場合は、継承図が違います。
たとえば、
class A: public B {};
で、B の一部分の性質みのを A が持つと言いたいなら、
class B: public apartofB {};
class A: public apartofB {};
ですね。
> たとえば、事例でいうと西日本鉄道の「列車ダイヤ作成システム」をオブジェ
> クト指向技術を使って作ったときに問題になったみたいですね。
> このニきは、OMT によるモデルから C++ へのコードへ移すときに、表現の実
> 現方法が違うので、クラス構造から作り直したそうです。
>
> # 要は、言語にモデルを合わせたわけね。
へえ、もう少し聞きたいですが、どっかに参照できるところはあります?
http とか、、、。
> 私見ですが、OS を作りたいと思い、実際に OS をどう作るのかを理解してい
> るようなプログラマは、オブジェクト指向設計のような設計技法にはあまり興
> 味がないような気がします。
> たとえば、Linux ML などを読んでも、新しいプログラムを作るときにオブジェ
> クト指向設計技法を使おうとかいう話を見かけたことはありません。
うむむ。誰も vision が浮かばないのかな。
> > > OS で、オブジェクト指向と言った場合、普通は設計技法としてオブジェクト
> > > 指向を使ったことを言うのではなく、アーキテクチャとしてオブジェクト指向
> > > 的になることをセうと思います。
> >
> > でしょうね。
> > だから「新しい!」
>
> うーん、OS でオブジェクト指向設計を使っていないのは、新しいからではな
> く、単に向いていないだけでは?
その辺を、Next Generation の方で、話し合いましょう!
> > まあ、実際、data の flow をみたら、OOになら無いのは当たり前ですが。
> > data のあり方(性質)を見るとOOになるかな。
>
> ここで、OOと書いているのは、具体的には何を思い受かべているんでしょう
> か? それが分からないことには、何も言えないのですが。
> えーと、私がデータフローによる設計方法ニ書いたのは、正確にはデマルコの
> データフローダイアグラムのことです。鈴木さんの言うOOというのは、どう
> いうものなんでしょう?
継承図です。個人的には DAG を使って書いたおなじみの物を想定しました。
> 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.