Need words to resolve the ambiguity of "interface" in OOP. It can mean either a type defined with the keyword "interface" or an object's accessibility

Question

In some object-oriented programming languages, the keyword interface is used for declaring a type that defines how objects that implement (another keyword) it may accept messages (calls) from other objects. These types declared with the keyword interface end up being called interfaces themselves.

However, some objects do not implement an interface but also accept messages (again, calls) from other objects. This is defined simply by what the object makes publicly visible. This is also commonly called the object’s interface, even though there is no separately defined type for it.

Using the same term for two distinct but related concepts makes writing about them difficult. I have seen explicit interface used to mean the first kind. However, in C♯ this term has a different meaning than what I’m discussing here: there it means package disambiguation.

I need two different terms for these so that I can separately refer to these two distinct concepts in a way that always makes clear which of the two senses I mean, and I need this pair of terms to work for every object-oriented programming language that exists.

A little background for clarity

When Java, and later C♯, decided to create a type that did not allow implementation code to exist in it but only defined a set of accessible methods (a protocol) they decided on interface as the keyword for this. This meant people would come to refer to these types as interfaces.

However, the word interface already had another meaning. It meant whatever was accessible by virtue of not being hidden by access modifiers like private. It still also means this, but when people use the word interface now, it has become hard to know which of the two senses they mean.

Other languages like C++ have no keyword for this and just call such creations header files. Thus a C++ programmer can freely talk about header files and interfaces with no ambiguity resulting.

Answer 1

I use API to describe an object's set of public methods, and interface to mean a programming contract defined with the keyword interface. I only use API to talk about object design when there is no chance of confusion with the API provided by a remote application.

API does mean "application programming interface", so the only benefit of the acronym is to signify a class's public methods rather than any interfaces it may implement.

If I must talk about a remote API and describe how my app connects to it, then I'll use interface for my code and API for the remote code that I have no control over, as in: "this HTTPRequest object provides an interface to make API calls."