Leo Brodie's "Interface Component"

Question

On page 85 of Leo Brodie's book, Thinking Forth, he describes a component which he calls the "Interface Component." He describes its differences from, and benefits over a standard interface as follows:

When it comes to data interfaces between modules, traditional wisdom says only that “interfaces should be carefully designed, with a minimum of complexity.” The reason for the care, of course, is that each module must implement its own end of the interface (Figure 3.8).

This means the presence of redundant code. As we’ve seen, redundant code brings at least two problems: bulky code and poor maintainability. A change to the interface of one module will affect the interface of the opposite module.

He goes on to introduce the concept of the Interface Component:

There’s more to good interface design than that. Allow me to introduce a design element which I call the “interface component.” The purpose an interface component is to implement, and hide information about, the data interface between two or more other components (Figure 3.9).

Is this pattern applicable when programming in Java? Interfaces in Java are similar to those depicted in Figure 3.8 above. If an interface component object were to be introduced, wouldn't it, along with the two other objects all need to adhere to the Interface defined? I do not see what benefits the interface component would provide.

Any thoughts?

Answer 1

Rule #1 when reading any programming or computer science text: "interface" never refers to the Java interface construct. (Rule #1b: except when the text is specifically about the Java language. And even then, it's not guaranteed.)

In this particular case, it sounds like "interface" is used in the generic computer science sense of information hiding, data abstraction and modularity, i.e. the distinction between private hidden internal implementation details and a public way to use the module, aka its interface.

What the text is saying, is that even if you have two fully encapsulated modules, the way that those two modules agree to interact with each other (i.e. the interface they present to each other), still couples them together, and even worse, changing the way they interact with each other requires changes to both modules. IOW, the knowledge about how to interact with each other is spread across the two modules.

The way to counter this, is to extract a third module which manages the interaction between the two modules.

The "design elements" Brodie talks about, would probably be called Design Patterns in more modern/mainstream parlance, and there are in fact two Design Patterns in the GoF book that roughly meet Brodie's description:

• The Bridge Pattern: decouples an abstraction from its implementation, if you are familiar with C++, this is a generalization of the PIMPL idiom.
• The Mediator Pattern: encapsulates the way a set of objects interact into a separate object, you may call it a "re-ification of the interaction", if you will.