More reasons for interfaces

time to read 2 min | 270 words

Usually when I start a system, I want to focus on the shortest scenario that would bring me a live system. That is usually the login page, since that is almost universally identical.

My approach to that is fairly simple, Login Controller that collaborate with an authentication service and an authorization service. The first to verify who the user is, the second to verify that the user even has the right to log in. I always use interfaces for those, so I would have IAuthorizationService and IAuthenticationService as the forth or fifth elements in my application.

Now, the reason for interfaces is actually not mocking, or anything of the like. If is simply because an interface allows me to create a strict separation between what is going on and how it works.

In order to complete the story, I may often need to write ActiveDirectoryAuthenticationService, but that is an implementation detail, I don't want to know about that. I want the interface to express just the required detailed for authentication, not to be involved with the details of actually handling the AD authentication.

In most projects I am going to have only one implementation of many of those types of interfaces, but the fact that I maintain this separation means that reading the code that makes use of those interfaces is far easier than it would have been otherwise. There is a wider line between the two collaborators, and far less chance of letting implementation semantics go through.

I was in place to try to extract those semantics out once or twice, and that is never pleasant or easy.