in reply to Class::Interface -- isa() Considered Harmful

I think you're solving a problem that doesn't exist. Java needs interfaces because it has no multiple inheritance. In Perl, you can just make a class that shows the abstract interface, and have everything that implements that interface inherit from it. You don't even need to put anything in the interface class. It can be totally abstract, or it can implement the methods by throwing an error that says "you were supposed to implement this in your class" as I've seen Damian Conway suggest.

I also agree with castaway that your example doesn't really make sense. An Airport that contains an Arcade does not implement the Arcade interface itself, so of course it won't inherit from Arcade.

  • Comment on Re: Class::Interface -- isa() Considered Harmful

Replies are listed 'Best First'.
Re: Re: Class::Interface -- isa() Considered Harmful
by chromatic (Archbishop) on Jan 16, 2003 at 18:57 UTC

    Inheritance is by no means the only way of constructing classes. I'm looking for a scheme by which I can say "this object can receive these messages". I don't want it tied to inheritance, except that I want subclasses to be marked as implementing their parents' interfaces.

    I think Java got it wrong in this case.

    My example (which is not great, and that leads to the confusion), I imagine that the Arcade interface has a couple of methods: collect_quarters() and play_annoying_dance_music(). Whenever a Person walks by, it should play the annoying music. Whenever a FranchiseOwner or Hoodlum walks by, he should be able to collect quarters. It oughtn't matter if the Arcade is alone on the street, in a Mall, or in the Airport. If the actor is near something that implements the Arcade interface, he should have the option of listening to the annoying dance music or collecting quarters.

    If the only option I have is inheritance, that power is lost to me. It's as if I wanted to make a Car that could throw_hubcap(), so Car had to inherit from Wheel. What happens when I want HoverCar?

[reply]
[d/l]
[select]
      It looks to me like you're getting things from inheritance and containers mixed together. An Airport may contain an Arcade, but it would not implement collect_quarters() any more than a Directory class would implement the methods of a File class. If you want to do something with the arcade, you qould query the Airport with a get_arcade() or something, and then operate on the returned Arcade object.

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

[reply]
        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.

[reply]

      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.

[reply]
[d/l]
[select]

        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)
[reply]
[d/l]
[select]

In Section Meditations