Just to clarify, this page is about what delegation means in general (and in programming). It is on the fundamental aspects of the nature of delegation, and not the specifics of any particular implementation. With respect to OOP, delegation often refers to a specific PrototypeBasedProgramming mechanism, and that is not what's being discussed here. DifferentStylesOfDelegation is on that topic, and ConfusionAboutInheritance belongs on its own page. ---- On DelegationIsInheritance, the following question was posed. ''Than please define what you think delegation is. Let's start with something concrete:'' ''If the method call:'' targetObject.method(x1,x2,...,x_n) ''Is then resolved in the body of TargetClass.method() to:'' delegate.method(x1,x2,...,x_n) ''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 would call this an example of explicit, manual delegation. In my book, delegation is pretty much what you'd find in a dictionary: entrusting an action to another agent or representative. I don't care how it's done, or who the delegatee is. If something is understood to be placed in the hands of another party, it's delegation. Inheritance is often used to delegate state and interface definition. ''But not always. The general case is that a derived class '''cooperates''' (through the use of virtual method calls) with all the base classes in its hierarchy to realize a specific behaviour. A method call can be resolved in the body of a base class, which can further call another virtual method that may be resolved up the hierarchy.'' [sorry, but this is still a form of delegation (per the above definition), and this cooperation up (or down) class hierarchies is another good example of it -Lucas] For example, in class/inheritance based languages, a class may delegate some actions and state to it's super-class, and possibly others to its derived classes. In a PrototypeBasedLanguage, an object delegates unspecified behaviors to it's proto-object. In a serious ComponentBasedLanguage, an object might have automagic internal delegation, where it's sub-components decide what events are delegated to themselves (this is my dream language, I'm working on it). [sidetrack removed, ConfusionAboutInheritance is now on its own page] Let me state a theory: polymorphic behavior is always delegation of some sort, and thus delegation (to impliment polymorphism) always has a layer of indirection. Please find a problem here, so we can make this more succinct/correct, or dis/prove it. Lets also try to say what delegation is NOT. From my above theory, a simple subroutine may have responsibility for the computation of some part of a program, but a subroutine call is not delegation because it is direct. It lacks a layer of indirection. A function-pointer IS however, since it can point to any function, and the decision of what function it points to must already have been made when it is dereferenced and called. Even a switch/case statement can be delegation, provided it adds a layer of indirection. So what does OO and polymorphic behavior have to do with delegation, if delegation is such a simple, ubiquitous thing? Perhaps this is the real core of the matter. OO is about resolving polymorphic behavior by delegating to objects. -- LucasAckerman ''''But polymorphism and inheritance are different things. Yes it depends on what you want your OO to be, but it does not help to subvert the meaning of inheritance as others have used it a long time. Therefore DelegationIsInheritance may be misleading. --Costin'' I agree Costin, and have no intention to subvert the meaning of inheritance. I just think we ought to recognize that the mechanisms of inheritance (in all their various forms) perform a kind of delegation to achieve their results. Saying DelegationIsInheritance is definitely misleading, as I noted on that page. However, polymorphism depends (according to my theoretical definition above) on some form of delegation taking place. Does NonPolymorphicInheritance exist? Incidentally, my father made this astute observation about delegation: you can delegate authority, but you can NOT delegate responsibility. This follows from the meaning of responsibility, not from delegation. Whether this is meaningful relative to programming is perhaps a matter of personal viewpoint. -- LucasAckerman ---- Lets turn up the intensity here one more notch: supposing PolyMorphism is delegation with indirection, what is the simplest possible delegation? How do we establish a baseline for it without invoking indirection? Perhaps simple subroutines, procedure calls, macro expansions, or #include directives are minimal delegation. How do we then distinguish delegation from basic DivideAndConquer? ''Maybe it's on the same fundamental level.'' YouCanSolveAnyProblemWithAnotherLevelOfIndirection - so lets tackle the real issue here. In a literal sense, indirection is accomplished by manipulation of addresses. This indicates that indirection changes behavior. Suppose we say delegation dispatches on desired action, while indirection introduces new behavior. Better yet: delegation is done by the caller, while indirection is a function of (dispatch to) the callee. Does this sufficiently clarify polymorphism, delegation, and indirection? -- LucasAckerman ---- Result = Process(Data) * What are you trying to say? That's no different than if you had just written "computation"; too vague to mean much on any page here, let alone this one. That says nothing about delegation per se. ---- If a regular procedure call is Result = Process(Data) then delegation is introducing a new intermediary called Delegate so that the same function can be performed this way: Result = Delegate(process, data) -- DaveEaton ''I have never seen delegation expressed this way in ProceduralProgramming. What does "process" represent as parameter? A function pointer? [Yes, as in lambda calculus.] A selector?'' ''I have seen delegation expressed:'' procedure Process(Data) { // perhaps some specific pre- or post-processing return DelegateProcess(Data) } ---- Delegation is assigning the task to another in order to allow you to continue with your primary task without being distracted. In source code, the distraction is the intricacy of the delegated task. No matter which programming paradigm we are in, the delegation can always be conceived of in the above form. And good delegation in source does achieve ClearEncapsulation, where I also used the above. The implication is that delegation equals ClearEncapsulation, but it is only good delegation which achieves this. I do not know how to address your assertion of vagueness - if it does not fit here, that's fine. It is Wiki after all. * Your paragraph of explanation here is coherent/understandable. The problem seems to be when you are overly brief, you do not recognize the resulting ambiguity and vagueness. "Result = Process(Data)" could describe absolutely any computation at all, not just delegation, and hence communicated essentially nothing, unlike your paragraph of explanatory text. If your point is that all computation is delegation, say so (although I think such a definition would meet some resistance, despite a possible philosophical germ of truth). * Note that "delegation" is both a non-technical word as well as technical jargon. I see that you've been thinking hard about delegation for decades, but it is unclear to me that your use of the word is the same as the widespread technical use, despite your use being fine in regards to the non-technical definition. If my impression is correct, then I believe you will have misunderstandings with others who do not follow your usage. Of course, there are squabbles about the precise technical definition as well (hence this page), but there are some major camps, not just idiosyncratic definitions. ** Your beliefs are unfortunately accurate. I wish everybody else would get in step. ---- Doesn't delegation imply in some way that there should somewhere be a definition of the work that must be performed, or at least the inputs and outputs that are required? I know this could also be construed as being to general, but there is also the implication that any number of agents can complete the work. Rather than saying the particular agent X can perform work function Y, you are saying here is work function Y, who wants to do it? * In software, the delegates have been carefully chosen by the designer. In software, delegation is done with the confident expectation that the delegated task will be achieved. The programmer usually has absolute blind faith that the current call will succeed. But i like your concept of throwing process Y out there for somebody to resolve. It is true that the delegator does not care how the delegate achieves its task. -- PeterLynch ---- See also: DifferentStylesOfDelegation, DelegationIsInheritance (it is not!), PolymorphismAndInheritance, DelegatorIsDelegationInJava ---- CategoryObjectOrientation