4

This is a question I got asked in an interview.

When you create a WCF service, you get two files; "IService.cs" and "Service.cs". Why is it a class implementing an interface versus a class inheriting an abstract class. Don't reply saying that you cannot put a [servicecontract] attribute over the abstract class. I know you can only apply it to interfaces, but why?

fbhdev
  • 526
  • 7
  • 17

3 Answers3

6

One can implement more than one interface. One can only inherit a single abstract class.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • I said that in the interview, but they said that it is highly unlikely to implement two service contracts in a wcf service. – fbhdev Dec 19 '11 at 17:04
  • I didn't say multiple service contracts (though I have seen that done, where the two contracts have different security requirements); I meant interfaces of any kind. – John Saunders Dec 19 '11 at 17:05
  • @ fahed. We have multiple services that implement multiple interfaces, so not that unusual! – ChrisBint Dec 19 '11 at 17:06
  • Indeed, this lends well to the interface segregation principle where different consuming clients may want different "views" into the same backing API. – David Dec 19 '11 at 17:08
  • you can implement multiple interfaces true. but I can also inherit an abstract class and still implement multiple interfaces (assuming that the abstract class was decorated with [servicecontract] attribute). – fbhdev Dec 19 '11 at 17:11
  • Yes, but you can only inherit a _single_ abstract class. – John Saunders Dec 19 '11 at 17:14
  • I completely agree, and did tell them that, I just think they were looking for a different answer. – fbhdev Dec 19 '11 at 17:16
  • Maybe they wanted you to say that an abstract class may include behavior, and that you don't want behavior from the server to pollute the client, even assuming that the behavior description could be transmitted over the network. – John Saunders Dec 19 '11 at 17:17
6

WCF completely decouples the client from the service, if you specify the implementation of the service as the service you have tightly coupled your client to the service.

Rich O'Kelly
  • 41,274
  • 9
  • 83
  • 114
1

Several reasons I can think of:

  • A clear statement of intent - "this set of API signatures is totally decoupled from any possible implementation". By contrast, an abstract class (in my opinion) is more a statement of "this base class was designed to work with this set of derived classes".
  • More open for modification - once you inherit one base class, that's it. Since a [ServiceContract] has no implementation, why waste the one inheritance slot you have on it? For example, all our service classes inherit from an abstract ServiceBase class which provides common context state and methods, in addition to implementing the [ServiceContract] interface. However, even if that were not the case, I would still leave the base class slot free for future use.
  • It permits one service class to implement more than one [ServiceContract] if appropriate.
  • If you are using a strict contract versioning system that relies on inheriting one [ServiceContract] from another, then adding service classes to the same inheritance tree will ruin it.
Christian Hayter
  • 30,581
  • 6
  • 72
  • 99