DropにおけるUMLインタフェース表記の解釈について
これは、fj.comp.oopsにてインタフェースの議論がなされた記事の一部です。この中で、まつもとさんより、「DropにおけるインタフェースはJavaのインタフェースにひきずられている」という指摘を受けました。これについては、分析モデルでは言語依存の解説はしていないつもりでしたが、指摘の通り誤解を招く書き方だったので、訂正することにしました。
|まつもと ゆきひろです | ||萩本です。 |||前にも言ったと思うのですが，CORBA, DCOMにおけるinterfaceとJava |||におけるinterfaceとは同じ単語を使ってはいますが，違うも |||のだと考えます．萩本さんの「インタフェース」はそれらを包含す |||る上位の概念なのかもしれませんが，それにしてはDropにおける |||「インタフェース」はJavaのインタフェースにひきずられていると |||思います． || || そうですか。それはどのような点であるかできれば教えてください。 || 本人はできるだけ、そうならないようにしているつもりなのですが.... | |JavaのinterfaceとCORBA, DCOMにおけるinterfaceとを包含するイ |ンタフェースの概念としては，「仕様と実装の分離」というコンテ |キストの「仕様」に該当するものだと推測します．というか，そう |でないインタフェースという概念で双方を包含することを想像でき |ないだけですが． | |となると，これは「仕様」あるいは「signature」を指すものなの |で，オブジェクト指向の文脈では(多重継承を含めた)継承のサブセッ |トのはずです．それであるならば，仕様と実装の分離を否定しない |立場の私からは別になんの不満もないわけです． | |ですが，Dropの資料を読む限りでは，現在の「仕様と実装の両方を |継承する通常の継承」とは別にinterfaceの表記を導入するなど， |「継承とは違う概念であるinterface」という概念を確立しようと |考えておられるような印象を受けます． | |確かにJavaはinterfaceの導入によって仕様と実装の分離をある意 |味強制しているので，その教育的効果はある程度評価するのですが， |interfaceだけを分離したのはJavaの都合なので，そこから押し進 |めて「interfaceという概念が継承とは異なる新しい概念である」 |という印象を多くの人に与えるのは望ましくないと考えます． |# いや，本当に押し進めたのかは私には分かりませんが． なるほど。何度か読み返して、まつもとさんのお考えが少し分かっ たような気がします。 |さて，萩本さんご自身が | |||「superclassもinterfaceもroleである．interfaceはroleに特化し |||ている」という主張なら反対することはなにもないのですが． || || うーんー。「superclassにはroleがある。intafeceはroleである」なら私の主張 ||と同じです。:-) | |と述べておられるので，「interfaceだけがroleである」と考えて |はおられないのだろうとは想像しますが，一方Dropの説明を読む限 |りでは，そう主張していないとは読みとれませんでしたし，この表 |現ではそう誤解してしまう人は出てしまうだろうな，とも思います． | |# 単に私の読解力の不足なら良いのですが． これは、確かに誤解を招く書き方だったかもしれません。Dropの 静的構造モデルのインタフェース解説の注釈部分だけJavaについて してしまっているのが問題なのかもしれません。ご指摘ありがとう ございました。 「superclassにはroleがある」というのが私の考えです。でも、 「superclassはroleである」とは言えないとも考えています。role はsuperclassとなるオブジェクトの一つのviewでしかないと個人的 には思っています。「汎化－特化」のラインには、そのラインの存 在価値が場(field)となり、その場にコンセプトが実在していると 思っています。roleは、もっと局所的なコンセプトを持つのではな いでしょうか？ また、roleしか頭にないとすれば、使いやすいクラスライブラリ などできるはずがないと考えています。役割と「汎化－特化」のバ ランスよい使い分けこそが重要であると思います。その点で、私が 主張を変えないと言ってしまったわけです。 | |Dropの影響かどうかは分かりませんが，少なくとも元のポストの人 |は「roleすなわちinterface」と思われたようですし． Dropでは、interfaceの使い方を２つ示しています。 1.「仕様」と「実装」を分離する。 2.roleとして利用する。 |表記に関して言えば，現実の実装言語が「仕様と実装を同一に継承 |してしまうシステム」を採用しているものばかりである現状では， |interfaceの記法の導入がどれだけ意味があるかはわかりません． Javaのintafaceについて同意見です。動的型結合による言語のrole としてのintafaceよりも意味が拡大したと思います。 とは言っても私が知っているこのような言語は、ObjectiveCのprotocol しかありませんが。 |上述の誤解を生む可能性と天秤にかけると，「私なら」採用しなかっ |たでしょう．せいぜい，「このクラスは仕様だけを記述してるんだ |よ」というマークを導入する程度でしょう，おそらく． 私が言語屋さんなら私もJavaとは異なるやり方をしたと思います。 |||「interfaceはroleである」という主張には賛成するのですが，そ |||れを大々的に主張するあまりに「inheritance(superclass)はrole |||ではない」という主張までが暗黙に成立しているような印象を受け |||ます． || || 上記私の文面の「異なる概念と同じ実現手段がとられてしまいます」という ||問題はあるかもしれません。私は、バランスを考えて、今の私の主張は変え ||たくないと思っています。 | |えーと，私が問題にしているのは「Javaではinterfaceだけがrole |(＝仕様)を表現するものである」あるいは「interface(＝仕様)は |継承とは違う概念である」というような誤解を助長する表現であっ |て，「異なる概念と(に？)同じ実現手段がとられてしまいます」と |いう点ではないと思っています． なるほど、ご指摘の点ははっきり分かりました。たしかに、この 点では誤解をまねいているんだと思います。これをどのように表現 (Dropということになりますが..)するか、少し考えさせてください。 私の中で考えが前進しそうです。ありがとうございました。 |萩本さんが， | || うーんー。「superclassにはroleがある。intafeceはroleである」なら私の主張 ||と同じです。:-) | |と感じておられて， | |||「インタフェース」はJavaのインタフェースにひきずられていると |||思います． || || 本人はできるだけ、そうならないようにしているつもりなのですが.... | |また | || interfaceを言語から独立した概念モデルの世界で、その意味を定義する ||ことも上記と同様に重要だと思います。私は、概念モデルにおけるinterface ||は「has a responsibility」という定義をしており、それに基づいていろんなとこ ||ろで発言しています。 | |と考えておられるなら，interfaceというものを「追加する」より |もむしろまっこうから継承における仕様と実装の分離というテーマ |に取り組むべきではないでしょうか．ちなみにこのテーマに関して |は久野先生は日本における先駆者です．あと，Satherの取り組みも |(かなり極端ですが)参考になるでしょう． はい。いつも久野さんやまつもとさんのfjでの発言は勉強させても らってます。論文などをあさって読んでいないので少々勉強不足を感 じますが、勉強したいと思います。 私は、今の主流言語を睨みながらも、ソフトウェアに依存しない概 念モデルから、実装モデルに、モデルを移し替えるのに適したmethod を追い求めています。インタフェースについても、Dropで大きく取り 上げているものではありませんが、その一つとして考えています。 それで、私の最終目標はいろんな現場で使える方法論ですので、Java などの言語で実装する際に「使える方法論」でなければなりません。 その観点で、問題ある部分は、じゃんじゃん考え方を変えていきた いと思います。 ということで、今回まつもとさんからご指摘いただいた内容を、Java など現在主流のオブジェクト指向言語をターゲットとした方法論として どう改善すべきか？？？ うーん。capacityのない頭が混乱してまいりました。 よい解説・方法などありましたらよろしくお願いします。:-) |||個人的には，Javaの継承のラインを1本に制限し，他の「機能取り |||込み」を違う方法で行うことそのものは見るべきものがあると考え |||ています．が，roleを「インタフェース(しかも，それは継承とは |||違うもの)」でカバーするという考えには賛成しません． || || その視点は、software designにて有用だと思います。 | |あー，すいません．その視点っていうのはどのようなもので，その |視点が有用であるというsoftware designとはなんなんでしょう？ |ちっともわかりませんでした． ゴメンナサイ。software architecture designと書いたつもりでした。 と書いてもはっきりしませんので、要は問題領域がソフトウェアのデ ザイン解決にある場合に有効ですねというつもりで端折って書きました。 まつもとさんのおっしゃるJavaの継承のラインとは別の「機能取り込 み」の重要性、有効性はすごくあると思いますし、それは別にインタフ ェースでなくても可能なものです。Gammaらのデザインパターンで示され ているように！ しかし、このような利用法を、私の書いた下記のインタフェースの利 用法に組み込むとすれば１でもない２でもない１と２の中間というよう に思えます。 ソフトウェア領域の機能を果たすべき役割と考えれば「2.role」であり、 実装の分離にも役立つという点では「1.」だからです。その辺が頭で整 理できていないので、いまのところDropでは明確にしていません。ただ、 概念モデル(ソフトウェアから切り離された)については、「2.role」で しかないと考えています。ということは、roleかな？ だんだん独り言 にようになってしまいました。:-) 1.「仕様」と「実装」を分離する。 2.roleとして利用する。 萩本順三
次は上記の発言に対して、まつもとさんからの発言があったものに対して、さらに私が発言したものです。
萩本です。 | || これは、確かに誤解を招く書き方だったかもしれません。Dropの ||静的構造モデルのインタフェース解説の注釈部分だけJavaについて ||してしまっているのが問題なのかもしれません。ご指摘ありがとう ||ございました。 | |そうですね．このことが気になっていたので，「DropはJavaに特化 |した方法論ではない」と聞いてかなり意外でした．繰り返しになり |ますが，Javaのinterfaceは多重継承のサブセットなので，Java的 |なinterfaceを強調するということはJavaに特化することになると |思います． | |# Javaのinterfaceの「仕様しか記述できない」という制限はとて |# も意味のあることなんですが，それはそれとして． | |そしてJavaに特化せずにinterfaceがどうあるべきかを述べる方法 |論としては「継承における仕様と実装の分離」の問題を十分に検討 |しないと適切な見解は出せないと思います． | |Dropのinterfaceについて述べた部分に意味がないとは申しません |が，ここに関してはJava以外の言語に対して適用することは難しい |ような印象を受けました． | |念のためですがDropで紹介されている考え方については共感できる |ものも多くあります．たとえば，開発プロセスを映画作成にたとえ |るところとか．私も自分の本の中で芝居を演出するたとえを使おう |と思ってたのですが，マネになるので止めました．^^;;; それはまねではないのでは？ 私も、意見を同じくする方法論はたくさんあり、影響もかなり受け ています。DROのProcessをモデル化するインタフェースカードはCRC に影響を受けています。 まつもとさんの芝居を演出するたとえを、読んでみたくなりました。 || 「superclassにはroleがある」というのが私の考えです。でも、 ||「superclassはroleである」とは言えないとも考えています。 | |そりゃそうです．superclassからは仕様(＝role)だけじゃなく実装 |も継承しますから．しかし，JavaとSather以外の静的な型のあるオ |ブジェクト指向言語がすべからく仕様と実装の両方を継承するのは |伊達じゃないと考えています．つまり，いろいろ考えても分離を強 |制するのは結局使いやすくないんじゃないかなあという意見を持っ |てます． | ||役割と「汎化－特化」のバ ||ランスよい使い分けこそが重要であると思います。その点で、私が ||主張を変えないと言ってしまったわけです。 | |ほらほら，ここで「役割」vs「汎化－特化」の対立が顔を出してま |すよ．私の主張ではこれらは対立するものではありません．役割に |だって「汎化－特化」があってしかるべきだと思っています．たと |えば，「工員」という役割と「塗装工」という役割の関係のように． |これらが対立するって思ってしまう点で既にJavaの言語仕様に考え |方が染まっていると思います．それは悪いことではありませんが， |それを自覚せずに一般的な話だと思い込むことは問題だと思います． 自覚しているつもりなんですけどね。 どちらが問題領域にとって主要かということです。たとえばまつも とさんの発言の中で「継承のラインとは別の」という表現があります が、継承のラインとそうでないものの区別をどのようにつけるべきか という説明をなさるとしたら、どのようになさりますか？ 私は問題領域にとって本質的（一番重要な概念）なものに「汎化－ 特化」の関係を付けるという考えです。ここでいう問題領域はソフトウ ェア世界であったり、たとえばビジネスプロセスのようなソフトウェア以 外の世界であったりします。 この考えがないと概念モデルもクラスライブラリもコンセプトが伝 わってこないギクシャクしたものになると思います。 || Dropでは、interfaceの使い方を２つ示しています。 || || 1.「仕様」と「実装」を分離する。 || 2.roleとして利用する。 | |すいません．私の貧弱な理解では実装から分離された「仕様」と |roleというのはほとんどイコールなんですが，これらは捉え方によっ |ては全く違うものとして認識されるんですか？ 「仕様」 ＜＝ 「role」 という考えです。 私はインタフェース継承については、あまり重要視していないでね。 roleが一つ以上集まってクラスの「仕様」となる。これは、オブジェ クト指向において、ソフトウェアに対する要求は、いくつかのオブジェ クトによって果たされる。個々のオブジェクトが果たすべき要求が 「仕様」として現れていると思います。その要求を実現するためには、 いくつかの役割が割り付けられるという考えです。 要求こそが本質的にオブジェクトが果たすべき「仕様」であり、それ にはいくつかの役割が伴うという考えです。 |||表記に関して言えば，現実の実装言語が「仕様と実装を同一に継承 |||してしまうシステム」を採用しているものばかりである現状では， |||interfaceの記法の導入がどれだけ意味があるかはわかりません． || || Javaのintafaceについて同意見です。動的型結合による言語のrole ||としてのintafaceよりも意味が拡大したと思います。 | |うーん，同意見と言われても困るんですが．というのも元の発言の |「表記」とは萩本さんがDropで導入された記法のことですから． それは、とんでもない勘違いをしてました。私はJavaのintaface について問題意識があったもので。 ちなみにご存じだとは思いますが、あの記法はUMLです。それで、 その解釈についてはDrop独自のものです。 |更に言えば「動的型結合による言語のroleとしてのintafaceよりも |意味が拡大した」という表現の意味するところがさっぱり分かりま |せん． | |「動的型結合」とは？ 「動的結合」のこと？ それとも「動的型」 |のこと？ 後者だと仮定すると，そのような言語は普通は暗黙のプ |ロトコルによってroleを表現していますが(というか暗黙だから表 |現はしていないんだけど)，そのroleがinterfaceによって明示化さ |れたことを言ってるんですかね．でも，それなら「静的型」に付随 |する特徴で，interfaceに限らないことなんだけど． | |# 一所懸命推測しても間違ってそうだな． 「動的型結合」って一般的な用語ではなかったんですね。:-) 以前に、ある方の論文を見てよい表現だと思いそのまま今まで使っ ていました。「静的な型を持たない言語」のことです。 私が以前仕事で使っていたObjectiveCもそのような言語でした。 (静的な型も併せ持つ言語ではありましたが..) ObjectiveCにはprotocolというものがあり、それを使うとコンパイ ル時に型を解決することもできました。protocolの使い方は、実行 時に型を決める言語環境の中で、明示的なプロトコルによってrole を表現するもので、ダイナミックな環境の中でroleの部分だけを明 確に定めることができていました。きっと論点がズレていたのかも しれません。 | || 私は、今の主流言語を睨みながらも、ソフトウェアに依存しない概 ||念モデルから、実装モデルに、モデルを移し替えるのに適したmethod ||を追い求めています。インタフェースについても、Dropで大きく取り ||上げているものではありませんが、その一つとして考えています。 | |現在Dropで取り上げているレベルのインタフェースなどは実装言語 |に依存する領域だと思います．たとえばSmalltalkでは登場しよう |がないですよね．実装レベルではどうしても実装言語に左右される |ものだと思います．ですから，その部分はJava用です，と割り切っ |てよろしいんじゃないでしょうか．今私が問題にしているのは一般 |論の中にJava固有の考え方が混ざっていることですから． 私はそうは思えません。たとえばSmalltalk VisualWorksにおける メソッドカテゴリの決定は、概念モデルを作り出す際にそのオブジェ クトの果たすべき役割をroleとして束ね、それをクラスライブラリの 中の約束事として、カテゴリに置き換えるのという思考プロセスが 伴うのではないでしょうか？（あくまで憶測ですが..） だから役割のモデル化についての表記は必要だと思います。Drop図 の(A),(B),(C)のことです。でも、(D)のような表記は必要ないです。 あのインタフェース表記の部分の主たる目的は、モデル表記の使い 分けとして「What」と「How」を分けたかったのです。私の考えでは roleに着目するのは「What」です。仕様と実装を分離することは、そ のような仕組みを考慮した時点で「How」になり、クラス関係とクラス 内部構造に視点が移ります。 |それとは別に概念モデル(っていうんですか)のレベルでroleの果た |す意味と言うものもあるのではないかと推測します(あることを確 |信しているわけではないですが)．たとえば設計の方針としての． |で，そういうものを語るには，まず萩本さんが「仕様と設計の分離 |とは」とか「オブジェクト指向プログラミングにおける静的な型と |は」などのテーマについてもっともっと堀り下げる必要があるので |はないかと思っています．余計なお世話でしょうが． | いえいえい、貴重なご意見ありがとうございます。 昨日、投稿した「伽藍モデルとバザールモデル」の翻訳されたURL を載せるのを忘れていました。 伽藍とバザール (The Cathedral and the Bazarの日本語訳) http://www.post1.com/home/hiyori13/freeware/cathedral.html 昨日も平野さんとDropについて議論していたのですが、Dropは バザール方式のようなアプローチで作成していながらも、なぜDrop の提供する開発サイクルは伽藍モデルなのか？といわれてしまい ました。未完成なDropについて、みなさんと議論していると、なにを なすべきかうっすらわかってくるようです。 といことで、インタフェースについての議論をDropの目次ページの Discussionに追加してよりしいでしょうか＞まつもとさん。
