約 5,571,160 件
https://w.atwiki.jp/imops-forth/pages/32.html
Mops言語のオブジェクトシステムにはどんな効果があるのか Forthのオブジェクト指向拡張は数多くある。実は、forthで言語の仕様を変更するのは容易なのである。初心者から一歩踏み出したあたりで、言語実装がforthプログラミングの課題となってくる、とさえいえるほどである。結局は、それでforthにおけるどのような問題が解かれるのかにかかってくる。 Mops言語のオブジェクト指向はNEONモデルといわれる構文を基としている。これは、forthのオブジェクト指向拡張としては最も早期のもののひとつである。実際には現時点でのMopsのオブジェクト指向特性は起源からもうかなり離れてしまっている。とはいえ極めて古い時代の設計が基礎となっていることは否定できない。ところが、偶然ではあろうが、驚くべきことに、比較的近年になって初めて注目された新しい着眼点とみなされている事柄についても、既に簡明な解答が与えられているように見える場合がある。(もっとも、forth系では、このような時間軸のねじれはよくあることだが。) というわけで、ある程度の期間Mopsのオブジェクトシステムの中でコードを書き、さらに、それを実装してみた経験から、このシステムが見せるいくつかの側面について、実装方法も含めて説明し、解明を試みることにしたい。Mopsのシステムはそれほど錯雑したものではないが、その効果は簡単には説明できないほど奥深いのである。これは、分析的個別問題解決指向が強烈なforthがその背景にあることも関連していると思われるが、その話はここでは触れない。 形式論理位階によるオブジェクト指向分類の試み Mopsのオブジェクト指向は、動的プログラミングを求めるということを主としていないように思われる。つまり、コンパイル時に行うことを実行時まで延期するという手段によって、メッセージ伝送という局所的な部分で"柔軟性"を得ることには、可能ではあるが、あまり腐心していない。というのも、それだけなら素のforthで十分に事足りるからである。つまり、xtを保存して入れ替えながら実行すれば良いのである。実際、xtをvTableに整理して特定のデータ構造と結びつけるだけで、"動的な"オブジェクト指向機能を導入できるのである。その程度ならば、アルゴリズムとデータ構造に関する入門レベルで簡単に実現できる。Forthの強みである。生のままのForthでできることを主たる利点としてオブジェクト指向システムを導入しようとするのは、無駄であるかナンセンスである。 クラスとそのメソッドを定義するというところまでは、MopsのOOシステムも、標準的にみられる機能をでていない。「できること」を表にして比べると、どうということはない印象になってしまう。Mops OOシステムの驚くべき特性は、そこからうかがい知ることはできない。その特性というのは、実はインスタンス変数と呼ばれる対象の仕様の差異から生じてくるのである。 First Order OO System 実用を考慮したオブジェクト指向システムの議論を見ると、インスタンスとして観念されるのは、属性データの塊という趣が強い。インスタンス変数をフィールドと呼んだりスロット — 全てがリストであるとする見方に相応しい — と呼んだりすることに、その思考前提が垣間見られる。そういった属性データの塊が、その上に稼働するメソッドと組になってクラスインスタンスを構成し、上位クラスに特有のデータ塊は、下位クラスの属性データの部分集合を成すことで引き継がれる。上位クラスのメソッドは、データ塊の部分集合に動作するものとして引き継がれ、下位クラスは追加的な属性データの上にもメソッドを持つことによって、上位クラスを拡張、変形するのである。 このようなオブジェクト指向システムは、具体的インスタンスの属性データを第0オーダー、その類型を定めるクラスとデータを操作する関数としてのメソッドを第1オーダーとみれば、形式論理でいうファーストオーダーシステムを形成していると見ることができる。変数と関数からなる特にオブジェクト指向システムを持たない手続的プログラムと、大差はない。データ指向であること、つまり、属性は違うが同類のデータを持つインスタンスを求心点として、その上のプロセスが集められ、編成されているというところが、オブジェクト指向の処理プロセス指向とは異なる点、ということになるだろう。 構成素(Objects) 位階(Logical Order) データワード(Variable, Value, Array etc.) 0階(the 0th order) 実行ワード(Executable words (colon-definition etc.) ) 1階(the first order) クラスインスタンス(Class instances) 0階(the 0th order) メソッド(methods) 1階(the first order) クラス(Class (prototype)) 2(1.5)階(the second or 1.5th order) 継承(inheritance) 3 (2.5)階 (the third order or 2.5th order) この数え方で、クラスはセカンドオーダーになる。クラスというオブジェクトが眼に見える形で導入されなくても、インスタンスを中心にメソッドが編成される形が、クローンなどで複製できれば十分である。クラスは数値を返さないので関数ではない。しかし、関数を対象として編成する。見方によっては、インスタンスの求めに応じて関数を返すメタ関数とみることもできる。インスタンスと関数を結びつけるのである。その意味で、クラスの論理階数は関数の1つ上になる。とはいえ、一方の端であるインスタンスがデータの塊として0次オーダーで考えられているのが、ややバランスが悪い。この点からみれば、ここではクラスはむしろ1.5階程度に止まっているというべきかもしれない。 Second Orderは「2次」と訳す人もあるようだが、数学ではかなり昔から「階」と訳していたと思う。まあ、分かればどっちでも良いが。 俗な言い方では、階が上がる毎に、いわゆる「メタ階層」に移行するという話である。 このような形のセカンドオーダーオブジェクトが導入されることが、オブジェクト指向によるプログラミングの革新の出発点であろう。 したがって、このレベルでもオブジェクト指向のプログラミングは可能であるが、そこで実際に新しくできるようになることは、あまり多くない。中心的なことは、関数がインスタンスをコンテキストとして持つことができるようになること、であろう。つまり、ひとつの名前で特定される関数が、それに付け加えられるインスタンスのコンテキストに応じて、様々な動作をするということである。ドグマ的に発想すれば大したことのようにも思われるが、実用上は、別のクラスが同じ名前のメソッドを持ちうるというだけの話で、画期的に有用かというと、それほどでもない。 そこで、このオーダーからはみ出さない頭で考えて、なお有用性を強調しようとすると、処理手順を「動的に」組み合わせ変更できるという方向がひとつある。その方向に行くと「Late Bindはオブジェクト指向を便利なものにするには必須」とかいいだすのである。 それどころか「動的」なものはオブジェクト指向的とか言い出すに至っては、知能崩壊としかいいようがない。そこまでいうことはないか。 実際、動的束縛が便利な局面というのはある。けれども、forthで考えると「屋上屋を架す」の類にしか感じられないのである。特別に静的にガッチリと固めなければならない言語であればメリットも感じられるのだろうが。 この方向をもっと伸ばそうとすると、インスタンスの個別的特性に応じて、前処理や後処理を追加したり、処理の順番を変えたりできるような手段があればいい、ということになる。MOPの議論はこの方向でオプションを追加しようという話を含んでいる。ここまでくると、確かに、かなり「動的」という感じは出てくる。逆に言えば、これくらいできないと、例えばLISPなどでは、オブジェクト指向の機構を利用する意味が感じられなかったのではないかと想像される。 抽象的論理平面で考えると、そのような個々のメソッドの束ね方の操作可能性は、1階要素同士の関係を操作しようとするものである。この点で、ここに至って初めて額面通りのセカンドオーダー領域が拓かれたともいえる。つまり、インスタンスは0階という認識のままである「アカデミックな」オブジェクト指向理論では、クラスは中途半端な第2階に止まってしまうので、MOP云々で初めてキッチリ第2階といえるレベルが導入された、ということになるのである。 それでも、ここまでは、ファーストオーダーのオブジェクト指向の発想の中に止まっていてもできる。 クラスないしタイプを経由した、ファーストオーダーのデータとしてのメソッドの結合関係を前提としつつ、その組を対象単位として、組同士を関連づける機構は、セカンドオーダーといってよいと思われる。そのような機構を操作してどうするかを考えるのがセカンドオーダーのオブジェクト指向、というわけである。 言い方が抽象的になってしまったが、セカンドオーダーOOのための機構といえる最も馴染みのあるものは、実は、継承(Inheritance)であることに気づく。継承は、クラスとクラスの関係を操作するものである。その意味で継承はもっとも古典的な第3階要素である。その内容は、内部構造の複製と追加的変形修正である。 Second Order OO System けれども、継承はもともと静的な秩序を指向する制約的な手段である。その本質上、窮屈なのである。その結果、上に書いたような「オブジェクト=属性データ」思考では、継承はクラスの構成にめり込んでしまい、より高い抽象度の操作性を持つことができないのである。 そこで、もっとカジュアルに使える第3階要素が求められるわけだが、ここに、ちょっと、その歴史的展開に関する話を挿入してみたい。 構造思考脱落の歴史 継承の制約 継承はこれまでにないプログラム操作の手段を与えたものなわけで、初期のオブジェクト指向プログラムの関心が、継承の機能に集中していたように見えるのも、無理もないことなのである。ところが、そこに落とし穴があったことは、多分、今では誰でも知っている話である。その穴を埋めようとした結果として、新機能が続々と出てきて追加されることになったわけである。この過程で、継承、特に多重継承は悪玉に仕立てられてしまった。けれども実際に問題だったのは、継承が発生してきた背景をすっ飛ばして、売りのための「高度なfeature」だけを追求する姿勢だったのだと思う。 継承からの逸脱、そして離脱 継承は階層構造を構成する。それは、静的なデータ構造と序列関係を基礎としている。あるクラスが他のクラスを継承するとすれば、それは核部分に同じ静的構造を持っているからである。そのことがデータ処理の効率をも高める。そのように、継承はその由来から見ても、静的でカッチリと固まった構造を設計する思考を伴うはずのものである。柔軟で動的な処理を支える堅固な骨格のような。 ところが、複数の関数を束ね合わせるための方法が継承ぐらいしかなかったため、「便利な機能を他所から持ってくる」というだけの発想で継承が扱われ始めた。あれもこれもと、便利そうなメソッドを獲得するために多重継承、という話になった。けれども、継承はもともとそんなものではなかった。特に多重継承は構造が複雑になるのだから、予め静的に設計した上で統合するべきものである。だから、あれもこれもというご都合主義発想に向かないのは当然である。(逆にキチンと設計すれば大したことではなく、多重継承の難点などというのは架空の抽象論でしかないのだが、プログラマーは行き当たりばったり人種なのである。そしてformal指向のアカデミズムは「任意に選択した — つまりデタラメの — 場合の問題」を真剣に論ずる。結果、真面目な人ほど「原理的に」騙される。) もっとも、データ構造に関しても元々動的で緩い種類の言語では、継承も、初めから機能を引っ張ってくるということでしかなかったのだろう。 とはいうものの、異なるタイプ間でメソッドを結合する方法は継承しかなかった。そんなわけで、オブジェクト指向の「新機能」は、当初は「継承を迂回する方法」という体裁で主張されることが多かったのだろう。 delegateでさえ「継承を回避することができる」とかいわれるらしい。継承が負担過剰だったことは明らかである。 継承経由でなく、例えば、友だち同士ならば使えるメソッドをつくるとか、逆に、下位クラスにも使わせないメソッドをつくるとか、あれこれ方法はあった。けれども、決定的だったのは、多分、mix-inであろうと思う。 mixin,Traits etc. mixinは、自分の理解する所によれば、継承関係にないクラスを横から持ってきて、そのクラスのメソッドも混ぜて1つにまとめてしまう方法である。謳い文句は「多重継承なしでも他クラスのメソッドが使える」。実際、そこでの問題は、機能的なまとまりを構成する関数とデータを束ねること、であって、整合的な構造系列の構築などではないのである。だから必要な処理手続を横から借りてきて集めるという方法が、もっとも直接的な問題の解法であるように思われる。 けれども、mixinは横から借りてきたメソッドも、筒抜けに利用できるようにするものである。すると、メソッド名の衝突をどう解決するかという問題が生ずる。同じ名前のメソッドが、上位クラスから継承されたものにも、mixinされた複数のクラスにも、また、当のクラスでオーバーライドされたものとしても存在する、ということがあり得る。そこは、まあ、常識的に優先順位はつくように思うが、メッセージを送るコードを書く側から見ると、ちょっと不安である。デフォルト順位をかいくぐる方法とかも考えると、かなりややこしい。とすれば、mixinしたクラスのメソッドは筒抜けにはせず、なにか特別に符牒を付けてアクセスする方が、多少、文字数は増えても、読み書きの際に何をしているのか分り易く、メンテナンスも容易なのではないか、とも思えてくる。 それはともあれ、必要なメソッドを継承関係の無い脇道から引いてくるというのは、アスペクトがナンタラという考え方に繋がっていると思われる。 Mopsのインスタンス変数特性 上のような展開と対比して初めて気づいたことなのだが、Mopsのインスタンス変数の性格は、プログラミング上に特異な効果をもたらしている。インスタンス変数は、普通は、クラスインスタンスの内部データの1つ1つを指す。Mopsでもこの点に違いはないのだが、そのインスタンス変数は、単なるデータではなくて、他のクラスのインスタンスなのである。呼び名としてはインスタンス変数というものの、NEWされたオブジェクトのレファレンスを格納する変数ではない。名前で特定されるインスタンスそれ自体が埋め込まれているのである。したがって、継承系列外のクラスのインスタンス変数を追加するだけで、その外部クラスのメソッドが当クラスの機能に追加されるのである。インスタンス変数へのメソッド束縛は原則として静的であるから、実行速度のペナルティーもない。したがって、インスタンス変数を宣言することは、クラスの中に他のクラスの機能を埋め込むことであり、クラスインスタンスにとっては、その中に別のクラスのインスタンスの機能を埋め込むことになるのである。 ただし、インスタンス変数のメソッドはmix-inの場合ように筒抜けにはならない。クラスのメソッド定義から、インスタンス変数にメッセージを送ることで、その機能を利用するのである。したがって、定義クラスがインスタンス変数のクラスの特性を持つようになるのではなく、インスタンス変数のクラスの機能が定義クラスのプライベートな内部機能として追加される、ということである。インスタンス変数は、全く独立に動作できるインスタンスではあるが、存在としては当のクラスの内部的機能にはめ込まれている。クラス定義が、次第にハイレベル機能のモジュール作成という特性を強めてくる。これは、アスペクト指向とかいわれているものの基本であるように思われる。この機能の実装は1980年代の初め頃から存在することになるわけだが、あまりそういう観点から見られることはなかったようである。 一般論では、現在でも、クラスのインスタンス変数宣言部分はベタなデータの格納庫づくりとして捉えられ、結果、インスタンスも実態は付属データの塊とされ、関数部分であるメソッドの操作のところにだけ、何かハイレベルな特性を求めようとする発想が、まだ主流ではないかと思われる。いずれにせよ、Mopsのオブジェクト指向の強みは、その発想を超えた所にある。標語的にいえばコンポジションによるモジュラーなコーディングである。インスタンス化は、そのモジュールを現実に生産することである。 これはオブジェクト指向思想の基本であったと思われるが、現実には、そこに到達しているものは以前は乏しかったのかも知れない。 それがいつまでも怪しいOO教説本が尽きない理由かも知れない。商業的宣伝と技術的解明は区別されなければならないはずのものと思うが、 電子技術系での混同傾向は昔から強く、近年は特に甚だしいように思われる。 さて、このような機能を考えると、各構成素の論理的位階が若干変わってくる。 クラスインスタンスは、属性データの塊としての0階要素から、文字通り処理機能を兼ね備えた具体的動作主として、1階要素に持ち上がる。すると、メソッドとインスタンスを関連づけるクラスは、1階要素を対象として操作するという意味で正式に2階要素と見ることができるようになる。 加えて、クラス内で行われるインスタンス変数のコンポジションは、クラス機能同士を束ねるという意味で、第3階要素と見ることができる。 構成素(Objects) 位階(Logical Order) データワード(Variable, Value, Array etc.) 0階(the 0th order) 実行ワード(Executable words (colon-definition etc.) ) 1階(the first order) クラスインスタンス(Class instances) 1階(the 1st order) メソッド(methods) 1階(the first order) クラス(Class (type)) 2階(the second order) クラス -- インスタンス変数宣言(Ivars declaration) 3階(the third order) 継承(inheritance) 3階ないし3.5階?(the third or 3.5th order) このとき、継承は、合成されたインスタンス変数機能を引き継ぎ操作するのであるから、第4階といえないこともないが、構造的設計が必要であることを考えれば、「操作」といえるほどのものでもない。 つまり主張の要点は、Mopsでは、クラス定義がある種のメタクラス定義の特性を持つということである。もっとも、例えば、Rubyなどの新しいオブジェクト指向言語には、多分、同じように解釈できる機構が備わっているであろう。今ではおそらく、特別に先進的な機能ではないだろう。しかし、逆に言えば、MopsのOOシステムの意味が理解される条件が今やっと整ったといえるのではなかろうか。 「背景思考」と実際のコーディング 便利な機能を強調する宣伝思考では、オブジェクトの見方などはどうでもよい話のように思われるだろう。ところが、人様の話を読んだり聞いたりしていると、意外にそうでもないらしいことが分るのである。 継承系列 まずは、実証的な方向から述べてみよう。 Mopsのオブジェクトシステムでコードを書いていると、継承を使う場面とインスタンス変数を使う場面を使い分けることを考えるようになる。インスタンス変数が文字通りインスタンスが持つことになる変数フィールドでしかない言語仕様では、継承とインスタンス変数が機能的に重なるという意識を持つことはないのではあるまいか。 「継承」の原語は「Inheritance」である。系譜学(Genealogy)風の用語であり、「何かが引き継がれる」イメージで理解される傾向にあるように思われる。それで間違いということはないのであるが、クラスを用いて構造的に定義していく仕様では、実はむしろ階層的類別に近いものと考えるべきであろう。クラスの系譜を下ることは、むしろ一般から特殊へと降りてくることであって、親から子へ代々受け継がれる属性というのとは微妙に異なるのである。後者は、むしろ、プロトタイプ-クローン型のオブジェクト指向の発想であろう。もっとも「既存の便利な機能をあれこれ借りてくる」という発想は、どちらとも完全には適合できない。 そのようなわけで、Mopsのオブジェクトシステムでプログラミングする場合、継承は、下位クラスが上位クラスの機能的特殊化であるといえる場合に採用されることになる。機能の豊富化ではないのである。機能の豊富化にはインスタンス変数の追加が利用される。これはいわば異化作用である。 その結果の一つとして、やたらと長い継承系列が無くなる。必要なくなるのである。 小さな変異なら、同じクラス内でも扱える。それはforthの機能を用いて容易にできる。 他のオブジェクト指向言語でも、おそらく、mixin機能がついてきたところで、継承の負担軽減が現実に可能になったのではないかと憶測される。(そして、「継承を使うのはヘタクソ」みたいなスローガンが作られたであろうことは想像に難くない(実際は知らないが)。) ともかく、上の段に書いたような一般的基準は、コードの構成を考える上でかなり明確な手掛かりになる。 例えば、FILEというようなクラスがあったとして、新しく定義しようとするクラスがファイルを扱う機能を持つとする。そのとき、新しいクラスのインスタンスは、何かファイルといえるようなモノ(対象)であるかどうか、が問題となる。それがある種のファイルであるという場合には、継承すればよい。そうではなくて、別のものだがファイルと密接に関わるものであるというなら、インスタンス変数としてFileを持てばよいのである。 Mopsでは経験からごく当たり前のことである。実際には自分はオブジェクト指向云々を学校とか本とかでキチンと勉強したことなどない。ごく断片的な話と実地でどう考えるかとの組み合わせで思ったことを書いているのだが、お勉強方面でも基本は同じ議論をしているようにも見える。しかも、どうも一般にはかなり応用に入り込んだ話で、理論として勉強して初めてそこに到るものであるらしい。いや、まあ、それは人にもよるのだろうが。それに、自分の見方が全く根本的に間違っているという可能性も捨て切れない。そこは読者諸氏の賢明な判断に委ねざるを得ないわけであるが。 オブジェクトのCompositionという発想 オブジェクト指向の死から Mopsのプログラミングに慣れると、オブジェクトの合成(Composition)という見方を自然にするようになる。いつも必要になるわけではないが、プログラムでインターフェイスになるような最終生産物的対象は、大抵、そんな感じになる。 ところが、一般に流れている話を見ると違和感を覚えるのは、その合成の発想が、オブジェクトではなく、メソッドのcompositionであるということなのである。つまり関数指向、あるいは、プロシージャー指向である。有意義な作用をするのはいつもプロシージャーであってデータではないからでもあろうし、アカデミクス方面での主流が関数型思考だからでもあろう。しかし、これは、オブジェクト指向の死でもある。 というのは、オブジェクト指向の基礎的な考え方は、次のような表式で表されているはずだからである: データ構造+アルゴリズム=プログラム(モジュール)=オブジェクト; プロシジャー指向は、データ構造をすっ飛ばして、処理アルゴリズムだけを考えるコマンド型モデルへの回帰である。モジュラーとか構造型とかいう話の以前の、最古のプログラミング観への退行である。 もっとも、データ構造というのは、コンピューターという機械の機構から出てくる観念である。つまり、計算理論も含めて数学とは無縁のものである。私見としては、そこにソフトウェア科学の工学としての重要な1側面があったと考えるが、数学で数値計算だけを考えると、確かに、データ構造って何?という話になる。邪魔になるだけであるのならば、データ構造の発想など捨ててもかまわない、ということになる。それを捨てても、「手数(てかず)を減らす」という発想は工学的な部分として残るから、学域としての独自性は保つことができる(多分)、と。すると、プログラムは、パブリックとかプライベートとか符牒をつけるだけで区別されたことになるコマンドの集まりを、適宜束ねて扱うものとなる。結局、総体が手続型のモジュール形成、例えば、動的ライブラリの構築とかに還元されてしまう。オブジェクト指向の死である。最も旧式の手続指向が自分たちこそ「最新鋭の」オブジェクト指向だと主張することも可能になっている。プログラミングの歴史は手続指向の圧勝である、ということにでもなるのだろうか。 実際、オブジェクト指向というとき一般に考えられているのはオブジェクトライブラリーの提供である。 そのようなオブジェクト指向は、プログラミングの方法であるというより、プログラミングしないで済ます方法である。生産的手段というより消費材である。 確かに便利だが、そのような便宜提供にはオブジェクトは不要である。マシンのプログラムを学ぶためには、むしろ有害であろう。 機械の仕組みはこの数十年基本的に変わっていない。にもかかわらず、データ構造という概念が捨象できるようになった理由は、おそらく、データの低廉化だろう。それはメモリーが安価になったという量的な意味で低廉化と同時に読み書きの高速化という処理時間的な低廉化が同時進行したことである。そこで起こったのは、データ構造の抽象ではなく捨象である。データの形の流動化、あるいは不定形化である。もちろん、機械に落とす所では不定形なままでは処理できないから、プログラム構成の段階で不定形なデータは、コンパイル時か実行時か、何処かの段階で決まった形を与えないといけない。それがかつては大変な手間であったのが、今では、実行時にそれをしても、体感上は特に問題が無いほどになってしまった。もっとも、本体の処理量が膨大で、ともかく高速で直接的な処理が必要になる場合には、実行時の特定というのは問題にならない。するとコンパイルには膨大な時間がかかることが多いが、それは一回きりなので、よいのである。 このメモリーの低廉化と処理速度向上の話は、プロシージャーの意味での「動的」処理の実用化という話に限定して語られがちであるが、そこで得られた実際の成果というのは、むしろ、データ構造という思考の破砕であると思われる。 形式論理との対応を常に意識していた関数型言語では当初からデータ構造の流動化を指向していたように見えるのは興味深い論点だが、 ここではあまり関係ないのでやめておくことにする。 とはいえ、機械の動作にはデータ構造の思考がなお有効なのである。そして、よく考えれば、人の思考、とくに科学的というか学問的な水準でキッチリと考えようとすると、何かを名指すものの形式構造について意識する必要があることが多いのである(タイプ論はその(やや表面的な)複製である)。素人の物知りと本格的な研究者とを分けているのは大体その点であり、構造無視のゆえに、知識が豊富でもトンデモナイ話に引っ掛かったり、素っ頓狂な話を信じて主張したりすることが多いのである(この危険は、現状では専門家とか学識経験者にまである)。これは機械の構造とは違うものだが、現実に基づくという際のインターフェイス部分の問題として何か象徴的な連関が感じられるのである。計算理論方面では、データは所詮は数値と言うことで均質で不定形なデータを扱うことで済んでいるのではあるが。 ソフトウェアというのが、機械と人とをつないで人が機械を簡潔かつ的確にコントロールできるようにすることを課題としているものだと考えれば、多様な要請に対して機械をキチンと誤りなく制御するためには、データ構造という思考自体は、今も不可欠であると思う。iMopsのドキュメントに、「ExactでRobustな処理のためには構造的思考は今も必要だ」と書いたのは、だいたいそういう趣旨である。だから私見としては、オブジェクト指向、つまり、データ構造とアルゴリズムをきっちりと組み合わせたプログラムをモジュール化したものとしてのオブジェクト、という考え方は、まだ死ぬべきではないと思うのである。...が、... オブジェクト参照変数との異質性 インスタンス変数は、他クラスのインスタンスでもあり得るべきである。そうすれば、新クラスはメタクラスのように機能できるのである。 (もっとも、基本がforthであることもまた、この作用のために重要な要素であると思われるが。) ところが、インスタンス変数を属性データの塊として規定してしまう思考からは、その意味が理解できないようである。「インスタンス変数はオブジェクトの参照を格納するポインタ変数であることもできるのだから、そんなことは当然できる」というのである。加えて、そのような参照はランタイムに入れ替えることもできるのだから、より動的であって優れている、と。Forthプログラマーでさえも概してそう思うようである。 「動的(ダイナミック)」云々はナントカの一つ覚え的で、何でも動的ならば良いというものでもなかろうが、それは別としても、確かに、オブジェクト参照をインスタンス変数として用いることで、少なくとも機能的には同じ結果が得られるようにも思われる。 しかし、オブジェクト参照をインスタンス変数にできないオブジェクト指向言語は存在するのだろうか?多分、大抵のものでは可能なのではないかと思う。では、なぜ、mixinのような特殊機能が歓迎されたのだろうか? かつて、SmalltalkとMopsの双方に詳しい知人に尋ねてみたことがある。すると、インスタンス変数は基本的にオブジェクト自体というよりその参照変数であり、基本データ以外のクラスのインスタンス変数では長いメッセージ系列には実行速度の点でペナルティーがあるなど、あまり便利ではないということであった。ひょっとすると、いちいちインスタンス変数にコンストラクタを呼ばないといけないのかもしれない(良く知らない)。 しかし、思うに、これは、システムの機能というかfacultyやfeatureの問題ではないのである。プログラム構成の基本思想の問題なのである。 オブジェクト参照の変数としてのインスタンス変数という発想からは、クラス定義が諸クラスのバンドルとコンポジションになりうるという考えが、多分、出てこないのである。インスタンスのデータフィールドあるいはスロットには他クラスのオブジェクトの参照も格納できる、というだけでは、まだ何か違った観点に立っているのである。 Mopsにもオブジェクト参照という特別なオブジェクトがある。これは、通常は他所で生成されたインスタンスのベースアドレスを格納する。インスタンス変数にすることもできるが、その場合も、外部からインスタンスを格納するか、特別にNEWしないと、コンテンツが欠けた状態に止まる。この機構は、メッセージを受けるオブジェクトを流動化しつつ無名オブジェクトの束縛を効率化するために事後に導入されたものだが、もし、初めからこれだけがインスタンス変数として許されていたならと想像すれば、確かに、インスタンス変数宣言がコンポジションの一翼を担うという考えは出てこなかったかも知れない、と思う。 すると、ごく部分的なものでしかない他クラスインスタンスの埋め込みというインスタンス変数宣言の仕組みが、プログラムの構成の仕方や言語の総合的セマンティクスを転換する効果を持った、ということかも知れない。 単純に言語の断片的機能や能力の一つとしてみれば、確かに大したことではないのである。 実際にMopsでコードを書いていても、必ずしもコンポジションとしては考えない人もいるようではある。 これはしかし、ある程度の経験というか、その変容を自分の感覚で感じ取る機会がないと、なかなかわからないようなのである。 あるいは、政治的な理由でわからないふりをしているだけかも知れないが。 結語 インスタンスを属性の塊にとどめてメタ方向に延ばしていこうとはせず、プロシジャーないし関数としてのメソッドの動的組み合わせ可能性に集中するオブジェクト観では、インスタンスは、単に、メソッドを選択するコンテキストでしかなくなる。もっといえば、インスタンスは、vtableの切り替えスイッチでしかない。そして、どれだけ多くのタイミングでスイッチ切り替えの機会が与えられているか、ということが誇られるのである。見たまえ、ダイナミックだろ、と。 オブジェクト(と呼べるもの)があること、とか、各要素がオブジェクトであることが重要なのではない。そのような名目には何の価値もない。重要なのは、それがプログラミングにもたらす機能である。機能とは特定局面で使える道具的便宜に限られるものではない。とくにオブジェクト指向システムのような機構にとっては、プログラム構造的なレベルに、その主要な機能があるはずのものである。私見では、クラスシステムであろうがプロトタイプシステムであろうが、コンポジションによるモジュールの逐次的拡大ができないものは、オブジェクト指向システムと呼ぶに値しないし、そのような発想でプログラムを組み立てたことのない人は、オブジェクト指向プログラミングの経験はないのだというべきではないか、とさえ思う。 Mops言語の観点からは、まとまったモジュールの構成と、その構成の意味付けに関する抽象化の能力を高めることが、最重要の関心事である。ダイナミック云々は、モジュールの機能的完結性とコードの再利用可能性などの点から、必要に応じて対応できればそれでよい。実際、可変性や柔軟性の面では、コードをデータとして扱い、適宜実行できるforthの仕組みによって、既に十分に与えられているように思われるからだ。 小さく機能的にまとまったモジュールとしてのワードをキチンと組み上げていく、というのが、Mopsの基底言語であるforthの流儀であるとすれば、MopsのOOシステムは、機能単位としてのモジュールの意味的抽象化能力を一定方向に更に高めているという点で有効なのだ、と考えるのがMopsプログラマーとしての観点である、と思う。 これが、おそらく、他のページでも書いた、Mopsのオブジェクト指向が、forthの発想の自然な(ただしある特定方向へでしかないが)拡張のように感じられる根底にある思想なのだ。 結局、Mopsのオブジェクト指向は、forthが本来持っているモジュラリティーの思想を基に、より複雑な固有データ構造をモジュールに追加して組み合わせることを可能にし、結果として、機能的な意味単位としてのモジュールの抽象度を螺旋状に高めることを可能にしているのである。
https://w.atwiki.jp/m_shige1979/pages/1132.html
オブジェクト調査 概要 is_object サンプル(is_object)をチェック ?php // 親クラスなし class TestClass01{ public $aaa; public $aaa02; private $bbb; private $bbb02; protected $ccc; protected $ccc02; function __construct(){ $this- zzz = "aaa";// コンストラクタ時に定義するため、検知できない $this- bbb = "111"; $this- ccc = "222"; } } ? ?php // stdClass $obj1 = new stdClass(); object_check($obj1); // TestClass01 $obj2 = new TestClass01(); object_check($obj2); // ERROR $obj3 = "aaaaaaaaaaaa"; object_check($obj3); function object_check($obj){ if(is_object($obj)){ $_class = get_class($obj); echo $_class . " object ok\n"; }else{ echo "not object \n"; } } ?
https://w.atwiki.jp/javastudy/pages/30.html
★クラスとオブジェクトの応用 ■objectクラス objectクラス…すべてのクラスのスーパークラス ■instanceof instanceof……オブジェクトが指定したオブジェクトかどうか調べる boolean flag =cinstanceofX;←クラス名 ↑オブジェクト名 指定したインタフェースをオブジェクトが実装しているかを調べることもできる boolean flag =cinstanceofY;←インタフェース名 ↑オブジェクト名 ■ サンプルプログラム interface Cry { void cry(); } class Cat implements Cry { public void cry() { System.out.println("にゃー"); } } class Dog { public void cry(){ System.out.println("わん"); } } class CheckCry { public static void main(String[] args){ Cat cat = new Cat(); Dog dog = new Dog(); if(cat instanceof Cry) { cat.cry(); } if(dog instanceof Cry) { dog.cry(); } } } ■サンプルプログラム //抽象クラス Figure abstract class Figure { abstract void area(); // 面積 abstract void around(); // 外周 void measure() { area(); around(); System.out.println(); } } // 抽象クラスのサブクラス Square class Square extends Figure { double side; double height; Square(double s){ // コンストラクタ side = height = s; } Square(double s, double h) { // コンストラクタのオーバーロード side = s; height = h; } void area() { // 抽象メソッドのオーバーライド System.out.println("四角形の面積:" + (side*height)); } void around() { // 抽象メソッドのオーバーライド System.out.println("四角形の外周 " + (2*(side+height))); } } // 抽象クラスのサブクラス Circle class Circle extends Figure { final double pi = 3.14; double radius; Circle(double r) { // コンストラクタ radius = r; } void area() { // 抽象メソッドのオーバーライド System.out.println("円の面積" + (radius*radius*pi)); } void around() { System.out.println("円の外周" + (2*radius*pi)); } } class SizeFigure { public static void main(String[] args) { Figure fig1 = new Square(2.5); Figure fig2 = new Square(2.3,3.7); Figure fig3 = new Circle(3.6); fig1.measure(); fig2.measure(); fig3.measure(); } }
https://w.atwiki.jp/index-index/pages/2536.html
【種別】 装置 【初出】 ヘヴィーオブジェクト 【解説】 オブジェクトに動力炉を組み込む前に試験的に作る実験炉。 炉を通常ではありえない特別臨界状態に変異させる事で、意図的に爆発を引き起こす事が可能。
https://w.atwiki.jp/index-index/pages/2557.html
【種別】 装置 【初出】 ヘヴィーオブジェクト ファースト・コンタクトブック 【解説】 静電気の反発剤となるスプレーを中和する物質と大量の静電気を発生させることでオブジェクトを浮かばせている静電気を乱し、 一時的にオブジェクトの動きを止めるマット状の装置。 有効範囲は五〇メートル四方で、オブジェクトの動きを数秒から十数秒ほど止めることができる。 通常のバッテリーではオブジェクトを止めるほどのエネルギーを生み出せないため、 一瞬だけ莫大な電力を生み出せる爆発発電を利用している。
https://w.atwiki.jp/ririna_choco/pages/44.html
画像 場所 ドロップ 出現モンスター 備考 ウィステラの街 - - 破壊不可。通常攻撃はなかなか当たらない。 オダリムの草原1 リカバリンの実Sスキルゲンの実Sスキルゲンの実L ビビリスライムレッドゼリー(1,2) ポドックの森1 リカバリンの実Sスキルゲンの実S トゲネズミベジバード(2)キルウォーム(2-3) オダリムの草原1 スキルゲンの実S ビビリスライム(3)チョコットリ(2) ポドックの森1 リカバリンの実M ビビリスライム(3)チョコットリ(3)トゲネズミ(1,3,4)ヤブアオガエル オダリムの草原1 古びたメダル(5)砂金袋5gもろい鉱石 レッドゼリー(2)トゲネズミ(1,2) ポドックの森1 古びたメダル(5)砂金袋5gよくある鉱石 ファイヤーボール(3) ポドックの森2 古びたメダル(5) ファイヤーボール(5) ポドックの森1 ポドックの森3 マッシュマン 接近時、一定の確率でマッシュマン(高確率)又はマツタケリン(低確率)出現。 ポドックの森4 ビックリダケ草クラゲ(3) 接近時、一定の確率でビックリダケ(高確率)又はマツタケリン(低確率)出現。 ポドックの森2 草クラゲ(3) ポドックの森4 砂金袋5g ラストード(6) グランガンの谷 原始の谷入口 草クラゲ(1) グランガンの谷 谷1 グランガンの谷 湿地帯 グランガンの谷 湿地帯 グランガンの谷 湿地帯 レイコールの塔1F 砂金袋10g砂金袋50g レイコールの塔B1 部屋A 砂金袋10g ブラックグミ(7) レイコールの塔2F 部屋K レイコールの塔1F 古びたメダル(10)砂金袋5g(2)カイザー液S鋭い鉱石 ブラックグミ(1,3,5) レイコールの塔B1 部屋A 古びたメダル(10) レイコールの塔3F キラキラした鉱石 レイコールの塔B1 部屋A スカスカした骨 スカルトンハイエナマウス 接近時、一定の確率でスカルトン出現。 レイコールの塔1F リカバリンSエンジェルフェザー メソメソおばけ(1,3,5) レイコールの塔2F 銅のかけら鉄のかけら 亡霊兵士ドッキリゴースト(3,5) 接近時、一定の確率で亡霊兵士出現。 レイコールの塔2F 部屋K ドッキリゴースト(5) ヴォルケの洞窟 入口 ファイヤーボール(3)ラストード(3,5) ヴォルケの洞窟 灼熱の広間1 接近時、一定の確率で玄武出現。 ヴォルケの洞窟 灼熱の広間1 ファイヤージェル(4) コメント 最新の10件を表示しています。コメントページを参照 名前:
https://w.atwiki.jp/agile_game/pages/13.html
オブジェクト指向設計の原則 オブジェクト指向設計の原則とは? オブジェクト指向におけるクラスなどのソースコードに変換する際の基本原則です。 オブジェクト指向設計の原則はどんなものがあるのか? 単一責任の原則 ( SRP The Single Responsibility Principle ) クラスを変更する理由は一つ以上存在してはならない。 オープン・クローズドの原則 ( OCP The Open-Closed Principle ) ソフトウェアの構成要素( クラス、モジュール、関数など )は修正に対して閉じていて、拡張に対して開いてなければならない リスコフの置換原則 ( LSP The Liskov Substitution Principle ) 派生型はその基本型と置換可能でなければならない。 依存関係逆転の原則 ( DIP The Dependency Inversion Principle ) a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。 b. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。 インターフェース分離の原則 ( ISP The Interface Segregation Principle ) クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。
https://w.atwiki.jp/sinnerei/pages/451.html
【作品名】ヘヴィーオブジェクト 【ジャンル】小説 【名前】ミリンダ=ブランティーニ 【属性】ベイビーマグナムのパイロット 【年齢】14歳 【長所】盾になったりトドメをさしたりと、こいつが居なかったら主役二人は何度も死んでる 【短所】局地戦特化の第二世代には苦戦する vol.4
https://w.atwiki.jp/30pin/pages/13.html
┼ オブジェクトを地面にスナップ 概要 机の上に物を置く時など、地面やオブジェクトの表面にスナップします。 オブジェクトを遠くに移動する時にも便利です。 Let s Try! 選択・移動モード (Select and Move) を選択 移動したいオブジェクトを選択 配置したい場所で Ctrl + Shift + 左クリック ┼ ┼ 無料レンタル
https://w.atwiki.jp/terragen/pages/84.html
はじめに この項では作成、またはインポートされたオブジェクトについて解説します。Terragenはいくつかの組み込まれたオブジェクトを備えており、また各種フォーマットのオブジェクトファイルをインポートする事が出来ます。オブジェクトの作成時に生じる解説や設定するためのアクセス方法があります。最後にインポートされたオブジェクトの対処法が記載されています。 オブジェクトのインポート TGはいくつかのオブジェクトファイルのインポートをサポートします Terragen Object (.tgo)Terragenオブジェクト、またはTGのネイティブオブジェクトファイルのTGOフォーマット。このフォーマットの中でオブジェクトを見つけ出す事が出来ます。最も適した例はXfrog社の植物オブジェクトです。TGOはジオメトリを加えたテクスチャとマテリアル(プロシージャルテクスチャを含む)を含めています。 Wavefront OBJ (.obj)Wavefront OBJは一般的なオブジェクトファイルフォーマットです。TGOフォーマットの入手が出来ない中では、TGにインポートするオブジェクトとして最良の選択肢です。OBJにはマップベースのテクスチャとマテリアル画像だけではなく、ジオメトリを含んでいます。 Lightwave LWO (.lwo)Lightwave LWOは3Dアプリケーション『Lightwave』フォーマットのオブジェクトです。このフォーマットは最低限サポートされているだけで推奨していません。代わりのOBJフォーマットを使用して下さい。 TG4はFBXフォーマットをサポートしますが、FBX経由でオブジェクトやジオメトリのインポートはサポートしません。『Terragenのインポート/エクスポート関連事項』の項目で、サポートされたオブジェクトフォーマットについてのより詳細な情報を見出す事が出来ます。 TGにオブジェクトをインポートするのは簡単であり、多くの方法が用意されています。 ファイルメニュー オブジェクトのインポートのために、ファイルメニューには2つの項目を備えています。"Import Object"。これは、インポートするフォーマットの選択可能なサブメニューを備えています。"as Population(ポピュレーションとして)"オブジェクトをインポートする事も可能です。これらの項目のいずれかを選択時に、インポートファイルを選択するための「ファイルを開く」ダイアログボックスが表示されます。 "Import Object from Library...(ライブラリからオブジェクトをインポート)"。インポートするオブジェクトをブラウズから選択するためのライブラリ・ウインドウが開きます。 オブジェクト・ノードリスト メインのトップツールバー【Objects】ボタンをクリックすると、オブジェクトノードリストが左上に表示されます。そこで[Add Objects]ボタンが見つかります。ボタンをクリックするといくつかのアイテムを備えたプルダウンメニューが表示されます。"From Library..."を選択すると、インポートするオブジェクトをブラウズから選択するためのライブラリ・ウインドウが開きます。 "Objects"です。これはオブジェクトの種類を選択するサブメニューを備えています。サブメニューにはGrass Clump(草茂み)やRock(岩石)などのTGに組み込まれたオブジェクトが含まれています。オブジェクトのインポートには"xxx reader"と記されたオブジェクトを選択する必要があります。例えばTGOファイルのインポート時には"TGO reader"を選択します。このメニューからアイテムを選択すると、Populationとは対照的に単一のオブジェクトを作成します。 "Displaceable object"です。ここに備えられたオブジェクト(cube、disk、octahedron等)は、いつでもディスプレースメントが最も効果的に機能してレンダリングが行えますが、他のオブジェクト(TGO、OBJ、LWO、Card、Grass Clump、Rock)はレイトレースでディスプレースメントのレンダリングが行うには扱いが難しいです(ただし、micropolygon rasteriseでは行えます)。具体的な取り掛かり方法しては、オブジェクトの「Rendering」タブにある"Rendering method"を「Force Displacement」に切り替えます。これによりディスプレースメントは有効になりますが、3DプレビューやRTPで変位を確認する事は出来ません。また、"Displacement amplitude"値の単位はメートルなので、パラメータの設定は非常い小さい値から試行してみて下さい。今後これらの制限事項を改善する計画はありますが、現状はこれらの方法でインポートしたオブジェクトを変位させる事は可能です。 "Population"です。これはPopulationがオブジェクトのために作成されている事を除いて、"Objects"の項目としてまったく同じように動作します。 ライブラリ・ウインドウライブラリ・ウインドウは、オブジェクトをブラウズ表示し、どれを作成するかを選択する事が出来ます。上記で説明されている通り、ファイルメニュー、または[Add Objects]ボタンから開く事が出来ます。さらに【View】メニュー、またはトップメニューバーの【Library】ボタンから開ける事も出来ます。ライブラリについては、ここでより多くの情報を見つける事が出来ます。 ノード・パレットノード・パレットを使ってオブジェクトをインポートする事も出来ます。他の方法に比べ手続きは容易ではありませんが、単一のオブジェクトとPopulationを作成する事が出来ます。 ビルトイン・オブジェクトの作成 TGには多くのビルトイン・オブジェクトを備えています。これらオブジェクトは"Plane(平面)"や"Sphere(球)"などの単純なジオメトリオブジェクトから"grass clump(草茂み)"や"rock(岩石)"などより複雑なオブジェクトに及んでいます。これらオブジェクトを単一として作成する事も、多く(全てではない)をPopulationで作成する事も出来ます。ノード・リファレンスで全てのビルトイン・オブジェクトを見る事が出来ます。 前項で説明した通り、ビルトイン・オブジェクトを最も作成しやすい方法は、オブジェクトノードリスト上で[Add Objects]ボタンを使う事です。 これらオブジェクトを作成する別の方法は、ノード・パレットを使う事です。 オブジェクトを作成した次の手順は? オブジェクトまたはインポートされた時、関連する1つ以上のノードが作成されます。単一のオブジェクトを作成した場合、少なくともそのオブジェクト自体のノードが作成されます。Populationを作成した場合、オブジェクト自体のノードと共に"Populator v4"ノードが作成されます。 オブジェクトがマテリアルとテクスチャを含んでいる場合、さらにそのためのノードが作成されます。作成された全てのノードが互いに接続されているため、オブジェクト設定に取り掛かる準備は出来ています。 オブジェクトのノードリスト内でノードを選択する事により、オブジェクトのノードパラメータにアクセスする事が出来ます。Populationを作成した場合は、Populationノードとオブジェクトノードと共に、オブジェクトのノードリストの上位レベルにおいてアクセス出来ます。 作られたノードの名前、またはリストアイテムのアイコンを見る事で、ノード間の違いを見分ける事が出来ます。オブジェクトノードのアイコンは1つのボックスのように見え、Populationノードのアイコンは3つのボックスのように見えます。 ノード・ネットワークの画面からオブジェクトノードのパラメータにアクセスする事も出来ます。パラメータビューを開く為にノードをダブルクリックして下さい。 オブジェクト用に作成されたいくつかのノードは、内部ネットワーク内で別のノードとして作成されます。例えばPopulationを作成時、オブジェクトノードはPopulationノードの内部ネットワークに配置されます。別の例で、オブジェクトのテクスチャとして作成されたノードは、オブジェクトノードの内部ネットワークに配置されます。そういうわけで、たとえ多くのノードが作成されていても普通に1つのノードがネットワーク・ビューに追加されて見えるだけです。作成されたノードの右端に[+]印が描かれているので、ネットワーク・ビューのノードに内部ネットワークを備えているかどうかを判断する事が出来ます。 populationの動作についてより多くを学ぶためにはポピュレーションの説明を参照して下さい。 オブジェクトは3Dプレビュー画面に表示されます。3Dプレビュー内でのオブジェクト表示の詳細は、3Dプレビューでのオブジェクト表示を参照して下さい。 オブジェクトをインポートした際のトラブルシューティング オブジェクトが横向き状態これは"OBJ reader"でよくある症状です。多くの3Dアプリは上方向にZ軸を使いますが、TGはY軸を使います。修正にはノードのパラメータを表示させ、"OBJ Options"タブに切り替えて下さい。そして"Source Z up"にチェック(または非チェック)を入れて下さい。これはオブジェクトに正しい方向付けをして再読み込みします。 オブジェクトのサイズが間違っているように思えるTGの寸法単位はメートルを使用します。モデルが異なる寸法を使用している場合、オブジェクトノードのスケール・パラメータを使ってTG用に適切なモデルにサイズ変更する必要があるかもしれません。あなたが作成したモデルであるならば、作成した3Dアプリからメートルの単位を使ってエクスポートしてみて下さい。 オブジェクトが地表からあまりにも低い、または高位置に設置されているオブジェクトは、モデルの起点に基づいて設置されます。起点はオリジナルのオブジェクトを作成するために使われたアプリに設定されています。TGでオブジェクトを使用する上で、オブジェクトの起点を設定する事は上手く地表に設置出来る価値があるでしょう。例えば根を持つ木のモデルを所有していた場合、起点がオブジェクトの底(根の下)に設定されていると、地表の上に根が下ろされてしまい木は浮かんでいるように見えます。起点を地表面の通常の場所として根の上部付近に設定する事で、木は地に根を下ろして見えるでしょう。 LWOオブジェクトにテクスチャマップが表示されないTGはLWOオブジェクトのテクスチャ読み込みに未対応です。代用にOBJフォーマットの使用を強く勧めます。 戻る