The Gang of Four book is wrong about delegation (2012)
saturnflyer.com
saturnflyer.com
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.
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."
The concept of design patterns is highly useful. The particular patterns in one book would always be of limited usefulness. Often times devs are more eager to prove their smarts than to get a job done well.
That's such a good quote, I just may copy + paste it mindlessly into my next presentation and assert it with zeal. (With credit of course)
Sure it can. The syntax is a little different, though. And there are a few ways to do it. Here's one:
#include <iostream>
#include <functional>
struct Container {
template <typename Self>
void announce(Self const & self) const
{
std::cout << "these are my things: "
<< self.things << '\n';
}
};
struct Bucket {
std::string things;
std::function <void()> announce;
template <typename Delegate>
explicit Bucket(
Delegate const & delegate,
std::string const& aThings) :
things(aThings),
announce([&](){ delegate.announce(*this); } )
{ }
};
int main()
{
// Container works with anything with a 'things'
// attribute
Container container;
// Bucket takes anything with an announce method
// that accepts a Bucket-like object
Bucket bucket(
container,
"planes, trains, and automobiles"
);
bucket.announce();
return 0;
}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?
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.
It may not seem novel now, but it was not obvious to everyone at that time that this was a possible design-pattern.
The Gand of four wrote Design patterns for the inhertance-based world, because that was what was churning out most business software and had the biggest need for some standard patterns and conventions. And they used (reused?) the word delegation to fit a useful pattern in a non-prototypical language.
And AFACT that's his argument. That all modern OOP languages got it wrong. So they got delegation wrong too. And GOF got it wrong because the wrote it for modern OOP.
Or did I miss anything?
As far as I follow it, the argument is that delegation means, in prototype-based OO (apparently the only context in which either author recognizes its use), that if an object has no method for handling a message that it has received, then it transitively searches through its prototypes for one that can handle it, and if found, the receiving object delegates the message to that prototype's method for handling. When that method handles it, however, it should do so in a way that is aware of the context of the object originally receiving the message, so that, for example, if both the receiving and handling object have a name, the handler should use the receiver's name if it needs a name in handling the message.
If we assume that the methods reference the context they are working with through a variable called 'self', then passing the handling method a 'self' bound to the original message receiver (not necessarily the most recent delegator) will achieve this: any method calls or references the handler needs to make will go through the same delegation process, starting from the original receiver, and in so doing possibly, but not necessarily, ending up at a method from the same object as was picked to handle the original message.
There may be the additional implication that this greatly facilitates composition, which is (it is claimed) preferable to inheritance, but I would think name collisions are a problem.
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.
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.
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).
I don't agree. It's a seminal book which, in spite of having been released about 2 decades ago, is still required reading. The book also is well suited as a reference due to their clear explanations, descriptions, and use-cases.
I guess it was mostly due to my inexperience in software design in general. I haven't tried to read it again since then, but I'm sure by now I'd at least understand some of the words in there :) So I wouldn't recommend it for beginners, but I think even experienced developers could still learn something new.
But then I switched from Java to Ruby, and half of the design patterns were completely irrelevant. And I had other problems for which I didn't have appropriate design patterns.
I think the Gang of Four book's target audience is far narrower than it's often been interpreted. It's meant for intermediate C++ programmers. People who have already run into a number of these problems that C++ doesn't really handle well, and now here's a book that helps you around those limitations.
I guess it also works well for older Java versions, but it's not universal. Many patterns are completely irrelevant for some languages, because those languages have easier ways to do that. Many languages have other shortcomings that are not handled in that book.
Maybe there's another target audience for that book: language designers. Design your language so nobody needs these patterns. Have built-in constructs that handle this stuff in an easy way for the programmer.
I found it helpful - it allowed me to think and talk about structures in more explicit way, so problem solving got easier.
I think it should be read when you already have some experience with project that has some logic in it (e.g. not crud and also not frontend - frontend requires entirely different structures imo) where you had to make decisions about what goes where. It cease to be abstract then (or your brain adjusted to thinking in more structural way).
I have heard the word delegation as in "this object methid here just returns value somebody else calculated" so many times, that I am pretty confident everybody would be just confused if I started to use different terms.
Anyone understand the concept?
That is why i like C. I can have my data structure and just add functions that can operate on those data structures outside of the data structure itself without worrying about coupling code to the data. Extra functions that can operate on the data may as well be inside a dynamically loaded plugin. Not feeling forced to put everything that can operate on a single instance of the data inside the same class. Not feeling forced to create a separate class to add methods that can operate on multiple instances of the data and hardcoding multicore support inside of it.
The new C++ (and Nim) have the notion of concepts which can mostly replace the many ways OOP was being abused. It is similar to type classes in Haskell. I advice you to read Alexander Stepanov's books.
You can have a data structure in a class, add certain concepts that the data structure supports and then create separate functions which can operate on these concepts outside of the class / object.
I agree with everything else you said, but the way I see it - when a paradigm cornerstone itself starts getting in the way of code organization, then that's a clear sign that paradigm itself is 'wrong', or more precisely, wrong when applied to this set of problems.
Oooooooh, look at that, I understand now what you meant :-D
Regarding your second paragraph - this is, looking from efficiency standpoint, the best approach. Additional gain is in access control: it becomes flat (ie. module-controlled), rather than having a class hierarchy in between, and then using messy constructs such as interfaces/mixins to achieve both code and type inheritance. Raise hands if you ever ended up in situation where you have to convert from one type to another, while the actual data they carry are precisely the same. Raise hands if you ever had to pollute an interface or a parent class with extra data, because a subclass somewhere contains exact data needed at the other part of the chain. This is friction - and it works against the developer/team. The larger the software, the worse it gets; it doesn't have to be that way.
Anyways, regarding last two points - yes, I'm very familiar with parametric polymorphism (it is a sole reason I use C++ for work, over C), and I have than half a decade of Haskell experience behind me. Trying to shift into Rust lately - its easier to find jobs.