Documentation/DevGuide/FirstSteps/Using Services

<maintab>First Steps||Programming||Applications||Get Started||Get Objects||Work with Objects||Types||Example</maintab> <subtab>Objects, Interfaces, and Services||Using Services||Example Spreadsheet||Types||Struct||Any||Sequence||Elements</subtab> The concepts of interfaces and services were introduced for the following reasons:

Interfaces and services separate specification from implementation

The specification of an interface or service is abstract, that is, it does not define how objects supporting a certain functionality do this internally. Through the abstract specification of the [PRODUCTNAME] API, it is possible to pull the implementation out from under the API and install a different implementation if required.

Service names allow to create instances by specification name, not by class names

In Java or C++ you use the new operator to create a class instance. This approach is restricted: the class you get is hard-coded. You cannot later on exchange it by another class without editing the code. The concept of services solves this. The central object factory in [PRODUCTNAME], the global service manager, is asked to create an object that can be used for a certain purpose without defining its internal implementation. This is possible, because a service can be ordered from the factory by its service name and the factory decides which service implementation it returns. Which implementation you get makes no difference, you only use the well-defined interface of the service.

Multiple-inheritance interfaces make fine-grained interfaces manageable

Abstract interfaces are more reusable if they are fine-grained, i.e., if they are small and describe only one aspect of an object, not several aspects. But then you need many of them to describe a useful object. Multiple-inheritance interfaces allow to have fine-grained interfaces on the one hand and to manage them easily by forging them into a collection. Since it is quite probable that objects in an office environment will share many aspects, this fine granularity allows the interfaces to be reused and thus to get objects that behave consistently. For instance, it was possible to realize a unified way to handle text, no matter if you are dealing with body text, text frames, header or footer text, footnotes, table cells or text in drawing shapes. It was not necessary to define separate interfaces for all of these purposes.

Let us consider the old-style service [IDL:com.sun.star.text.TextDocument] in UML notation. The UML chart shown in Illustration 1.2 depicts the mandatory interfaces of a TextDocument service. These interfaces express the basic aspects of a text document in [PRODUCTNAME]. It contains text, it is searchable and refreshable. It is a model with URL and controller, and it is modifiable, printable and storable. The UML chart shows how this is specified in the API.

Illustration 1.2: Text Document

On the left of Illustration 1.2, the services [IDL:com.sun.star.text.TextDocument] and [IDL:com.sun.star.document.OfficeDocument] are shown. Every TextDocument must include these services by definition. On the right of Illustration 1.2, you find the interfaces, that the services must export. Their method compartments list the methods contained in the various interfaces. In the [PRODUCTNAME] API, all interface names have to start with an X to be distinguishable from the names of other entities. Every TextDocument object must support three interfaces: XTextDocument, XSearchable, and XRefreshable. In addition, because a TextDocument is always an OfficeDocument, it must also support the interfaces XPrintable, XStorable, XModifiable and XModel. The methods contained in these interfaces cover these aspects: printing, storing, modification and model handling. Note that the interfaces shown in Illustration 2.2 are only the mandatory interfaces of a TextDocument. A TextDocument has optional properties and interfaces, among them the properties CharacterCount, ParagraphCount and WordCount and the XPropertySet interface which must be supported if properties are present at all. The current implementation of the TextDocument service in [PRODUCTNAME] does not only support these interfaces, but all optional interfaces as well. The usage of a TextDocument is described thoroughly in [CHAPTER:Text].