Interfaces Are For Clients
Interfaces connect. Graphical user interfaces (GUIs) allow humans to operate computers intuitively.
It doesn’t have to be this way. Humans can also control computers by sending them textual requests via a command-line. We are still above the native computing level of 1s and 0s. But a command-line interface, compared to a GUI, is a step closer to how a computer operates under the hood.
We want the human to succeed in operating a computer. Therefore we shape the computer’s operating interface to suit humans. We design user interfaces for the user—the client.
The same principle applies to programmatic interfaces. They also exist for whoever is consuming them.
Let’s look at an example.
A business logic workflow requires looking up customers by customer number from a persistence medium, say, a SQL database. Being smart developers, we create an interface, ICustomerDataSource
, to represent the database behaviour rather than use the SqlCustomerDataSource
class directly:
public interface ICustomerDataSource
{
Customer GetCustomer(CustomerNumber customerNumber);
}
SqlCustomerDataSource
would implement ICustomerDataSource
.
However, the Object Relational Mapper (ORM) tool we’re using for data access creates an entirely different method signature for retrieving a customer by customer number from the SQL database:
public Customer Get(string customerNumber);
The returned Customer
type is not the business logic Customer
but a simple data transfer object (DTO) representation of the Customer table in the database. Furthermore, the business logic wants to look up the customer by a CustomerNumber
object, yet the database lookup method uses a primitive string
customer number.
The ORM tool has created a lookup method suited for our database implementation. For example, it reveals that the database stores customer numbers as strings.
The business logic is not interested in this detail—it operates at a higher level of abstraction. It wants to get a customer by customer number—that’s it.
Interface ICustomerDataSource
should specify the methods needed by the business logic and not the ones produced by the ORM. The business logic is the client dictating the interface, ICustomerDataSource
.
If we always follow the approach that the client dictates the interface, we will be onto a good thing regarding application architecture.
Leave a Reply
Want to join the discussion?Feel free to contribute!