Question

I am still having trouble understanding what interfaces are good for. I read a few tutorials and I still don’t know what they really are for other then “they make your classes keep promises” and “they help with multiple inheritance”.

Thats about it. I still don’t know when I would even use an interface in a real work example or even when to identify when to use it.

From my limited knowledge of interfaces they can help because if something implements it then you can just pass the interface in allowing to pass in like different classes without worrying about it not being the right parameter.

But I never know what the real point of this since they usually stop short at this point from showing what the code would do after it passes the interface and if they sort of do it it seems like they don’t do anything useful that I could look at and go “wow they would help in a real world example”.

So what I guess I am saying is I am trying to find a real world example where I can see interfaces in action.

I also don’t understand that you can do like a reference to an object like this:

ICalculator myInterface = new JustSomeClass();

So now if I would go myInterface dot and intellisense would pull up I would only see the interface methods and not the other methods in JustSomeClass. So I don’t see a point to this yet.

Also I started to do unit testing where they seem to love to use interfaces but I still don’t understand why.

Like for instance this example:

public AuthenticationController(IFormsAuthentication formsAuth)
{
    FormsAuth = formsAuth ?? new FormsAuthenticationWrapper();
}

public class FormsAuthenticationWrapper : IFormsAuthentication
{
    public void SetAuthCookie(string userName, bool createPersistentCookie)
    {
        FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
    }
    public void SignOut()
    {
        FormsAuthentication.SignOut();
    }
}

public IFormsAuthentication FormsAuth
{
    get;
    set;
}

Like why bother making this interface? Why not just make FormsAuthenticationWrapper with the methods in it and call it a day? Why First make an interface then have the Wrapper implement the interface and then finally write the methods?

Then I don’t get what the statement is really saying.

Like I now know that the statement is saying this

FormsAuth = formsAuth ?? new FormsAuthenticationWrapper();

if formsAuth is null then make a new FormsAuthenticationWrapper and then assign it to the property that is an Interface.

I guess it goes back to the whole point of why the reference thing. Especially in this case since all the methods are exactly the same. The Wrapper does not have any new methods that the interface does not have and I am not sure but when you do this the methods are filled right(ie they have a body) they don’t get converted to stubs because that would really seem pointless to me(it it would be converted back to an interface).

Then in the testing file they have:

var formsAuthenticationMock = new Mock<AuthenticationController.IFormsAuthentication>();

So they just pass in the FormsAuthentication what I am guessing makes all the fake stubs. I am guessing the wrapper class is used when the program is actually running since it has real methods that do something(like sign a person out).

But looking at new Mock(from moq) it accepts a class or an interface. Why not just again made the wrapper class put those methods in and then in the new Mock call that?

Would that not just make the stubs for you?

Answer 1

Interfaces define contracts.

In the example you provide, the ?? operator just provides a default value if you pass null to the constructor and doesn’t really have anything to do with interfaces.

What is more relevant is that you might use an actual FormsAuthenticationWrapper object, but you can also implement your own IFormsAuthentication type that has nothing to do with the wrapper class at all. The interface tells you what methods and properties you need to implement to fulfill the contract, and allows the compiler to verify that your object really does honor that contract (to some extent – it’s simple to honor a contract in name, but not in spirit), and so you don’t have to use the pre-built FormsAuthenticationWrapper if you don’t want to. You can build a different class that works completely differently but still honors the required contract.

In this respect interfaces are much like normal inheritance, with one important difference. In C# a class can only inherit from one type but can implement many interfaces. So interfaces allow you to fulfill multiple contracts in one class. An object can be an IFormsAuthentication object and also be something else, like IEnumerable.

Interfaces are even more useful when you look at it from the other direction: they allow you to treat many different types as if they were all the same. A good example of this is with the various collections classes. Take this code sample:

void OutputValues(string[] values)
{
   foreach (string value in values)
   {
       Console.Writeline(value);
   }
}

This accepts an array and outputs it to the console. Now apply this simple change to use an interface:

void OutputValues(IEnumerable<string> values)
{
   foreach (string value in values)
   {
       Console.Writeline(value);
   }
}

This code still takes an array and outputs it to the console. But it also takes a List<string> or anything else you care to give it that implements IEnumerable<string>. So we’ve taken an interface and used it to make a simple block of code much more powerful.

Another good example is the ASP.Net membership provider. You tell ASP.Net that you honor the membership contract by implementing the required interfaces. Now you can easily customize the built-in ASP.Net authentication to use any source, and all thanks to interfaces. The data providers in the System.Data namespace work in a similar fashion.

One final note: when I see an interface with a “default” wrapper implementation like that, I consider it a bit of an anit-pattern, or at least a code smell. It indicates to me that maybe the interface is too complicated, and you either need to split it apart or consider using some combination of composition + events + delegates rather than derivation to accomplish the same thing.