Talk:Delegation pattern

Language election

Is Kotlin the most appropriate language for the example? What criteria were used to choose it? I think languages based in C syntax are more common, so programmers are more likely to understand the example. Be it C++, C#, or even ES6. — Preceding unsigned comment added by 195.57.119.44 (talk) 13:16, 14 March 2018 (UTC)

Delegation vs. Adapter Pattern

I've read the GOF book and I don't see why this is considered a pattern. The object adapter pattern in GOF sounds identical to this. Am I missing something? [5 March 2012]

Examples

I think the proliferation of examples is problematic. I think the following issues need to be considered,addressed.

• Are two Java examples necessary.
• Are C++ and Objective C examples necessary.
• All example languages are similar, where are the examples in functional or declarative languages, or even a notational example e.g. UML.
• Perhaps all programming languages should use a consistent example.

MartinSpamer (talk) 11:47, 17 December 2007 (UTC) - All examples must related to the same problem. If someone is trying to understand it using 2 languages, it becomes a challenge. —Preceding unsigned comment added by 121.242.104.67 (talk) 07:55, 2 June 2010 (UTC)

Agreed! A couple of examples, one simple and one complex case, in ONE programming language would be enough! Too many examples actually pollute this page! 200.32.121.66 (talk) 15:25, 5 July 2012 (UTC)

Removed all the examples except the Java one. The rest where mostly syntactic variants. Qwertyus (talk) 16:13, 11 September 2012 (UTC)

The Ruby example (whilst trying to be extra smart) is not really helpful in explaing the concept of delegation. A::f() and B::f() should not be the same (virtual) function at all. — Preceding unsigned comment added by 79.247.184.225 (talk) 23:44, 7 August 2012 (UTC)

Delegation vs. Proxy pattern

The Delegation and Proxy pattern, as well as the Strategy pattern, all look very much alike. Some more information in the differences and similarities between those two patterns would be welcome here. Avernet 18:54 19 Jun 2003 (UTC)

They are similar. I would classify Proxy to be a specialisation of the more general delegation pattern. In the Proxy both the Subject and the Proxy conform to the same interface, this isn't the case with delegation. MartinSpamer —Preceding unsigned comment added by MartinSpamer (talk • contribs) 12:31, August 29, 2007 (UTC)

I've heard a lot of people talking about the ‘delegation’ pattern lately. I wondered why? It's not a classic GOF pattern. There might be a few legitimate reasons to use it, but I've yet to hear a compelling reason. Unlike the ‘proxy’ pattern which serves a legitimate purpose, the ‘delegation’ pattern seems like a code bloating anti-pattern to me. Why is it so popular? I just bought Wiley's Patterns in Java Volume 1. Sure enough, it's the first pattern listed. Ah!

You are right to say that it's not a classic GOF pattern. The GOF book considers delegation to be a technique that forms a building block for several patterns (e.g. State, Strategy, Visitor), rather than a pattern in itself. There's a section on Delegation in the introduction of the GOF book. —Preceding unsigned comment added by 194.133.18.67 (talk) 08:18, 3 April 2008 (UTC)

Observations

The criticisms section is making non-submissible arguments.

The criticism is based on the observation that an incorrect implementation may not work correctly. This is a tautology and holds for any code in any language. If the design pattern was complicated to the extent that writing a correct implementation is considered difficult, then that would be a valid criticism.

Also I suggest an 'applicability' section describing an example of where this pattern may be preferable to an alternative such as standard OO inheritance, and perhaps a case where this pattern is less-preferable than an alternative pattern etc..

<KRC 2009-07-25 15:50> I'm not sure what the ettiqute is for making comment comment here, so forigve me if I've done the wrong thing by editing an existing comment to append my own.

I strongly agree with the suggestion that "an 'applicability' section" would be most useful. I would suggest that downside of all patterns is that noobs have a tendancy to throw them in willy-nilly, where it's not appropriate.

Also: I personally don't care if GOF considers Delegation to be a "full blown" pattern, or just a technique... the arguement is mue... Delegation is a very useful and commonly used coding paradigm and IMHO it should be covered herein, regardless of it's position in the pop-chart.

Also: Yes, I agree that there are probably too many examples for an encylopedia entry... though it would be terribly nice to see them ALL taken offline, and linked to. Probably one code example would do (roll a dice to decide which language, most programmers can read most languages anyways)... and yes I do think a UML diagram would be a good idea... UML shows "abstract patterns" cleanly, without any of the common language hang-ups. </KRC>

Applicabilty

I added an applicabilty section in PHP. Feel free to switch this to something more mainstream such as java or C++. This should clarify the use of this pattern and also clear up any confusion between this and the proxy pattern.

I browsed through the various patterns on wikipedia and found the majority of the text borderline useless and confusing. Additionally there are very few discussions on how a particular pattern might be applied to solve a real world problem.

Please comment on the usefulness/clearness of my applicability example. Should it be decent I'll go ahead and start working on the other patterns as well. --Begby 18:10, 2 March 2006 (UTC)

Suggest merge with Delegation (programming)

The node Delegation (programming) talks at length about the Delegation pattern, yet Delegation pattern already has its own node. Shouldn't they be merged? --Devnevyn 12:47, 11 August 2007 (UTC)

ObjC example

Hmm. I added an example for Objective-C. Since they call it 'delegates', I assumed it was the delegation pattern. However, after actually RTFA I realize that it doesn't seem to be at all the same. Does anyone know what my code is actually a pattern of, so that I can move it to a more appropriate place? Or does it actually fit here? --Devnevyn 13:19, 11 August 2007 (UTC)

This and pimpl

Isn't this just a more general case of Opaque_pointer. If so, maybe some information linking the two should be present. 202.10.86.59 11:42, 31 October 2007 (UTC)

Motivation and use

I cannot extract from the article when it's best to use this pattern. Can someone give a motivation or an example in which situation it's good to use this pattern. I know that it in Java e.g. it's used by swing. But I don't know with which aim. Maybe it would be good, to add an motivation section to the article. 80.144.128.176 (talk) 10:25, 11 March 2008 (UTC)

I found this, which makes it a little clearer: http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/delegation.html

80.144.128.176 (talk) 10:54, 11 March 2008 (UTC)

Overlaps with Strategy pattern

Aren't these two basically the same? 138.246.7.155 (talk) 13:14, 6 November 2008 (UTC)

Actually they are not.

The Strategy pattern basically abstracts the implementations from the caller. The caller needs to know of new implementations. The implementations are instantiated, in a strategy pattern.

The Delegation pattern basically points the correct implementation that needs to be used, there by also abstracting the instantiation of the implementation too.

Both these patterns are to be used by considering the "thought" process behind the usage. Code wise its easy to say, I can use one or the other. But if you review the thought process you will realize that the Delegation pattern is to be used when we need the instantiation also taken care of by, lets say, the library. The Strategy pattern basically goes with the thought process of choice provided by the library of just a new protocol/algorithm.Basically when we use multiple libraries that provide new algorithms (and no way of switching between them). So here you have control of "instantiation". Hope I was able to add some value in this discussion. —Preceding unsigned comment added by 121.242.104.67 (talk) 08:04, 2 June 2010 (UTC)<SiddharthDOTJagtianiATTHEGMAILDOTCOM> <!Template:UnsignedIP -->

This is not correct. The GoF Strategy pattern does not describe the mechanism that a client uses to select a particular strategy. Nor does it guarantee that the set of strategies is open-ended. The "Complex" delegation example uses an interface, has multiple implementations of an algorithm, and allows the client to select which algorithm to use. That pretty much fits the GoF definition of Strategy.

It is probably wrong to try to say that Strategy and Delegation have no overlap. Delegation is a technique that underlies many other design patterns. In fact, I would say that it is too primitive to be called a pattern, but that's my opinion, and I'm sure that many others would disagree. Bytecrafter (talk) 13:42, 28 December 2012 (UTC)

Inversion of Responsibility?

The first paragraph states "It passes the buck, so to speak (technically, an Inversion of Responsibility)." but there is nothing intrinsic to delegation that means any responsibility is inverted. Delegation is one way in which inversion of control can be implemented but they are not the same thing nor necessarily linked. Can we take this bit out? Kylotan (talk) 18:29, 15 April 2011 (UTC)

Seconded

I agree with this. Inversion of control really refers to object composition (how is the object created at run time), while this article is meant to describe the behavior of an object within the context of its responsibilities Helios2k6 (talk) 20:54, 21 February 2013 (UTC)

Which DP category does it belongs to?

Galzigler (talk) 21:55, 19 June 2017 (UTC)

Content needs restructuring

This article is backwards. It first talks about how specific languages handle the pattern and then offers a definition of the pattern afterward.

Suggested Structure

• Keep first sentence as is.
• Move all the text of the Definition section to follow the first sentence, removing the Definition section heading in the process.
• With the Definition section now gone, create two new sections, "Example" and "Language Support"
• The Example section contains the Kotlin example and the sentence that precedes it.
• The Language Support section contains the sentence following the Kotlin example and at least the first four sentences of the paragraph that follows it.
• The final sentence in that paragraph does not seem to belong in the paragraph at all, since it is not about language support. Suggest moving it to follow the definition and immediately precede the "Example" section.

— Preceding unsigned comment added by Roobyroo (talk • contribs) 16:01, 28 June 2017 (UTC)

Example is not delegation, but forwarding

The example given for the delegation pattern is not actually delegation, but forwarding. The sender isn't being passed as an argument to the delegate, as the article seems to suggest would be characteristic of the delegation pattern, and the called method has no access to the original sender. I would suggest replacing the existing example with an example in Lua, partially because it's easy to read, and partially because the delegation pattern is common in Lua. rdococ... (talk) 06:57, 25 April 2019 (UTC)

I was going to raise a topic on this, but you nailed it. The example is indeed Forwarding (object-oriented programming), and a good one at that. D98dbu (talk) 12:22, 23 December 2023 (UTC)