views:

530

answers:

9

Is it just because of dynamic typing we don't require a concept of interfaces(like in Java and C#) in python?

A: 

Interfaces are used in statically typed languages to describe that two otherwise independent objects "implement the same behaviour". In dynamically typed languages one implicitly assumes that when two objects have a method with the same name/params it does the same thing, so interfaces are of no use.

Grzenio
+11  A: 
OscarRyz
I'd add an additional +1 for mentioning Structural typing, if I could. It's a great concept.
RHSeeger
Another +1 for structural typing
Yann Ramin
"The interface as a keyword and artifact was introduced by Java". Not really sure about that. CORBA's IDL (1991) has the `interface` keyword, and in C++ release 2.0 (1989) a class with all pure virtual member functions is semantically identical to an interface. So I'd guess that perhaps Java borrowed the keyword from CORBA in order to give special prominence to the language feature idea borrowed from C++.
Daniel Earwicker
And another +1 for static structural typing though again I have to point to C++ (templates) as the most widespread example.
Daniel Earwicker
A: 

In C# and Java, interfaces are just abstract classes with all abstract methods. They exist to allow pseudo multiple-inheritance without actually supporting full-blown multiple inheritance and the ambiguity multiple inheritance creates.

Python supports multiple inheritance and has its own way of determining which parent's method should be called when a method exists in multiple parents.

R. Bemrose
"In C# and Java, interfaces are just abstract classes with all abstract methods." Ah, if only that were true! http://smellegantcode.wordpress.com/2008/05/22/virtual-properties-in-c/
Daniel Earwicker
+1  A: 

Interface constructs are used in statically typed languages to teach the type system which objects are substitutable for each other in a particular method-calling context. If two objects implement the same method but aren't related through inheritance from a common base class or implementation of a common interface, the type system will raise an error at compile time if you substitute one for the other.

Dynamic languages use "duck typing", which means the method is simply looked up at runtime and if it exists with the right signature, it's used; otherwise a runtime error results. If two objects both "quack like a duck" by implementing the same method, they are substitutable. Thus, there's no explicit need for the language to relate them via base class or interface.

That being said, interfaces as a concept are still very important in the dynamic world, but they're often just defined in documentation and not enforced by the language. Occasionally, I see programmers actually make a base class that sketches out the interface for this purpose as well; this helps formalize the documentation, and is of particular use if part of the interface can be implemented in terms of the rest of the interface.

Owen S.
+3  A: 

We don't require them, but we do support them. Check out Zope Interfaces (which can be and are used outside of Zope).

gomad
A: 

Dynamic languages are Duck Typed

If it walks like a duck and quacks like a duck, it must be a duck

http://en.wikipedia.org/wiki/Duck_typing

In other words, If you exect an object to suport the Delete() method, than you can just use the

obj.Delete()

method but if the object doesn't support Delete() you get a Runtime error. Statically typed languages wouldn't allow that and throw a compile time error. So you basically trade type safty against faster developement time and flexibility.

Without interfaces you can do something like that in static languages:

void Save(MyBaseClass item)
{
    if (item.HasChanges)
        item.Save()
}

but that would require every object that you pass to this method to inherit from MyBaseClass. Since Java or C# don't support muliinheritance that isn't very flexible because if your class already inherits another class it cannot inherit from MyBaseClass, too. So the better choise would be to create a ISavable interface and accept that as a input parameter to ensure that item can be saved. Then you have best of both: type safety and flexibility.

public interface ISavable
{
    bool HasChanges {get;set;}
    void Save();
}

void Save(ISavable item)
{
    if (item.HasChanges)
        item.Save()
}

The last backdoor is to use object as a parameter if you cannot expect every item that will use your save method to implement the interface.

void Save(object item)
{
    if (item.HasChanges)
        item.Save()
}

But than again, you don't have compile time checking and probably get a runtime error if someone uses your method with an incompatible class.

SchlaWiener
"Dynamic languages are Duck Typed". That's a pretty wild thing to say. It needn't be entirely true.
Noufal Ibrahim
A: 

It's worth noting that, contrary to what many people will say as a first response, interfaces can be used to do more than document "what methods a class supports". Grzenio touches on this with his wording on "implement the same behaviour". As a specific example of this, look at the Java interface Serializable. It doesn't implement any methods; rather it's used as a "marker" to indicate that the class can be serialized safely.

When considered this way, it could be reasonable to have a dynamic language that uses interfaces. That being said, something akin to annotations might be a more reasonable approach.

RHSeeger
+1  A: 

One key thing about at least some dynamic languages that makes explicit interfaces more than a little awkward is that dynamic languages can often respond to messages (err, “method calls”) that they don't know about beforehand, even doing things like creating methods on the fly. The only real way to know whether an object will respond to a message correctly is by sending it the message. That's OK, because dynamic languages consider it better to be able to support that sort of thing rather than static type checking; an object is considered to be usable in a particular protocol because it is “known” to be able to participate in that protocol (e.g., by virtue of being given by another message).

Donal Fellows
And by “given by another message” I mean passed as an argument to a method call, or returned from a method call.
Donal Fellows
A: 

Perl has Roles (or traits ), It is more than interfaces unlike java perl roles we can have a implementation check out these links for more on perl roles

http://en.wikipedia.org/wiki/Perl_6#Roles

use.perl.org/~Ovid/journal/38649