The reason for interfaces truly eludes me. From what I understand, it is kind of a work around for the non-existent multi-inheritance which doesn't exist in C# (or so I was told).
All I see is, you predefine some members and functions, which then have to be re-defined in the class again. Thus making the interface redundant. It just feels like syntactic... well, junk to me (Please no offense meant. Junk as in useless stuff).
In the example given below taken from a different C# interfaces thread on stack overflow, I would just create a base class called Pizza instead of an interface.
easy example (taken from a different stack overflow contribution)
public interface IPizza
public void Order();
public class PepperoniPizza : IPizza
public void Order()
//Order Pepperoni pizza
public class HawaiiPizza : IPizza
public void Order()
The point is that the interface represents a contract. A set of public methods any implementing class has to have. Technically, the interface only governs syntax, i.e. what methods are there, what arguments they get and what they return. Usually they encapsulate semantics as well, although that only by documentation.
You can then have different implementations of an interface and swap them out at will. In your example, since every pizza instance is an
IPizza you can use
IPizza wherever you handle an instance of an unknown pizza type. Any instance whose type inherits from
IPizza is guaranteed to be orderable, as it has an
Python is not statically-typed, therefore types are kept and looked up at runtime. So you can try calling an
Order() method on any object. The runtime is happy as long as the object has such a method and probably just shrugs and says »Meh.« if it doesn't. Not so in C#. The compiler is responsible for making the correct calls and if it just has some random
object the compiler doesn't know yet whether the instance during runtime will have that method. From the compiler's point of view it's invalid since it cannot verify it. (You can do such things with reflection or the
dynamic keyword, but that's going a bit far right now, I guess.)
Also note that an interface in the usual sense does not necessarily have to be a C#
interface, it could be an abstract class as well or even a normal class (which can come in handy if all subclasses need to share some common code – in most cases, however,