Delegation Is Inheritance

Delegation Is Inheritance - a seminal paper by Lynn Andrea Stein, published in the proceedings of OOPSLA 1987.

Lynn demonstrates that delegation and inheritance are duals of each other, and "are alternate methods for incremental definition and sharing."

A link to this, anyone? I'm interested.

The paper is at portal.acm.org , you'll have to pay the ACM fee to access the full text.

Related Papers And Discussion

www.cs.virginia.edu

"Automated Delegation is a Viable Alternative to Multiple Inheritance in Class Based Languages", by John Viega, Paul Reynolds and Reimer Behrends. It doesn't say that Delegation Is Inheritance, indeed it concludes "... However, we have also shown that our mechanism has potential drawbacks generally not found in multiple inheritance mechanisms."

It may have been at one point in time a interesting opinion, but it is invalid. Delegation is less than inheritance. See:

citeseer.nj.nec.com

citeseer.nj.nec.com

The reason is that delegation is one way, while inheritance is recursive. When a method call is delegated if in the body of the method a virtual method is call, the virtual call will be resolved within the delegate and not within the larger object. The body of the delegated method does not have access to a proper virtual self (aka this) reference. So the delegated object cannot make use of virtual methods defined in the base object, there is no base object as a matter of fact in delegation.

The delegation mechanism must pass the receiver (self or this), implicitly or explicitly, to the method that implements the requested operation. Any difficulties that may be present in Cee Plus Plus (the references to "proper virtual self" in the above suggest a Cee Plus Plus environment) are specific to that environment.

Uh, don't forget the Self Language.

See Delegation And Consultation and the link therein for clarification on this point, especially with regard to "delegation" as used here versus "delegation" in the Design Patterns Book. The Self Language has shown conclusively that the distinction is artificial. Incidentally, the Cite Seer links above seem to be dead. -- J. Jakes-Schauer

This is really an implementation detail isn't it? It doesn't reflect on the concept of delegation in general. Whomever made the above references has a very narrow view of what delegation is. It's a strawman argument.

Also, the notion that this invalidates an opinion is ludicrous.

In my mind, general delegation is not only more powerful (as a programming tool) than inheritance (see Limits Of Hierarchies, Composition Instead Of Inheritance, and Alternate Object Oriented Programming View), it's the proper subject at hand, and focusing on inheritance as being somehow more fundamental is silly. Any given implementation of a delegation system may be lacking, as many people find inheritance, but that's a language-specific issue. The title of this page really strikes me as being a backward description of the issue, it should be Inheritance Is Delegation. Inheritance is not fundamental to OO, it's a Red Herring. -- Lucas Ackerman

Than please define what you think delegation is. Let's start with something concrete:

If the method call:

Is then resolved in the body of Target Class.method() to:

Then this is what is usually call delegation, especially if this is done for a set of method, not only one. As such this mechanism does not subsume inheritance. It does not meet the semantics of inheritance as specified in the papers cited above. If you have other ideas please clarify.

[I'm not that guy, but let me jump in. You are assuming that all delegation is manual. Delegation like that is automatic in prototype systems.

This is the same as what you would do manually, but is equal to inheritance, because object 1 has all object2's methods, but uses the correct this pointer to itself.]

I am that guy, and I would call this an example of explicit, manual delegation. Let's move this discussion to What Is Delegation. -- Lucas Ackerman

I agree with Lucas, Inheritance is simply one implementation of delegation. Delegation is the fundamental principle here. Inheritance and Prototypes are both implementations of a delegation mechanism, but it's delegation in general that's needed for OO, either implementation fulfills this requirement.

Can delegation without polymorphism be considered OO?

Of course. Consider that composition tends to do manual delegation, yet it's still very much OO. It's the concept of delegating behavior to objects that can handle the request the best, while hiding that knowledge from the client, that is fundamental to OO, regardless of how the delegation is implemented, it's still OO. Delegation could be via inheritance, prototyping, or manually written, doesn't matter, it's still OO. You can write OO code in assembly, as long as you keep the code structured around these kinds of higher level concepts.

Any functional or procedural program does the same thing. What distinguishes OO from any other language where one calls other things to implement something?

Because procedural and functional don't call other "things", they call procedures and functions, which don't maintain their own state and identity. OO code makes calls to entities that manage their own behavior, they call "things". Polymorphism is still fundamental to OO, I just said it wasn't fundamental to delegation, IMHO. OO calls don't have to pass around a bunch of state, they just send messages, often times with no arguments whatsoever. This makes programming easier, I can just tell the "things" what to do, without having to give them the knowledge "data" to do it on each call.

Seems somewhat an artificial distinction. From the interface POV if i delegate to a function or another object it is the same. Delegation then is more fundamental than OO.

It's not the same. If you delegate to a function or a procedure, you must pass it state somehow, i.e. parameters. If you delegate to an object, you don't have to pass anything; it already has its state. There's a huge difference between this:

and this:

I bloated the number of params to make the point.

[Delegation can model inheritance; though there are good reasons to include "real" inheritance rather than use delegation everywhere. Delegation cannot, in a statically-typed language, replace polymorphism.]

Polymorphism is a different topic, it isn't really related to inheritance and delegation at the conceptual level. Polymorphism is about substitutability, delegation and inheritance are about sharing code and responsibility, just because some poor languages (C++) make them the same doesn't mean they are.

[It ain't just C++, it's Java Language, Eiffel Language, and even Smalltalk Language. If class A is declared to have B as its supertype in all four - A gets all the features of B (unless it overrides them) and an instance of A can be substituted where an instance of B is expected. None of them provide subtyping-without-subclassing(Not true, java's interfaces allow subtyping without subclassing, and Smalltalk does too since everything is polymorphic by nature), though for Smalltalk (being dynamically typed) the point is moot. Java comes close with its interfaces, but you can't "implement" a full-fledged class, only "extend" it. Only one of those languages provides a way to subclass without subtyping - guess which one? That's right, C++. It's a rarely-used feature, but private inheritance gives you subclassing without subtyping. (It has the drawback that you have to redeclare any methods defined as public in the source class as public in the derived class). Think of private inheritance as anonymous composition, and you'll be close.]

Yes, but Java, C#, VB, any COM enabled language, and a host of dynamic languages can and do treat polymorphism as a separate concept. Methods can be polymorphic without having any classes in common. It really is a separate issue. Object can be of the same type(think interfaces)... without having any parent classes in common. Like I said before, some languages confuse the concepts by tying them together, but that doesn't mean you have to think of it that way, conceptually they are different concepts.

[Bertrand Meyer argues in Object Oriented Software Construction that inheritance is all you really need; and that separation of subtyping and subclassing (implementation reuse) is not a good idea. I don't really agree with all of his position; on the other hand I think inheritance, properly implemented, is a useful and necessary construct in an OO language. It can be modeled with delegation and composition, but the result is less satisfactory.]

You are making assumptions about how state is managed and then saying that's the only way. If I call a function it's not my place to know how it is managing state. You certainly don't need to assume all the args are passed around. It could be in a tree that part of a module, in a functional language.

But don't you see, state management is the issue; it's what separates the different paradigms. Functions in the functional sense depend entirely on the value of their parameters and have no effect on the program other than what they return, otherwise it's a procedure, not a function. Functions don't rely on state outside of their parameters or have any side effects. If the procedure is depending on or modifying state existing somewhere, like an array or struct or something in a well known location, well, that's how OO got invented: by formalizing the concept of the "where", by making the "where" into the object. [That's a good description of module-based programming, actually, as found in Modula-2 and earlier versions of Ada. OO is a superset--bringing things like polymorphism and subtyping into the mix. The whole delegation/inheritance thing applies to OO, but not much so to module-based programming.]

In a dynamic language you also have to call something that knows what else to call. If that's defined by inheritance or in a class interface, it's essentially the same thing.

But don't you see, state management is the issue; it's what separates the different paradigms. Functions in the functional sense depend entirely on the value of their parameters and have no effect on the program other than what they return, otherwise it's a procedure, not a function. Functions don't rely on state outside of their parameters or have any side effects.

A pure functional language is your only option in the functional language world.

But not all languages that support functional programming are purely functional. Java Script, Lisp to name two, so that's not true.

Functions in the functional sense depend entirely on the value of their parameters and have no effect on the program other than what they return, otherwise it's a procedure, not a function. Functions don't rely on state outside of their parameters or have any side effects.

In a language with Multi Methods, foo.doSomething() is isomorphic [is that the right term?] to doSomething(foo). Also, in C++, foo.doSomething() is isomorphic to Runtime Class Of(foo)::doSomething_impl(foo) or foo->_vtable_->doSomething(foo).

That is to say, the method does take a parameter, it takes its current object.

So, what's to stop you from doing

Delegation in methods. Shared state between objects. Problem solved.x

See also: Poly Morphism, What Is Delegation, Different Styles Of Delegation, Prototype Based Programming, Delegation In Smalltalk, Self Language

Category Paper Category Polymorphism

See original on c2.com