c# - with - why interface is preferred over abstract class




Advantage of using Interface over abstract class for repository pattern? (5)

Possible Duplicate:
Interface vs Base class

Its common to see the repository pattern implemented using Interfaces

public interface IFooRepository
{
   Foo GetFoo(int ID);
}

public class SQLFooRepository : IFooRepository
{
   // Call DB and get a foo
   public Foo GetFoo(int ID) {}
}

public class TestFooRepository : IFooRepository
{
   // Get foo from in-memory store for testing
   public Foo GetFoo(int ID) {}
}

But you could equally do this using abstract classes.

public abstract class FooRepositoryBase
{
    public abstract Foo GetFoo(int ID);
}

public class SQLFooRepository : FooRepositoryBase
{
    // Call DB and get a foo
    public override Foo GetFoo(int ID); {}
}

public class TestFooRepository : FooRepositoryBase
{
    // Get foo from in-memory store for testing
    public override Foo GetFoo(int ID); {}
}

What are the specific advantages of using an Interface over an Abstract Class in a repository scenario?

(i.e. don't just tell me that you can implement multiple interfaces, I know this already - why would you do that in a repository implementation)

Edit to clarify - pages like "MSDN - Choosing Between Classes and Interfaces" can be paraphrased as "Choose classes over interfaces unless there is a good reason not to" - what are the good reasons in the specific case of a Repository pattern


I guess the key difference would be, that an abstract class can contain private properties & methods, wherein an Interface cannot, as it's only a simple contract.

The result being an interface is always "no shenanigans here - what you see is what you get" whilst an abstract base class may allow side effects.


Personally, I tend to have an interface that holds the signature for the methods that are purely "business-related" for example Foo GetFoo(), void DeleteFood(Foo foo), etc. I also have a generic abstract class that holds protected methods like T Get() or void Delete(T obj).

I keep my methods protected in the abstract Repository class so that the outside world is not aware of the plumbery (Repository will look like object) but only of the business model via the interface.

On top of having the plumbery shared another advantage is that I have for example a Delete method (protected) available to any repository but it is not public so I am not forced to implement it on a repository where it has no business meaning to delete something from my data source.

public abstract class Repository<T>
{
    private IObjectSet objectSet;

    protected void Add(T obj)
    {
        this.objectSet.AddObject(obj);
    }

    protected void Delete(T obj)
    {
        this.objectSet.DeleteObject(obj);
    }

    protected IEnumerable<T>(Expression<Func<T, bool>> where)
    {
        return this.objectSet.Where(where);
    }
}

public interface IFooRepository
{
    void DeleteFoo(Foo foo);
    IEnumerable<Foo> GetItalianFoos();
}

public class FooRepository : Repository<Foo>, IFooRepository
{
    public void DeleteFoo(Foo foo)
    {
        this.Delete(foo);
    }

    public IEnumerable<Foo> GetItalianFoos()
    {
        return this.Find(foo => foo.Country == "Italy");
    }
}

The advantage of using the abstract class over an interface for the plumbery is that my concrete repositories do not have to implement method they don't need (Delete or Add for example) but they are at their disposal if they need it. In the current context, there is no business reason for to some Foos so the method is not available on the interface.

The advantage of using an interface over an abstract class for the business model is that the interface provides the answers to how it make sense to manipulate Foo from a business side (does it make sense to Delete some foos? To create some? etc.). It's also easier to use this interface when Unit testing. The abstract Repository I use cannot be unit tested because it is usually tightly coupled with the database. It can only be tested in integration tested. Using an abstract class for the business purpose of my repositories would prevent me from using them in unit tests.


Take a look at the implementation of Tim McCarthy's Repository Framework. < http://dddpds.codeplex.com/ >

He uses interfaces like IRepository<T> for defining the contracts, but he also uses abstract classes like RepositoryBase<T> or his SqlCeRepositoryBase < T > that implements IRepository<T>. The abstract base class is code to eliminate a lot dublicate code. A type specific repository just have to inherit frome the abstract base class and needs to add the code for its purpose. Users of the API can just code against the interface by contract.

So you can combine both approaches to use the advantages of them.

Additionally, I think most IoC-Frameworks can handle abstract classes.


The main advantage of using an interface over an abstract class in this instance is that an interface is entirely transparent: This is more of an issue where you don't have access to the source of the class you're inheriting from.

However, this transparency allows you to produce unit tests of a known scope: If you test a class that accepts an interface as a parameter (using the dependency injection method), you know you're testing the class with a known quantity; the testing implementation of the interface will only contain your testing code.

Similarly, when testing your repository, you know you're testing just your code in the repository. This helps to limit the number of possible variables/interactions in the test.


While others may have more to add, from a purely practical point of view, most IoC frameworks work better with interface -> class mappings. You can have different visibilities on your interfaces & classes, whereas with inheritance, the visibilities must match.

If you're not using an IoC framework, from my point of view there is no difference. Providers are based on abstract base classes.







architecture