Finally! The Real Simple Guide To Understanding Interfaces

Understanding Interfaces can be challenging for many beginning programmers. Here’s a super simple guide to understanding them.

The classic explanation is that “an Interface is a contract”. This is what the people interviewing you for a job expect to hear. But what does “an interface = a contract” mean?

Well, first off, we know that Interfaces contain a special format of code that does not perform any tasks itself, that is, an Interface may have method signatures (the beginning part of a method), but all the code functionality is missing! The actual method code is contained in the class which only implements (the Interface version of inheritance) the interface.

// The Interface// Notice that the interface only has a method signature. The method has no body.

public interface IExampleInterface{// return type, method name, required parameter types and namesvoid Method1(string parameter1, string parameter2);}

Interfaces can also contain properties and events, in addition to method signatures.

// The Class// Implement the inteface by having the class "inherit" it.

public class MyExampleClass : IExampleInterface{public void Method1(string parameter1, string parameter2){// do something}}

// Notice that the method signature here is exactly the same as the one in the interface.

When a class implements a specific Interface, the class promises to follow the specific rules and regulation defined in that special code contained in the Interface. In our example, our Interface contains several method signatures. When our class implements the Interface, it promises to at the very minimum contain methods that match those method signatures exactly. The Interface doesn’t care about the code inside the method, it just requires that, just like I have { X } number of method signatures (or properties), the implementing class has the same exact number (at the very minimum) and that they match exactly.

A good example of how this contract works would be to look at how a franchised business works. Many people patronize specific companies due to “brand recognition”. Think of a large, chain, business near you. Let’s use Starbucks, for example. Starbucks is well known and has established itself as a trustworthy coffee shop where you are guaranteed to receive a certain level of service and product. Now, if you wanted to open a coffee shop as a small business, would you choose to open an independent coffee shop or would you pay a franchising fee to Starbucks to use their logo and marketing, as well as having to follow their corporate rules and regulations? Well, while an indie coffee shop provides more flexibility, customers may be less willing to patronize your indie shop since the service and product you provide is of an unknown quality and is also subject to change at any time without warning. A franchised Starbucks location on the other hand, is a known quantity due to your “contract” with the Starbucks corporation. Everyone knows what they’re getting, there are clearly laid out policies for everything including returns, refunds, and other customer satisfaction issues. Starbucks did a lot of the early, difficult, work of creating a brand that customers recognize and trust, you just must follow their corporate rules in order to benefit from that hard work.

In our case, the small business owner would be comparable to the class and the Starbucks corporation would be the Interface. The “contract” (that your interviewer is expecting you to mention) is the contract that you, as a business owner, sign with the corporation (Starbucks/the Interface) in order to benefit from using their work. Our Interfaces have a set of rules that we must follow, and this, in both business and software development, keeps things nice, tidy, organized, and predictable.