From Packages to Structure Packages

- Why are the usual concepts of packages and main packages no longer enough?

In large software projects, you generally have a large number of main packages.You must always define the use conditions between each main package explicitly, which can mean a lot of organizational work.

Structure packages can reduce the organizational effort necessary

As containers for main packages, structure packages can contribute substantially to reducing this effort. "Use" accesses can then be defined at the structure package level. Structure packages allow to reduce the number of use accesses needed between the client and server packages.

The particular significance of filters in structure packages can be explained using an example:

Let us assume that the two packages, APPL and HR, are normal packages or main packages, not structure packages. Now let us consider the object O1 in APPL, which is contained in the encapsulated package P1 and which is to be used by the object O2 from another package P2 (see graphic). P2 is also a component of APPL. First, you make the object O1 visible externally by adding it to the interface I1. This allows the user package P2 to create a use access to the interface I1 of P1. In this case, however, the object O1 is also visible to the package P3, so that it is not protected from accesses from P3. However, the package P3, belongs to HR. Objects from HR should not be allowed to use APPL objects, assuming that we want to ensure decoupling.

Additional possibilities offered by filter interfacesThis is exactly where structure packages come into play: they allow you to filter out visible objects from other structure packages. The use of objects that belong to different structure packages needs to be explained at the structure package level first.