Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive

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.


Jeff Brown

I do exactly the same thing for exactly the same reason.

Maor David

I agree with you. Great post.

Arne Claassen

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.

Dave Bown

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?


Ayende Rahien


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.

Dave Bown

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?

Ayende Rahien

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

Dave Bown

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.

Ayende Rahien

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

Comments have been closed on this topic.


  1. The worker pattern - about one day from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats