Same deal with the Car interface: $car->get_wheel->throw_hubcap(). Inheritance doesn't enter it, and neither does sharing interfaces.

Ah, Perrin you wrote exactly what I was just thinking.. I also can't see why an Airport should be able to directly respond to Arcade methods.. if a Person walks by, it should just do 'getArcade()->addPerson(personobj) and let the Arcade deal with it.. Absolutely no need to do anything else, in my opinion.


C.

1. The form of multiple inheritance that Java permits is inheritance of interface only. This is not the same as saying that Java provides interfaces in lieu of multiple inheritance.
   
   
2. Subclasses "marked as implementing their parents' interfaces" by definition are built from inheritance.
   
   
3. The only way to "implement an interface" without inheritance -- which is a contradiction in terms because class interfaces convey type -- is to write a class that serves as a wrapper around another class. In this case you've got redundant interfaces leading to the sullying of the outer interface (there's no reason why an Airport should have a public method collect_quarters just in case it contains an Arcade. Are Airports without Arcades different kinds of objects?), when what you really want is what castaway suggested above; namely an accessor that returns a reference to the contained object. The interface of Arcade should contain methods that take a Person or a FranchiseOwner or whatever and decide what to do based upon the type of object passed in.

All of these examples so far are problems just because the object models themselves are poorly thought out. A Car is not a subclass of Wheel, but more appropriately WheeledVehicle, and a HoverCar is not properly considered a subclass of a normal Car, but probably something like AmphibiousVehicle. As long as such difficulties can be solved by reworking the object model, I don't see any reason to introduce a new and awkward concept of the class interface.

Since both you and perrin have responded among similar lines, it seems that my examples are unclear and aren't communicating very well. Let me address your points in order and see if I can clear up my intent.

1. It is my opinion that Java provides interfaces in lieu of multiple inheritance. I think that's a lousy special case that doesn't address the real issue. (I find myself saying that about Java quite often.)
2. I agree very much. I think that that addresses the real issue backwards, however. My code shouldn't have to care whether it's dealing with an object that isa specific type. I'd much rather have it check to see that it can act as a specific type.
3. I disagree that the only way to implement an interface without inheritance is to write a wrapper. I've got a generic mock object that implements any interface you can imagine without wrapping at all. What I lack is a way to say, "Does this object act as if it were an object of this type?"

My goal is twofold:

• I'd like to be able to check that an object I receive from somewhere can handle the operations I'm about to perform on it
• I'd like that check not to dictate the object's implementation of those operations
Read more... (2 kB)

Okay, the problem then is that we've got different definitions of what an interface is. For me, coming from C++ and Java, the technical definition of an interface is an abstract superclass that provides only static data members, abstract method declarations, and that indicates an is-a relationship. To quote from Java in a Nutshell: "When you define an interface, you are creating a new reference type, just as you are when you define a class." (p. 112).

What you're talking about is behavior without association to a reference type. You essentially want a list of things that an object can do with its type information stripped away. In this sense, bart's suggestion to use can seems very close to what you want, as dws's astute observation that different classes may "mean" different things by similarly named methods is only relevant insofar as you're concerned with is-a relationships and getting one particular class-specific behavior. If your Test::MockObject is the prototypical application for this idea then I think using can is fine, as the objective there is, inasmuch as I can gather from a quick perusal, to isolate the code you're testing from other dependencies. This is a great idea, and it's much better than the one-off approach I've sometimes had to use in temporarily redefining methods just to report back some placeholder information. Nonetheless, I must cling to the belief for the time being at least that "real" code going into production or publication would suffer greatly in terms of maintainability from this sort of thing. And in that sense fixing the object model is almost always going to be preferrable to warping inheritance chains.

Due to the substantial precedence for associating interfaces with reference types, I think a different term would be helpful here. It sounds like what you want is shorthand for grouping a set of methods together into a set, but one not unified by type. Maybe "possible behaviors" would suffice?