Skip to main content

Abstract class vs Interface 1-0

There is a lot of talk on interfaces vs abstract classes and while I was working on a C# ADO.net application (with Ingres on the backend, of course) I was intrigued by the difference between the IDbconnection interface and Dbconnection abstract class. What is the difference ?

The IDbConnection interface was introduced in ADO.net 1.0 to enforce common behaviour for the providers' connection objects i.e. a standardized way of how to open a connection, how to close it etc. Of course there were a number of other interfaces introduced such as IDbCommand which at the end of the day allowed programming in a database-agnostic way.

So far so good, common behaviour is what an interface is primarily used for.

In ado.net 2.0 the DbConnection abstract-must inherit base class was introduced which implements IDbConnection; a first immediate advantage is that you get the implementation that was required by the interface's contract for free as it is implemented by the class.

But another advantage is versioning. In 2.0 Microsoft had to add new functionality to the providers beyond the interface members and to do that they would have to change the interface which subsequently meant changing any code that implemented the interface to implement those changes as well, even if not needed.

Thus what they've came up with were abstract base classes that allowed new features and new functionality to be added hence the old code would not require to be change plus it would give the client code the freedom to use or override those features.

So here it is a concrete example of passing the interface in favour of versioning.

Comments

Popular posts from this blog