From the POD of Class::Interface:

Polymorphism is a fundamental building block of object orientation. Any two objects that implement the same interface can receive the same methods -- they may be substituted for each other, regardless of their internal implementations.

Much of the introductory literature explains this concept in terms of inheritance. While inheritance is one way for two different classes to provide different behavior for the same interface, it is not the only way. Perl modules such as the DBDs or Test::MockObject prove that classes do not have to inherit from a common ancestor to be polymorphically equivalent.

Class::Interface provides an alternative to isa.

Instead of requiring that objects inherit from an expected class, consider requiring merely that they implement the expected interface.

I think inheritance is overused. Scanning various forums and some of the better programming and design books, it appears that other people agree. Consider two classes -- Airport and Arcade. An Airport can contain an Arcade. This is a composition arrangement.

If we followed the "traditional" inheritance scheme, any code that wanted to make sure it was accessing an Arcade correctly would check to see if the object is an Arcade. This is a problem for our scheme -- there's no good reason to say that an Airport is an Arcade. We might solve this by creating a superclass of both Airport and Arcade, but that's a mess.

I'd personally rather say "Make sure this object can handle any message I can send an Arcade." Since the Airport contains an Arcade, it will just delegate methods like collect_quarters and play_annoying_dance_music to the Arcade it contains.

The code that would otherwise do the checking to see if it's dealing with an Arcade object now does something slightly differently. It now checks to see if the object has declared that it implements the same interface as an Arcade object. It's a slight different of semantics, but it opens lots of other doors.

Of course, if you do subclass Arcade, things work just fine. A subclass automatically implements the same interface as its parent. Or parents. Or any of its ancestors.

I welcome any and all suggestions on the module, from its naming to implementation to tests and documentation.

Update: clarified title per Aristotle's suggestion