Friday, September 21, 2007

Interfaces Vs Classes

Are you a programmer with decent experience and are you in to .NET then you wouldn't have missed this question interfaces Vs classes. you must have come across this when you do design, or if not at least when you are interviewing. This happens to be one of the very favorite questions among the interviewers.

Initially I had different ways of understanding things and ended up giving different answers based on different reasons. Then I sat down with my senior (Nelson Kidd) in my current work place to understand what the real deal between both is. The below write-up is based on his teaching/inputs to me, a lot is based on our project but still it is very generic and applies to all.

Below you will see more than the common differences like the abstract classes can have implementations but the interfaces cannot, classes have the classes’ typical properties.

Interfaces are the way to mention the contract behavior, where as with classes it is hard to maintain it is like if you are providing API’s and if you are the provider of the API, if you are using interfaces you say it is like these are the behavior and properties. If you are doing the same by the way of classes (all the way inheriting with different provider side implementations) then it is like saying well this is the behavior and properties and also this is the way I am going to implement it. Then when something changes in the API’s end it becomes way to harder if the provider API’s are built based on classes, the consumers need to change the way their code is written. But if it is interface there will be very minimal impact or none in terms of addition of new methods to the interface and it will be a minor impact if something changes/removed. The killer here is the difference in the way the classes has to be inherited to achieve different implementation.

Dough I am not a C# programmer and my code is in C++, then what’s the deal, so you would create various Abstract classes with various pure virtual functions and the classes will implement the methods of the abstract classes. With classes there is a lot of way of messing out with the security/access specifier, that you can use public/private/protected. And you need to develop a document for the API users to understand when a method can be called, what is the context blah blah…so that they can understand how to use your classes.
But the nicer way with interface is that there is no way to get it wrong, I mean by mistake when using classes developers can misuse the access specifier and hence gets things wrong. But with interfaces they are the way they are and the .NET platform will not allow you to mess up with the interfaces, because it works straight things that are allowed are allowed and things that are not are not.

Think from a business angle it all boils down to the contract agreement, when you are developing enterprise wide applications you are often providing some API’s and the contract is signed for that. These API’s are easier to define on the first hand by understanding the requirements without bothering the implementation we can define whole lot of interfaces to it in the first place. So it is using interfaces helps in bridging the gap between requirements and development. The second thing is you do not have the luxury of asking your fellow customers/cross-company developers to change their code it is because you designed the API’s using the classes.

A simple way is to use a factory pattern to give the instance of the implementation of the interface and the caller will be just asking for the interface’s instances. But if the same where a class then there will be many strict design required as opposed to being very informal to the interface implementations and of course multiple interfaces could be implemented. Interfaces be re-casted, hence for security issues on the end (like .NET remoting) use classes, at least wrap the interfaces that you want to expose with the classes wrapping it.

There are different kinds off programmers, some would say this is how you have to do it, and some totally do not care about it unless the end result is fine. The rules are to be broken, but understand when and where you can break, understand the whole problem and give the best solution in terms of your approach and the way you attack, remember some one is paying for you and as long as they see the value in the way you do it, then you are in the right direction; if not it is time to THINK.

No comments: