why multiple inheritance is not possible in .net

Interfaces define a contract: implementing an Interface requires that you define and expose all the members of that contract, but does not give any of the implementation detail.  As you pointed out, that is up to the developer, and that is one of the beauties of it itself.

Let's use a classic example: Employee.  Not all employees are created equally: some are hourly, some are salaried.  Some are part time, some are full time.  Many of these examples create subclasses like HourlyEmployee, SalariedEmployee, etc.  The implementation details for calculating their pay could be vastly different, so you can't define the method in the parent Employee class.  So via an Interface, like IPayrollEmployee, you require that there exists a CalculatePay method, with a specific signature (like pay period date range), but you leave the implementation details up to the implementing class.

Now, you can create a Collection of IPayrollEmployee objects, and anything that implements IPayrollEmployee can be in that Collection.  And each object, whether it is SalariedEmployee or HourlyEmployee will have a CalculatePay method with a consistent signature even though the details are different.

So Interfaces are good for building objects with consistent member signatures.  They are also handy for grouping and processing like objects.  Ultimately, Interfaces define behavior.  Everything that implements IDisposable can be used in a like manner, but not every object disposes of itself in the same way.  Some objects need to close FileStreams, some need to clean up database connections, some need to do nothing.  The point is that with Interfaces, it is up to the developer to define how something is done.

This is very powerful, and brings us full circle.  It is correct that implementing multiple Interfaces is no substitution for real multiple inheritance (which would be a nightmare).  But it is a great mechanism for defining (not inheriting) multiple sets of behavior.  So I can create a custom sequence (IEnumerable) that is disposable (IDisposable) and cloneable (ICloneable).  And I can keep adding to that if I wish.

I'll give you one more example and then I'll quit.  One of my first .NET projects was to create a single point of entry for multiple ADO.NET managed providers.  I created an Interface called IDBAccess that defined all the signatures I needed, like RunSelectStatement, ExecuteNonQuery, ExecuteScalar, etc.  I then created wrapper classes for each of the different ADO.NET providers I wanted to support.  All of these implemented IDBAccess, but for each one they require different references to different namespaces.  They all used different classes for ADO access.  They all have different Connection String formats.  The list goes on about how they are different, but the magic here is how they are the same: they all need to expose the same behaviors, as described in IDBAccess.  To finish it all up, I created a master DBAccessManager class that also implemented IDBAccess, but all it did was manage an appropriate IDBAccess instance.  The result is that I have a single, unified set of methods for working with Databases without worrying about all the snarky details.

I hope this helps: Interfaces are your friend!

Can any one then tell me why do we really need interfaces when we still need to implement them on every class that implements it.

why cant you just define your methods and fiels on your class and use them, what defference does it make.

i really dont understand this interface thing.

Ive heard many say that interfaces are a substitution for multiple inheritance in C# though I dont see the truth to that. Interfaces cannot declare instance members, they simply act as a sort of template to implement into a class to make it conform to a certain specification. However, the class that implements the interface must create its own definitions for the interfaces members.

Therefore the class is not inheriting anything really, since an interface, unlike a class, cannot create method or property bodies, but merely their prototypes.

In true inheritance, a class can inherit predefined methods, properties, fields, etc... from a class that they were defined in and use those predefined members without having to define them itself, unless of course those members are virtual and you want to override them.

The only really good use I have found for interfaces is that if a class member is accessing another classes members, it can check to see if that class implements a specified interface first before attempting to call its methods. This is useful for conformity in objects.

Still, interfaces are not a true replacement for multiple inheritance, not that Ive found anyway :)