The Gang of Four book is wrong about delegation (2012)
saturnflyer.com
The Gang of Four book is wrong about delegation (2012)
1–10 of 26 posts
Re: The Gang of Four book is wrong about delegation (2012)
#2I'd hate to be the Gang of Four, especially since they wrote their book 20 years ago. Since then numerous people (including myself) have discussed how to evolve some of their ideas given today's landscape.
My position is many ideas are still valid in their book, but they are less novel today and are often implemented with simpler tools. I'm sure the Gang would concur.
Other ideas may be less valid over time and I'd be surprised if the team didn't grow in their perspective.
Re: The Gang of Four book is wrong about delegation (2012)
#3> If the message is delegated further, all questions about the values of variables or requests to reply to messages are all inferred to the object that delegated the message in the first place.
I'm not sure how the author jumps from that quote to:
> When that object delegates to another, then any reference to "self" always refers to the original message recipient. Always.
The high-order bit is that the delegating object can be interrogated for more information or context (and a reference to that object can be forwarded to further delegates), no? Why does that need to be implemented by re-binding whatever keyword or name an object calls itself to a different object?
Re: The Gang of Four book is wrong about delegation (2012)
#4Whole OOP is "wrong". It was "right" up to about early 90ies, given the average application size and hardware. The moment CPU's started scaling with cores and CPU started running hundreds of instructions per memory read, and applications started being bigger than few tens of KB - cornerstones of OOP (dynamic polymorphism, code attached to data, per-object access control) started actively working against developers.
Re: The Gang of Four book is wrong about delegation (2012)
#5I'd hate to be the Gang of Four, especially since they wrote their book 20 years ago. Since then numerous people (including myself) have discussed how to evolve some of their ideas given today's landscape. My position is many ideas are still valid in their book, but they are less novel today and are often implemented with simpler tools. I'm sure the Gang would concur. Other ideas may be less valid over time and I'd b…
I forget who said it, but I ascribe to the notion that most design patterns exist to work around insufficiencies in languages or ecosystems. To that end, a lot of them totally still exist--they've just been reduced in difficulty and ceremony, as you mention. The command pattern, for example, is literally just a closure.
Re: The Gang of Four book is wrong about delegation (2012)
#6I think the example gets bogged down in language features which obscures the conceptual idea.
Hence I think the example would best be illustrated using pseudocode, which would perhaps motivate a meaningful discussion of how language features make certain patterns more or less useful, and perhaps, zooming out, certain designs more or less easy to reason about.
Re: The Gang of Four book is wrong about delegation (2012)
#7I'd hate to be the Gang of Four, especially since they wrote their book 20 years ago. Since then numerous people (including myself) have discussed how to evolve some of their ideas given today's landscape. My position is many ideas are still valid in their book, but they are less novel today and are often implemented with simpler tools. I'm sure the Gang would concur. Other ideas may be less valid over time and I'd b…
> I'm sure the Gang would concur.
I'm pretty sure this is the case. I think that the ideas are great in producing a vocabulary for classes of structures within software architecture the way people creating a car can talk about gears, rotors, pistons, gaskets.
Whether or not you have the right rotor/gears/gasket/piston is up to the specific case. And sure some of those things may become like carburetors, and may become largely obsolete. But there is definitely a value in having a consistent vocabulary for things like "That box that controls the air-fuel-ratio mixture before it goes into the cylinder."
Re: The Gang of Four book is wrong about delegation (2012)
#8The Gang of Four book is terrible. The explanation are very unclear (often because of excessive abstraction, even in the description and discussion).
It's been a long time so my memory is hazy on its particular sins, but I've vowed never to touch it again. I never understood what anyone saw in that book (except that it was one of the first book on the topic of design patterns).
Re: The Gang of Four book is wrong about delegation (2012)
#9Perhaps a better way to explain "delegation" would be to say that it means "borrowing a method from some other object then executing it in the context of the borrower.
In O-O the "context" in particular refers to the "message recipient" available as the value of the pseudo-variable 'this' (or 'self' in Smalltalk).
To delegate = To borrow a method. Delegator = Borrower. Delegate = Lender.
Re: The Gang of Four book is wrong about delegation (2012)
#10> If the message is delegated further, all questions about the values of variables or requests to reply to messages are all inferred to the object that delegated the message in the first place. I'm not sure how the author jumps from that quote to: > When that object delegates to another, then any reference to "self" always refers to the original message recipient. Always. The high-order bit is that the delegating obj…
That is probably because what he and we are talking about here is the technical definition of "delegation".
If you just call a method of another object and then that object perhaps but not necessarily sends some messages back to the original sender, to get further information, that could conceptually be seen as "delegation". But technically that's just normal (bi-directional) message-exchange.
"Delegation" needs to refer to something more technically specific to warrant its existence as a technical concept.