What does it mean when we say, “X implements Y”?

For a research project I’m working on, we were looking for a scholarly definition of the term “implements”. You know, as in, this method implements that interface.

As programmers and data modelers, we all know what that word means. We tried to define it in a paper though, and ran into a constant stream of problems with whatever definition we proposed.

“This is crazy”, we thought to ourselves, “there’s got to be a good definition out there”. How could it be that such a fundamental concept behind object-oriented programming is undefined? Try Google if you like, what you’ll pull up is the definition of what “implements” means in terms of the java programming language. You’ll get tutorials on OOP. What you won’t get is a formal definition of what this crazy thing is.

So we dug deeper. Maybe the literature doesn’t talk about it that way. What term would they use, we wondered? After some more research, we found “behavioral subtyping”. Sure enough, they’re coming at it from a different angle, but basically “behavioral subtyping” is what we’re trying to establish when we say that X implements Y.

So there’s got to be a good definition of behavioral subtyping, right? Well…no.

Remarkably, there is no mathematically rigorous account of behavioral subtyping and its connection with modular reasoning about specifications and programs in conventional OO programming languages – although there has been much study [1, 2, 3, 11, 14, 15, 19, 22, 29, 30, 47] (see [21] for a survey). Some of the current understanding of behavioral subtyping is embodied in program logics [31, 40, 42, 43, 46] but is difficult to disentangle from various other complications.

Cite: Behavioral Subtyping, Specification Inheritance, and Modular Reasoning (2006).

Programmers informally reason about object-oriented programs by using subtype relationships to classify the behavior of objects of different types and by letting supertypes stand for all their subtypes. We describe formal specification and verification techniques for such programs that mimic these informal ideas.

Cite: “Reasoning About Object-Oriented Programs That Use Subtypes” (1990)

So it turns out, that the concept of “this implements that” is so fuzzy and loose, that we don’t actually have a good definition of exactly what it is. As a result, the academic work in this area seems more geared towards building models to reason about programs with these relationships – but crucially, the models approximate but do not duplicate what it actually means.