Duck Typing and Protocols vs. Inheritance

I don't know about Ruby ...

But in Groovy you can implement methodMissing() so that methods that are called are added to the type. Next time you call this method it will directly go to that method and no longer through methodMissing(). repondsTo() would also recognize this method after the first invocation.

Grails uses this approach all over the place. See one of Graeme's talks on the Grails Exchange for more details.

Also in Groovy, when I realize a method I expect to be there isn't I just add it using ExpandoMethodClass. In this way anything can be turned into a duck.

You could do the same in ruby, although the problem still remains, it has to be called once before the method is attached.

... or did other people also think that was Duct Taping, at first glance? :-D

Of course, the real question you should ask yourself is why you want additional checking of the protocol of your objects.

If it is for greater clarity at the source code level, in Groovy you would mix and match Java's static checking techniques with Groovy's dynamic typing capabilities. You could statically define the type of a variable (as a fine-grained interface of course) or you could implement an interface in your class definition if you wanted. These techniques provide you with a more declarative specification of your objects protocol(s) than without. That doesn't mean you abandon dynamic typing where it makes sense and you should still use fine-grained (interface-oriented programming) when thinking about interfaces anyway. It certainly puts Groovy miles ahead of many other dynamic languages for those scenarios where you want to apply a declarative style.

If it is for more robustness in your code, than you have various techniques available to you at the metaprogramming layer. In Groovy, I would possible hook into the beforeInvoke() interceptor or the methodMissing() level if needed. Groovy is a little bit more powerful (but mostly on par) with other dynamic languages in this regard.

We have had the same problem with duck typing and implicit assumptions that can be made based on particular implementation details in Python and Zope. Python is tackling the problem by adding abstract base classes to Python 3:

www.python.org/dev/peps/pep-3119/

Zope tackled the problem by using metaprogramming to supply their own interface implementation:

griddlenoise.blogspot.com/2005/12/zope-componen...

"This problem could, of course, be solved by making fine grained interfaces, with one method each, and building the full interface up with new interfaces that extend the previous ones, each adding a single API call."

from zope.interface import interface
from zope.schema import TextLine, SourceText

class IBaseContent(Interface):
  "Shared attributes amongst all content objects"
  title = TextLine(title=u'Title')
  description = SourceText(title=u'Description')

class IDocument(IBaseContent):
  "Plain document"
  body = SourceText(title=u'Body')

class INewsItem(IDocument):
  "News Item"
  slug = SourceText(title=u'Slug for lead-in text')

>> class Whatever(object):
...   "some random plain old object"
...
>>> random_obj = Whatever()
>>> random_obj.title = 'My Doc'
>>> random_obj.description = 'A simple doc'
>>> random_obj.body = 'simple body'
>>> interface.directlyProvides(random_obj, IDocument)
>>> IDocument.providedBy(random_obj)
True

>>> mydatacontainer['some-unique-name'] = random_obj

What bothers me about protocols is that intent seems to be left aside. For example, in the following, what is intended by the call to draw() by DrawThing? With interfaces, at least you can see from the inheritence what is intended if you implement only one of the interfaces that specifies a draw method.

public interface Graphics {
    void draw();
}

public interface DeckOfCards {
    void draw();
}

public final class DrawThing implements DeckOfCards, Graphics {
    public void draw() {
    }
}

Ahh the old - it looks like a duck, sounds like a duck - it must be a duck. Except it's not.

The original question (and some posts in the mailing list debate) seems to come from the confusion about the role of inheritance in OOP. StringIO and IO don't need to go back to the same superclass, because they don't share any commonalities except one: a set of methods they support.

Well then why do they both have a lot of the same methods? Obviously they do have something in common - a common set of behaviors.
Sometimes though it's not just the behavior that you're interested in. Sometimes it doesn't just suffice to know that an object can
respond to a specific message or method call. Sometimes you have to know what class the object really is.
It's got a beak, and webbed paddles - is it a duck, or is it a platypus?

class IQuacker(Interface):
	"It quacks!"
	def quack(self):
		"Make some noise"

class IDuck(IQuacker):
	"Definition of a duck"

class IPlatypus(IQuacker):
 	"Definition of a platypus"

class Duck(object):
	implements(IDuck)
	def quack(self):
		print "Duck noise is the only noise!"

class Platypus(object):
	implements(IPlatypus)
	def quack(self):
		print "Platypus noise is better than duck noise!"

>>> platypus =  Platypus()
>>> IQuacker.providedBy(platypus)
True
>>> IPlatypus.providedBy(platypus)
Ture
>>> IDuck.providedBy(platypus)
False

>>> platypus = Platypus()
>>> hasattr(platypus,'quack')
True
>>> isinstance(platypus,Platypus)
True
>>> isinstance(platypus,Duck)
False

class MockPlatypus(object):
	implements(IPlatypus)
	def quack(self):
		pass

These ideas sound a lot like what we are trying to accomplish with Qi4j in Java:
www.qi4j.org/160.html

By focusing on interfaces, and allowing an object to easily implement as many interfaces as are necessary without having to use class inheritance or manual delegation to implement it, it becomes a lot easier to write and (re)use code.

You should not need to know what the implementation class is, you just need the ability to distinguish between two different interfaces that share the same method names. The authors of Design Patterns summed it up very well with the statement, "Program to an interface, not an implementation." As soon as you use is_a? or responds_to? you are asking objects about their implementation details and "programming to an implementation".

First of all, let me say, the original article was great, and I really enjoyed it. Second, I'd like to weigh in on this conversation regarding if and when you should program to an implementation. It seems like you can divide up programming into three sorts of "layers". I don't mean layers of an application, but layers of code. You have the "system" layer, which is virtually defined by it's need to program to implementations. Nowadays we have runtimes like Java and the CLI to do that for us, so we rarely need to worry about this any more. A piece of "system" code serves no purpose other than to provide functionality to the higher levels. Then you have "libraries" which mix interface and implementation access. These are somewhat meant for higher-order code to consume, but also need to be very effective dealing with the specifics of the system layer. Finally you have the "application" layer. This layer should be 100% interface driven. I can't see any reason why implementation details should leak into this layer, they should instead be in the library layer if your system layer isn't providing them.

I think if architects first demanded code be driven by the code layer (as I have defined it) and only then by the application layer, we'd get better enterprise code. My point is that I find it worse to see data-access layer code that has generic library and custom business logic mixed in together, than it is to have controllers with a bit of data-access and user-interface code mixed together.

Let me say that another way... I'd rather see application code that communicates with two different app-layers, but both through interfaces rather than implementations, than I would to see code that communicates with low-level library or system implementations and higher-level interfaces.

The concern was expressed that a Ruby class that implements part of its API dynamically via

method_missing?()

respond_to?()

respond_to?()

respond_to?()

StringIO and IO don't need to go back to the same superclass, because they don't share any commonalities except one: a set of methods they support.

Sometimes you really need to know whether something is implemented - and _how_ it's implemented.

class ISimpleORM(Interface):

	def do_orm_stuff(self, data):
		"worlds worst ORM interface"

class GenericPoorPerformingORM(object):
	implements(ISimpleORM)
	
	def do_orm_stuff(self, data):
		# bunch of implementation details

class MySQLSpecificORM(object)
	implements(ISimpleORM)
	
	def do_orm_stuff(self, data):
		# bunch of MySQL-specific implementation details

# registration (usually done in XML or with 'convention over configuration')
component.provideUtility(GenericPoorPerformingORM(), ISimpleORM, 'generic')
component.provideUtility(MySQLSpecificORM(), ISimpleORM, 'mysql-tuned')

# later on in your application code
ORM_IMPLEMENTATION = 'mysql-tuned'
orm = component.getUtility(ISimpleORM, ORM_IMPLEMENTATION)

I found traits to be a valuable concept in this matter.

www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTra...

It helps to construct classes by composing them from behavioral building blocks (called traits), so a class can respond to complete set of protocols without having to use inheritance as the fundametal tool for it.
It's not a concept to replace single inheritance but to complement it. Also helps a lot in code reuse.

It was already implemented in Squeak (an open source Smalltalk dialect) and IMHO is a promising concept.

Good paper.

Smalltalk's Traits is very similar to Python's zope.interface and Perl 6 is also applying the same concept and calling it Roles. They all differ somewhat in the details, but they all aim to solve the problem as eloquently stated in the Smalltalk paper, "The purpose of traits is to decompose classes into reusable building blocks by providing first-class representations for the different aspects of the behaviour of a class."

Please don't post messages like this. My whole office is staring at me because I burst out laughing and disturbed them.