Why do WCF services use interfaces as a service contract instead of an abstract class?

Question

This is the question that I was asked in the interview.

When you create a WCF service, you get two files; "IService.cs" and "Service.cs". Why is it a class that implements an interface compared to a class that inherits an abstract class. Do not respond by saying that you cannot place the [servicecontract] attribute over an abstract class. I know that you can only apply it to interfaces, but why?

Answer 1

You can implement more than one interface. Only one abstract class can be inherited.

Answer 2

WCF completely separates the client from the service if you specify the service implementation as a service with which you have closely associated your client with the service.

Answer 3

A few reasons I can think of:

• A clear statement of intent is "this set of API signatures is completely separate from any possible implementation." On the contrary, an abstract class (in my opinion) is rather the expression "this base class was designed to work with this set of derived classes."
• More open to modification - as soon as you inherit one base class, this. Since a [ServiceContract] has no implementation, why waste one inheritance slot that you have? For example, all our service classes inherit from the abstract ServiceBase class, which provides a common context state and methods, in addition to implementing the [ServiceContract] interface. However, even if this were not so, I would leave a free base class slot for future use.
• It allows one service class to implement more than one [ServiceContract] , if necessary.
• If you use a strict version control system that relies on the inheritance of one [ServiceContract] from another, then adding service classes to the same inheritance tree will lead to its destruction.