Question

I got the following statement from an MSDN article. It says that the abstract classes have an advantage over interfaces because it is possible to alter an abstract class to add new members. Doesn’t altering the abstract class really make the classes inheriting from it unstable? Or can any one please explain what is their point here?

Do favor defining classes over interfaces.

In later versions of your library, you can safely add new members to
classes; you cannot add members to interfaces without breaking
existing code.

Answer 1

It’s not to be taken too strictly. Programming through interfaces (as contracts) is really the best way to decouple your application. For example, creating a wrapper around an interface is very easy, while a class doesn’t even have to have a single virtual method.

Additionally, the article doesn’t even seem to compare abstract classes to interfaces (because it only mentions them in the next “guideline”), but all classes in general over interfaces. So, it’s a rather fuzzy guideline, if you ask me.

It might make sense exclusively with the problem stated: changing an interface breaks all implementations, while adding members to a class doesn’t. On the other hand, if you change a method’s signature, you won’t be very lucky with classes either. From a security point of view, abstract classes do provide a way to make sure that your library always exposes its own functionality to callers, allowing modifications only where you want them. With interfaces, you can pass pretty much any code which satisfies the contract.