了解 API 引用
规范、实现和实例
<API 引用中包含抽象的 API 规范。API 引用的服务说明不是关于已经存在于某处的类。首先有了规范，然后按照规范创建 UNO 实现。甚至对 UNO 必须采用的传统实现也是如此。
而且，由于组件开发者可以根据需要自由地实现服务和接口，因而某个特定服务规范与一个真实对
象之间不一定要有一对一的关系。真实对象具有的功能可以比服务定义中指定的功能多。例如，如果您在工厂订购了一项服务，或从一个 getter（获取对象内部值一类的方法） 或 getPropertyValue() 方法接收一个对象，指定的功能就会出现，但还可以有其他功能。例如，文本文档模型中有几个接口未包括在 com.sun.star.text.TextDocument 规范中。
由于存在可选的接口和属性，因而不可能通过 API 引用完全理解 OpenOffice.org 中某个对象的给定实例具有什么功能。可选接口和属性对于一个抽象规范来说是恰当的，但它意味着当您离开必需的接口和属性的范围时，引用仅定义允许事物如何工作，而不是它们实际如何工作。
另一点重要的是存在对象实现实际可用的若干入口点。无法通过全局服务管理器实例化 API 引用中存在的每项旧式服务。原因如下：
- 有些旧式服务需要特定的环境。例如，独立于一个现有的文本文档或其他任何有用的环境来实例化 com.sun.star.text.TextFrame 是没有意义的。这样的服务通常不是由全局服务管理器建立，而是由文档工厂建立，这些文档工厂具有建立在某种具体环境中工作的对象所必需的知识。这并不意味着永远无法从要插入的全局服务管理器中获取文字框。因此，如果您希望在 API 引用中使用某项服务，就要自问从哪里获取一个支持此服务的实例，并考虑要使用此服务的环境。如果环境是文档，则文档工厂即可创建该对象。
- 旧式服务不仅仅用于指定可能的类实现。有时用来指定可由其他旧式服务引用的若干组属性。也就是说，有些服务根本没有接口。无法在服务管理器中创建此类服务。
- 少数旧式服务需要特殊对待。例如，不能让服务管理器创建 com.sun.star.text.TextDocument 的实例。必须使用桌面的 com.sun.star.frame.XComponentLoader 接口中的
loadComponentFromUrl()方法来加载它。
在上面的第一种和最后一种情况中，使用多继承接口类型而不使用旧式服务将是最佳的设计选择，但是提到的服务在 UNO 中多继承接口类型之前即可用。
因此，有时在 API 引用中查找一个需要的功能非常麻烦，因为在实际使用引用之前，需要基本了解功能的工作原理、包含哪些服务、可以从何处获得服务等。本指南的目的在于让您了解 OpenOffice.org 文档模型、数据库集成以及 OpenOffice.org 应用程序本身。
对象复合
接口支持单继承和多继承，而且它们都基于 com.sun.star.uno.XInterface。在 API 引用中，任何接口规范的基本层次结构区域中反映了这一点。如果您查找一个接口，通常需要检查基本层次结构区域，了解各种支持的方法。例如，如果查找 com.sun.star.text.XText，您会看到两个方法insertTextContent() 和 removeTextContent()，但是，继承的接口提供了另外九个方法。同一情况也适用于异常，有时还适用于结构，它们也支持单继承。
API 引用中的服务规范可以包含一个区域，即包含的服务，此区域与上一个区域类似，一项包含的旧式服务可能包括全部服务。但是，包含一项服务这一事实与类继承没有关系。根本没有定义服务实现通过什么方式从技术上包含其他服务（对于 UNO 接口继承也是如此），比如说，通过从基本实现继承，通过聚合，通过其他形式的授权，或只是通过重新实现所有内容。而且，这对于一个 API
用户来说没有什么意义，因为，该用户可以依赖于说明功能的可用性，但永远无需依赖于实现的内
部细节，例如，哪些类提供此功能、这些类从何处继承以及它们将什么内容授权给其他类。
| Content on this page is licensed under the Public Documentation License (PDL). |
