Interfaces Are Abstractions

Photo by Charles Deluvio on Unsplash

Previously, we discovered the opposite nature of Abstraction and Encapsulation—we can’t have one without the other. Today we’ll continue with the concept of Abstraction and how it relates to Interfaces:

All Interfaces are Abstractions

Interfaces are simplifications. They hide complexity. Whether it’s a User Interface (UI) or an Object-Oriented (OO) interface in code—interfaces represent What a system does, not How it does it. 

Let’s check out an OO interface example. Below is the declaration for ICustomerRepository: 

  public interface ICustomerRepository
  {
     Customer GetCustomer(string emailAddress);
     void SaveCustomer(Customer customer);
  }

ICustomerRepository stipulates two behaviours: 

1. Callers can get a customer by email address, and 
2. Callers may also save a customer. 

That’s all ICustomerRepository does—What it does. Implementers of the interface are free to choose How they fulfil these two functions. 

ICustomerRepository is an abstraction.

Fair enough. What about UI? Is that an abstraction too? 

Think of the interface for your favourite mobile banking app. You can transfer money between your accounts, make payments, and so on. Just think how easy your bank has made it to transfer dosh between your accounts: 

1. Select a source account
2. Select a destination account
3. Set the amount of money to transfer
4. Click OK.

As long as there are no problems (e.g. insufficient funds), the app will transfer the transaction amount. Simple. Or is it?

This seemingly straightforward process hides a massive amount of complexity—the bank’s software systems required to safely and securely transfer money between accounts are immense. Ensuring the transfer of funds either fails or succeeds in its entirety—and does not inadvertently create or delete digital cash—is quite involved by itself.

For laughs, let’s imagine the bank presented customers with a different interface—a SQL command-line directly into the bank’s central database. Customers wanting to transfer funds between accounts would be required to write and execute several SQL statements—correctly and in the proper order. They would need to know how to transfer funds. This hypothetical interface would not be suitable for bank customers or the bank. 

It would be too complicated for the vast majority of the bank’s customers. The situation would be even worse for the bank: By granting privileged, raw access to the banking database, at best, customers would make plenty of errors while working with their funds, and at worst, unscrupulous individuals would make or take digital money that wasn’t theirs!

Yeah, that’s not going to work. There are good reasons why we want to ‘abstract away‘ complexity using interfaces.

So, please remember that Interfaces are Abstractions.