What is an Interface?
IT DEPENDS hahaha, end of post, *bows* thank you for reading!
…
Ok sorry for that. It depends is still accurate though, unfortunately. Let’s check out why.
Syntax Interfaces
In various programming languages (mostly OOP-focused), the developers have thoughtfully created these features of the language called ‘interfaces’ which typically define public properties and even methods of a class that are required at compile time.
What does this mean? And why?
It means that if you claim in the program that an output from a function, or even a class itself will be an instance of a thing that thing can be an interface. The interface must have those properties and methods to be successfully compiled, and this is an architecture strategy to make it very obvious to the developer what data must migrate between contexts. This builds a contract between all the entities using that interface that those properties and methods must be there.
The why is pretty straightforward as well, it’s all about being able to build these contracts between systems, and for developers to be able to understand those contracts quickly. An immense amount of time can be wasted in the feature development process not properly understanding how two pieces of code should actually interact, or even worse, trying to understand any side-effects that are unwanted.
These interfaces help to reduce the time til understanding, as well as unwanted side-effects.
Communication Interfaces
A communication interface can include the syntax interface from above, but it’s a bit more abstract. It’s the I in API, and is typically done via some communication protocol. Sometimes this interface has clearly defined methods and properties and will take care of you when you ask for things you shouldn’t. Other times you may be in a riskier situation where when you get a response back it’s an error and you need to handle that on your own because the interface is closer to the communication layer, and relies on a lot of its default behaviors to function like expected.
I don’t have a lot more to say about this meaning here, other than it’s vastly complicated, and introducing communication layers into projects is very often a requirement, and is also one of the more complex parts of the project to manage usually. So tread carefully!
Abstract Interfaces
This is the part I’ve been waiting for. The Abstract meaning of interface is really what I’m usually talking about when I use this term, as it’s broad enough to encapsulate what needs to be covered in a discussion, but it’s specific enough to be defining ‘the point where two features need to exchange information that was up until that point relevant only in their own isolated contexts’.
Typically two bits of the program only need to interface if the context from one area, is needed in the other. Otherwise, there isn’t much reason to have them touch, to begin with, which is ideal because that introduces the bulk of complexity that happens in a program.
Simplified:
When talking about where two sections of the program need to exchange variables or other context with other sections of the program, even if there is no formal structure called an interface, I always tend to call this interfacing or interfaces.
Context Exchange?
let’s assume we have two classes, one called iceCreamCone, and another called iceCreamDispenser.
The dispenser of ice cream will have information and context that is relevant to the machine that creates and produces the ice cream.
The ice cream cone will have contextual information about the specific ice cream cone that exists and is ready to receive, then hold and contain information about the specific ice cream.
It’s a requirement that we be able to exchange information between these two items. The ability for the dispenser to be able to be ‘told’ about the level of the ice cream that is in the cone, for example, is some critical information if we don’t want ice cream going into the floor as it’s filling. OR to be sure that enough ice cream goes in to be sure the person filling the cone is satisfied.
So context per entity really just represents the abstract concept of the realm of information that an area in the code is supposed to be able to access and update.
Conclusion
An interface can technically be a lot of things, but it pretty much always represents a concept that defines the relationship of contextual exchange between at least two places in the program.
And when specifically I use the term interface, I’m usually using it in the abstract way where I’m just trying to discuss the way that the flow of context between two places in the program is defined.
