Public Parts 

The interfaces of a development component (DC) are called its public parts. A public part consists of a list of development objects offered to other DCs. All other parts of the DC remain invisible.

A DC’s inner parts are not visible from the outside. The public part lists a number of development objects intended to be visible for other DCs. A DC can define any number of public parts, each of which must have a unique name. A particular development object can be named in more than one public part. This allows you to organize public parts according to functional view points.

A DC may narrow the dependency to another DC to a certain public part of that DC.

When you declare dependencies, you should select only those public parts that your DC actually uses. If you have to make changes to the used DC at a later time, this helps you to evaluate the effects of the intended changes on other DCs.

In the figure below, DC X is on the same hierarchy level as DC Y: Therefore X is allowed to declare a dependency to Y and to refer to the development objects in the public part of Y.

In addition, DC X declares a dependency to one of the public parts of DC B: This is allowed, because B is a top-level DC. However, B does not see the public parts of the DCs X and Y, because they are enclosed in DC A.

Visibility of public parts. Dependencies of public parts

Child DCs cannot declare dependencies neither to their parent DCs, nor to their public parts.

Inner DCs do not see their parent DC: DC X, Y and Z could never get access to the public part of DC A, neither implicitly nor explicitly.

The parent DC can declare a dependency to one of its child DCs by referring to a public part of the child DC. It can use only the elements contained in the public part of the child DC.

Public parts cannot be used to enhance the visibility of a development object beyond the rules inherent to its technology. For example, a private Java class remains private even if part of a public part. On the other side, a public class remains invisible for other DCs unless it is added to any public part of its DC.

A DC can publish development objects from public parts of a child DC in its own public parts. This process is called propagation of public parts. This is used to make functions of child DCs available to the outside. Without this mechanism, no functions of the child DCs could be used.

A DC can publish a public part of a child as a whole or in parts, by adding the respective development objects to its own public parts. Thus, the DC can reorganize, enhance, or restrict the functions of the child DCs, and combine them with its own functions.

In the following figure, public parts pp (1) A and pp (2) A of DC A are assembled from various sources.

●        Public part pp (1) contains objects from the public part of the inner DC X.

●        Public part pp (2) contains objects from both inner DCs X and Y.

DC B depends on both public parts of A. The public parts of X and Y are invisible to B.

Joined public parts of a parent DC

Purposes of Public Parts

Public parts define the public interfaces of a DC. A public part consists of a list of development objects offered to other DCs. All other parts of the DC remain invisible. A DC uses another DC exclusively using its public parts. There are different types of usage, which are determined when you create the public part:

·         Compilation

Provides an API for developing/compiling other DCs. The objects (symbols, classes, and so on) in the public part of a DC are needed to compile the other DC. In this case, when defining the public part, you assign the purpose compilation to it.

To a public part of type compilation, add only those objects that you want to be visible on the outside, such as interfaces, but never their implementations.

·         Assembly

Can be packaged into other build results (for example Software Development Archives). The objects (symbols, classes, and so on) in the public part of a DC are assembled to a larger unit by the other DC, such as an archive or an application. In this case, when you define the public part, you assign the purpose assembly to it. Public parts of type assembly can also contain some private objects of their DC, for example, the interfaces and their implementation.

You cannot use a public part of this type for the compilation of a DC, and vice versa. However, you can assign two public parts of different types to a DC, which both contain the same development objects.

Make public parts as specific and as small as possible (including the entire content of a DC that is still being changed in a public part increases system load considerably): the automatic rebuild of used DCs is necessary only if in your change you use a public part that refers to the used DC. You can avoid unnecessary rebuilds by publishing objects that can be used by different DCs to different public parts. Every DC can contain several public parts – even of the same type. The same applies to the use: to avoid unnecessary rebuilds make the public parts small and specific. Whenever possible, refer to public parts and not directly to their DCs.

Example

A public part PP of type compilation contains a Java interface api and a factory class factory, which creates instances of api. When compiling the DC, a Java archive named PP.jar is created, which contains the .class files of api and factory, but not the implementation api_impl of the api interface.

Another DC can use this public part and is compiled without any problems, even though the public part does not contain api_impl. At runtime, however, api_impl is required. Therefore, the DC defines a second public part PP1 of type assembly and assigns api, api_impl and factory to it. When compiling the DC, a Java archive named PP1.jar is created, which contains the .class files of api, api_impl and factory. You can now wrap this archive in, for example, a Java EE application and download both of them into a runtime system.