An abstract class or interface for the IoC service?

Question

I am currently using IoC to provide specific repository implementations in a project. All the examples I read use the interface as a service definition. However, after reading the recommendations from Microsoft, it is recommended that abstract classes be preferred over interfaces .

I found this useful in combination with a template pattern to reduce repetition. For example, give the Product class with the IsActive property, I could use the interface for the repository, for example:

 interface IProductRepository { IEnumerable<Product> Load(); } 

If the general goal is to download active products, then I will need:

 IEnumerable<Product> activeProducts = repository.Load().Where(x => x.IsActive); 

Where repository is a specific implementation. If I were to use an abstract class, for example:

 abstract class ProductRepository { protected abstract IEnumerable<Product> LoadCore(); public IEnumerable<Product> Load() { return LoadCore().Where(x => x.IsActive); } } 

Then I could download active products using

 IEnumerable<Product> activeProducts = repository.Load(); 

The entire implementation for loading product information is inside the class class that receives the ProductRepository , so there is no connection with the level of stability. If it is discovered that there is another activity usually performed, then this can be added to the base class as an inextricable change that cannot be made using the interface.

Is there any benefit of using an interface instead of an abstract class? What potential flaws in using abstract classes can I find?

I use Castle Windsor as an IoC controller and .Net framework 3.5.

Answer 1

I do not think this question depends on the IoC; most of these frameworks do not care about what you use.

The big problem with using interfaces over abstract base classes is that you cannot correctly version control> .

Abstract base classes are usually the best choice because of this. I don’t think there is any drawback to using an abstract base class, except to get support questions such as “why can't I instantiate this type?”

Answer 2

The recommendation is based on the Wireframe Design Guide . This Microsoft recommendation exists specifically for reusable class libraries. In other words: frameworks similar to the .NET platform itself. If you are creating a line of business applications, this guide does not apply. This does not apply, since it is unlikely that you will have version problems in the business application, because you control all the client code that speaks with your classes / interfaces. This, of course, does not apply to reusable libraries.

Even Phil Hack’s article linking to this:

Again, these recommendations are specific to the development of Framework (for statically typed languages), and not to other types of software development.

Therefore, troubleshooting version problems is probably not a good argument for using base classes. However, a DRY code may be stored. However, the use of base classes and interfaces is not mutually exclusive; you can let your abstract class ProductRepository implement IProductRepository . If you do, exposing anything else besides IProductRepository would be a bad idea.