Difference between abstract class and interface if they have same no of methods and var

In addition to the reference by Griff, please read this discussion: When we use abstract and when we use interface...?.

[EDIT]
One more important thing: in .NET structures cannot inherit from non-interfaces. They can implement muliple interfaces though. This is practically the only OOP feature applied to structures (and value types in general). Most developers did not pay attention to this important feature (unfortunatly, including myself, until someone brought my attention to it).

—SA

I hope the links given by SAKryukov and Original Griff give you a clear picture. I am agree with the comment of Amit Kumar Tiwari. But the point I am stress here is there is no hard rule which one to use. It depends on your necessity. Let me give you a situation which favors Interface over Abstract.

Let us say you have a class Car. It has an abstract method? CalcFuelEfficinecy. Then you will end up defining this method in all your child classes, even the method is same for a few of those children. You can visualize repeatability of same code. As a rescue you want to move this method to your abstract class?. Can't right as a few children want this method in a different way. May be you end up messing with overloading.

But one thing clear this has to taken out of the class and deal separately. So how about defining a IEfficiencyCalculator and it has a signature for the CalcFuelEfficiency method?. Then interface will be implemented by a set of classes say EfficiencyCalculator1, EfficiencyCalculator2.... and so on. Now you can have a instance member of this interface type in your parent class and assign the required EfficiencyCalculator at runtime.. You can see now the problem solved and you can have any number of efficiency calculation business logics and same business logic not repeated. This pattern otherwise called a strategy pattern. You don't need to have a abstract class again to defined these strategy composites. Because here we only define a contract. A class needed only when we use the oops concepts like encapsulation, inheritance etc.,

Now coming back to Amit Kumar Tiwari's comment. An abstract class allows defining a method later stage. Agreed. This is an advantage or disadvantage?, I think it depends your requirement again. If you are going to implement/define this new method in the abstract class then I see there is a potential problem. From the example the Car inherited by Car1. Later you add a method to Car, of course it is useful method for many children, but not required for car1. So you must override this in car1 and do nothing, otherwise the classes inherit car1 will access this method and misuse it. But this problem not there in interfaces. It ensures a safe contract.

Again coming back to Amit Kumar Tiwari's comment that abstract class favors adding new method. Good point. But how to use it for flexibility. Define the interface as said earlier. Use an abstract class and abstract methods to implement this interface. Then only necessary methods can be implemented in the children. So when you add new method in interface , then the least change we need to do only at the abstract class and the necessary children. Other children not affected. So interface still offers the flexibility to add new methods at later stage in a safer way than the inheritance path.

Cheers!

Differences are as Follows:
1. Interface is Globally accessible but Abstract class is not.
2. Abstract class can have a method with Body but not an interface.
3. Abstract class can have a abstract or non-abstract method but methods in Interface are abstract by-default.
4. All Methods in Interface are public by-default but not in abstract.
5. Abstract class can have methods or attribute but interface cannot have an attribute.