+972 52-548-6969
More reasons for interfaces
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.
Comments
I do exactly the same thing for exactly the same reason.
I agree with you. Great post.
I think one reason why you have a greater appreciation for interfaces and build your code to allow you to swap in implementations is that you are comfortable with IoC. It's just a logic way of doing things, once you're used to an infrastructure that provides you with the appropriate implementation depending on configuration.
As long as people still primarily write the code that creates a concrete class by hand and then have to cast it to an interface, using an interface easily becomes an afterthought until you need a second implementation.
Could you please expand on this approach a bit more? Do you create all your interfaces first to define what is going on and then implement them classes to define how they work?
Is that so that if you want to change the behaviour you can simply implement the interface again and revert back to the old implementation if required in the future?
Thanks.
Dave,
I tend to be of mixed mind here, often enough I will pre-create the interface and some initial methods, proceed to use it, then write up an implementation.
That approach make it very easy to just add/remove methods when I explore what I need of it.
Other times I will just see the need of it and create it as I go along.
Thanks for the reply Ayende but doesn't that kind of violate the don't repeat yourself principle?
If one of the methods change then you have to update the interface as well as the implementation (well technically you don't but the interface is then pointless).
Why wouldn't you just create a normal class instead with blank methods i.e. F() { } and then go from there?
I don't think it violate DRY.
If one of the method change, I make the change in one place, and let R# handle it.
The main reason that I am using interfaces instead of classes is that I want to separate the WHAT from the HOW
I think I get it now.
So in future you could create a different implementation and then change between them if need be?
Thanks for your help by the way.
Not only for that, although this is the classic reason for interfaces.
That is something that I would call YAGNI on.
What I am striving for is to have IAuthenticationService and an ActiveDirectoryAuthenticationService.
With a big disconnect between the two.
I don't give a chopped monkey liver for the impl when I am using it, and I really shouldn't.
Comment preview