Am I confused about the interfaces?

Question

I support the ASP.NET MVC project. In the project, the original developer has an absolute ton of interfaces. For example: IOrderService , IPaymentService , IEmailService , IResourceService . What I'm embarrassed about is that each of them is implemented by only one class. In other words:

 OrderService : IOrderService PaymentService : IPaymentService 

My understanding of interfaces has always been that they are used to create an architecture in which components can be easily changed. Sort of:

 Square : IShape Circle : IShape 

In addition, I do not understand how they are created and used. Here is the OrderService:

 public class OrderService : IOrderService { private readonly ICommunicationService _communicationService; private readonly ILogger _logger; private readonly IRepository<Product> _productRepository; public OrderService(ICommunicationService communicationService, ILogger logger, IRepository<Product> productRepository) { _communicationService = communicationService; _logger = logger; _productRepository = productRepository; } } 

These objects never seem to be created directly, since in OrderService orderService = new OrderService() it always uses an interface. I don’t understand why the interfaces are used instead of the class that implements the interface, or how it works. Is there anything important that I am missing in the interfaces, that my Google skills are not being revealed?

Answer 1

This design pattern usually facilitates unit testing, as you can now replace OrderService with TestOrderService, both of which are specific to IOrderService. This means that you can write TestOrderService to provide specific behavior to the class you are testing, and then determine if the class does the right thing under the test.

In practice, the above is often done using the Mocking framework, so you don’t actually code the TestOrderService manually, but rather use a more concise syntax to describe how it should behave for a typical test, and then the mocking structure dynamically generates an implementation for you.

As for why you never see the “new OrderService” in your code, your project probably uses some form of the “Inverse of Control” container, which makes it easy to automatically inject dependencies. In other words, you don’t need to create an OrderService directly, because somewhere you configured that any use of the IOrderService should be done automatically by building a singleton OrderService and passing it to the constructor. There are many subtleties here, and I'm not quite sure how your dependency injection is performed (it should not be automatic, you can also just instantiate manually and pass them through the constructors.)

Answer 2

This is not the only use of interfaces, in MVC they are used to decouple the contract from implementation. To understand what MVC is, you need to think a little about topics such as separation of concerns and inversion of management (IoC). The actual act of creating the object to be passed to the OrderService constructor is handled by the IoC container based on some predefined mappings.

Answer 3

These objects never seem to be created directly, as in OrderService orderService = new OrderService ()

So waht?

The point is that THAT calls the OrderService constructor, and CALLER to create them. He passes them.

I do not understand why interfaces are used instead of the class that implements the Interface

Since you want to not know the class - it can change, be external, be configured using the IOC container, and the programmer decided not to require even a regular base class. The less assumptions you make about how someone implements the used utility classes, the better.

Is there anything important that I am missing in the interfaces that my Google skills are not outcrops?

No, a good OO programming book will help more than random Google snippets. This happens in the area of ​​architecture and the basics of .NET (for the first part).

Answer 4

Good practice is to program against interfaces, not objects. This question provides good reasons, but some reasons include the possibility of changing the implementation (for example, for testing).

Just because there is currently only 1 class that implements the interface does not mean that it cannot change in the future.

In addition, I do not understand how they are created and used.

This is called dependency injection and basically means that the class does not need to know how and where to create it, someone will cope with it.

Answer 5

These are service interfaces that encapsulate some kind of appearance. You often have only one implementation of them in your main project, but your tests use simpler implementations that are independent of this external material.

For example, if your payment service contacts PayPal to confirm payments, you don’t want to do this in the unrelated code test. Instead, you can replace them with a simple implementation that always returns “processed payment” and verifies that the order process passes, and another implementation that returns “payment failed”, and verify that the order process also fails.

To avoid implementation dependency, you do not create instances yourself, you accept them in the constructor. Then the IoC container creating your class will fill them. Take a look at Inversion of Control .

Your project probably has code that sets the IoC container in its startup code. And this code contains information about which class to create when you want to implement a specific interface.