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.

Figure 3.8

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).

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?

  • Actually, they're not so much similar. There's no "buffer" in the interface: just the "handshake" and the type(s) associated with that handshake. An interface in Java is just a service contract.
    – CPerkins
    Commented Aug 4, 2016 at 15:10
  • Right. An interface in Java only specifies what methods must be implemented and what data types those methods can accept and return. Does the need for this type of interface appear due to the fact that Forth is untyped?
    – dmux
    Commented Aug 4, 2016 at 15:36
  • 3
    If it's only about data, it's isomorphic to the Bridge Pattern. If it also orchestrates interaction, it's more like the Mediator Pattern. At least that's what I understood from the quotes you posted, I'm not familiar with Thinking Forth. (One of much too many books on my reading list.) Commented Aug 4, 2016 at 15:45
  • @JörgWMittag, thanks for the links. After reading about the two design patterns I'd gladly accept them as the answer if you'd like to post it.
    – dmux
    Commented Aug 4, 2016 at 17:12

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.