<このシリーズの、前の記事 | このシリーズの目次 | このシリーズの、次の記事>
「UNO旧スタイルサービス」と呼ばれるものがあるが、しかし . . .
歴史的な複雑な事情のため、参考文書内の「UNOサービス」という用語の使用法にはねじれがある . . .
それはよくない。用語の使用法のねじれは、理解のねじれにつながる可能性が極めて高い。
そう。我々の意図は、我々の説明から用語の使用法のねじれを取り除くことだ。
えー、「UNO旧スタイルサービス」と呼ばれるものがあるが、これらは、我々が先の記事で論じたようなUNOサービスではない。
それでは、それらは何なのか？
「UNO旧スタイルサービス」は、私が思うには、複数のインターフェースおよびプロパティを格納できる「インターフェースおよびプロパティのコンテナ」と呼ぶべきものだ。
ふーむ。
UNOの古い仕様では、1つのUNOインターフェースが複数のUNOインターフェースを継承することができなかったので、複数UNOインターフェースからの継承を実現するために、「UNO旧スタイルサービス」が使われた。
なぜ、「サービス」などという用語が与えられたのか？
「UNO旧スタイルサービス」の典型的な使い方においては、UNOコンポーネントは、「UNO旧スタイルサービス」を直接実装し、「UNO旧スタイルサービス」の名称をサービス名として使用して、UNOサービスとして登録される。そこで、「UNO旧スタイルサービス」とUNOサービスが同一視された。
ふーむ、UNOサービスを登録するために「UNO旧スタイルサービス」が使われたとしても、UNOコンポーネントによって実装されるものとしての「UNO旧スタイルサービス」は、UNOサービスではなく、一種のインターフェースだ。. . . それに、それはただ典型的なケースにすぎないのだろう？
そう。別のケースでは、「UNO旧スタイルサービス」は、UNOコンポーネントの継承−実装階層構造の中間階層で、複数のUNOインターフェースをまとめるために使われる。この「UNO旧スタイルサービス」をサービスと呼んでしまうと、我々の用語でいうところのUNOサービスという概念がぐちゃぐちゃになってしまう。
また、Javaの観点からすると、それは幻だということも注意しておこう。
「幻」というのはどういう意味か？
「UNO旧スタイルサービス」は、Javaの何にもマッピングされない。
はあ？ただ「何にもマッピングされない」と言って済むものなのか？「UNO旧スタイルサービス」を継承−実装階層構造中に持つUNOコンポーネントを扱う場合、一体どうしろというのか？
実のところ、問題は全然ない。例えば、インターフェース、InterfaceAおよびInterfaceB、を格納した「UNO旧スタイルサービス」、OldStyleServiceA、があり、この「UNO旧スタイルサービス」、OldStyleServiceA、とインターフェース、InterfaceC、を格納した「UNO旧スタイルサービス」、OldStyleServiceB、があり、UNOコンポーネント、ComponentA、がOldStyleServiceBを実装するとする。
「UNO旧スタイルサービス」は、別の複数の「UNO旧スタイルサービス」を格納できるということか？
そう。この場合、重要なのは、ComponentAが InterfaceA、InterfaceB、InterfaceCを実装するということだけだ。
ふむ？. . . ふむ。それでは、OldStyleServiceAにアクセスする機会はまったくないということか？
そのような機会はまったくない。Javaの観点からは、OldStyleServiceA存在しない。
それでは、Javaの観点からすると、「UNO旧スタイルサービス」は、あるUNOコンポーネントがどんなインターフェースを実装しているかを知るための単なる文書としてしか存在しないということになる。
そう。そう理解すると、「UNO旧スタイルサービス」が何なのかということが、Javaプログラマーにとってはっきりする。
しかし、「UNO旧スタイルサービス」に格納されているプロパティ群はどうなるのか？
「UNO旧スタイルサービス」に格納されているプロパティは、UNOコンポーネントが 'XPropertySet'といったある種のインターフェースを実装し、そのプロパティを処理するコードを含むという事実に反映される。
すると、その場合にも、「UNO旧スタイルサービス」は、UNOコンポーネントがどのように実装されているかを知るための文書としてのみ存在するわけだ。
「UNO新スタイルサービス」と呼ばれるものもあるが、しかし . . .
予想できるかもしれないが、「UNO新スタイルサービス」と呼ばれるものもある。「UNO新スタイルサービス」というのは、一つだけのUNOインターフェースを実装するUNOコンポーネントのUNOサービスのことを指すと思われる。しかし、Javaの観点からすると、この区別は、あまり重要性を持たない。
ああ、Javaクラスにとって、複数インターフェースを実装することは全然特別ではないので、実装されるインターフェースの数は、Javaプログラマーにとって特に関心のあることではない。
参考文書は、「UNO新スタイルサービスコンストラクタ」は「UNO新スタイルサービス」に対してのみ作れると主張しているが、これは正しくない。複数のUNOインターフェースを実装するUNOコンポーネントのUNOサービスに対しても、それらを作ることができる。それは、将来の記事で実証しよう。
我々はJavaの観点からのみ物事を見ているので。我々の知らない意図もあるのかもしれない。しかし、少なくともメカニズム上、「UNO新スタイルサービス」であることが特別なことであるとする何物も存在しない。
また、注意しておくが、先のサンプルUNO拡張機能におけるUNOサービスは、「UNO新スタイルサービス」であるが、その実装クラスは、実際には、3つのUNOインターフェース、'XHiUnoExtensions'、'XServiceInfo'、'XInitialization'を実装している。'XServiceInfo'と'XInitialization'は、勘定に入っていないが、これは、これらが、UNOサービスのユーザーが直接使用するものと想定されていないからだと思われる。しかし、メカニズムから見れば、「UNO新スタイルサービス」は、特に、一つだけのUNOインターフェースを実装するUNOコンポーネントのUNOサービスではない。
ははあ。
- Apache OpenOffice Wiki. (2014/01/02). Apache OpenOffice Developer's Guide. Retrieved from https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide
