I use the term «meta»-Interface to describe an Interface that serves only to declare the service Interfaces that form the purely port-based contract. The only operations of a «meta»-Interface are called Service Accessors. It is related to what I call The Golden Service Rule of port-based software engineering:
A truly port-based Class should only ever offer services via Ports as Operations of Interfaces, it should NEVER offer services directly.
(There is a loophole, namely that «friend» Classes may need direct access to public methods not in the public «meta»-Interface.)
Implementations of the «meta»-Interface can choose to create "port implementors" of the promised Interfaces by:
- creating them on construction (not very efficient or flexible, however sometimes necessary to prevent latency on later access)
- lazy instantiation: create them on-the-fly as and when needed (and never before being accessed, thus saving resources)
- lazy instantiation combined with Factory-based Dependency Injection: very flexible and efficient.
There is a corresponding Golden Client Rule of port-based software engineering:
Clients should only ever access services of truly port-based Classes via the Service Accessor Operations of a Meta-Interface.
In Java, including some dependency injection using a factory, it looks like this:
HumanPortFactory f = new SimulatedHumanPortFactory_(); // could of course be specified outside the application as XML Human h = new SmartHuman_(f); // The Port implementors will be obtained from an injected factory. h.cook().stir(); // will trigger creation of a Port that provides the grouped Cook service
You can now pass exactly the interfaces as needed to the relevant clients, like this:
Teacher t = new Teacher_(h.learn());
The teacher client does not know - and need never know - what Port implementation was used to provide Learn, or even who provided the service. Nor does the teacher client ever have to deal with Interfaces like Cook that have nothing to do with the required Learn service.
