The Gang of Four is wrong and you don't understand delegation (2012)

"There's nothing there" is pretty close. I see OOP as fundamentally one key concept: that there are functions which "belong to" specific types, and all other operations on those types go through the functions that "belong to" them.

You can do OOP in a language like C by writing your code as structs and accompanying functions that operate on them. You might expose the structs to the rest of your code as opaque pointers to enforce that all other code has to go through these accompanying functions to use this struct. Or you might just make it be convention. An OOP language is just one that has language features to facilitate this, such as by allowing you to define methods within a type rather than functions outside of it.

Once you have this, then you might start thinking of features that might be nice to have alongside, such as dynamic typing, dynamic dispatch, inheritance, etc. But I don't think any of those are fundamentally OOP, they just fit well and are often found together.

Since having functions that belong to specific types isn't a very big concept, discussion about OOP is going to focus on these other things, which are not necessarily omnipresent and are often different across languages. So the discussion is either going to be very specific to one particular language (maybe even one particular set of libraries for it) or very vague.

OOP has a "there" there, it's just that the core formalism is user interfaces. If you look up "object oriented programming" on Wikipedia, the first image you get is a UML diagram of a user interface component.

OOP was invented to facilitate old-fashioned "expert systems" type AI research. While that's a nebulous concept[0], it turned out to be really useful to represent (retained-mode) UI in this way. Any mildly complicated UI needs to be a tree structure where the contents of the tree are all different things. You might want to put a button inside of a cell in a scroll list on the right pane of a window, and to do that, all of those things need to...

1. Support arbitrary child objects of different types and data sizes

2. Communicate with a standard set of events and system behaviors

3. But also support modifying those behaviors or introducing new events to fit the present application

Outside of immediate-mode GUIs for games, GUI-approximating text mode applications, and classic Mac OS[1], every UI toolkit worth its salt is OOP. Yes, even USER.dll. Microsoft[2] wrote an object system on top of a non-object-oriented programming language because it was just that useful.

If you aren't doing UI work, OOP loses it's effectiveness. But doing UI work in a non-OOP language is painful, in direct correlation to how non-OOP the language is. e.g. If you're working in Rust, you can probably get by with a bunch of traits and `dyn UiWidget` them; and there might also be something similar for Go; but in C you'd have to manually construct vtables for every object type you plan to include and pass pointers to everything around everywhere.

[0] Yes, the term "AI" has been meaningless for over half a century. Yes, there's probably a link between that meaninglessness and the nebulousness of UI and OOP.

[1] Steve Jobs had been so distracted by the fancy pointer-driven UI at Xerox that he forgot about the OOP language powering it, Smalltalk. He'd fix that immediately at NeXT.

[2] Also, GIMP, whose UI toolkit wound up becoming GTK, and whose object system became GObject.

OO is pretty simple. Use objects. There are many many patterns that you can use that rely on this concept. You don't need to use every pattern to be using OO. Even at the most basic level of "a scoped namespace", OO can be useful in organization. The fact it can be used in many ways means there are many perspectives on how it can or should be used.

Popular OO languages are also very pragmatic. That means that even if they are OO languages, they allow for non-OO patterns as well. OO is flexible in this way. A counter example is FP, where it is not very flexible. FP has many rules you must follow to make the concept work, such as how mutability is handled.

The way I interpreted most of these "subclassing" cases in the GoF diagrams was actually as "subtyping", and then it makes more sense.

Regarding no one having a lock on the term "delegation", I think this is spot on. Yes, someone might have used the term differently before GoF, but that does not mean that GoF was wrong. It just meant something else in their context.

(Btw, congratulations, your comment is the first one so far in this comment thread that actually discusses the linked article and not just the GoF book itself.)

> everyone knew the ways in which that was a bad idea

The state machine pattern is used currently in verbs. That was the state of the art for many decades before higher level interfaces appeared.

Why was it a bad idea? Can you elaborate?

They're both likely a reference to the infamous political faction in China in the 60's.

https://en.wikipedia.org/wiki/Gang_of_Four

Trivial Builders are often used in java due to lack of named parameters or object literals. Trivial Visitors are sometimes used due to the anemic switch/enum support, although it's gotten a little better with switch expressions and switch patterns. Singletons and factories are used since java metaprogramming usually requires an instance of an class and can't use the class itself. E.g. you can only call interface methods on an instance, unlike e.g. a rust trait where you can call a trait method on a type without an instance of that type.

In non-trivial cases, these are still useful patterns though in many languages. E.g. traversing a complex AST is often an ideal case for a Visitor. Builders are useful e.g. you want to validate relationships between objects, so you keep a hashmap while building so you can do O(1) validation while building and provide targeted error messages, but then throw away the hashmap after building. Builders are especially useful if you avoid mutable state since you can often contain the mutable parts to the Builder and make the built object entirely immutable.

A lot of the patterns are useful, but you would unknowingly "use" them when appropriate without ever having explicitly learned them. E.g. the Adapter pattern is an obvious solution to a particular problem. I think the only contribution the book has for these patterns is giving these names.

All languages have patterns. They differ some between languages as language features dictate what problems need conceptualized solutions that are different from what the language provides. There are also lots and lots of domain specific patterns that are not very documented but which people that work within a domain tend to recognize.

It's been a while so I just looked through the list and... pretty much all of them?

It would be easier to identify the ones that don't make sense. The only obvious one is Observer, since without mutable state there's nothing to observe. Everything else looks relevant for immutable objects.

You need a different list of patterns.

Arguably, Haskell's use of monads is a pattern. It just isn't in the GoF, since it doesn't solve a problem that was a problem for the languages the GoF was written for.

> passing functions as arguments

You mean the Strategy Pattern?

A lot of the patterns are still there. They just look very different.

I don't think that is an unpopular opinion at all, and I like OO programming just fine. People latched onto Design Patterns like that were tablets from God whereas the book was better thought of as giving a taxonomy to existing practices (and not even best practices.) Different subsets of their patterns work better in different languages, and it is pointless to force a specific pattern into a design where it doesn't fit naturally.

I think it is useful to say "This design could be thought of as a delegate" when explaining your code, but saying "We need a delegate design pattern here" is needlessly prescriptive.

What it was trying to be was misunderstood. Arguably, there were too few patterns and they were provided as a way to build software like LEGOs.

I've read "A Pattern Language: Towns, Buildings, Construction" which was the inspiration for the GoF book. That book had 253 patterns and they were written as "here are ways architects solve common problems". Pattern 148 - small work groups

> When more than half a dozen people work in the same place, it is essential that they not be forced to work in one huge undifferentiated space, but that instead, they can divide their workspace up, and so form smaller groups.

> In fact, people will feel oppressed, both when they are either working in an undifferentiated mass of workers and when they are forced to work in isolation. The small group achieves a nice balance between the one extreme in which there are so many people, that there is no opportunity for an intimate social structure to develop, and the other extreme in which there are so few, that the possibility of social groups does not occur at all.

> ...

> Break institutions into small, spatially identifiable work groups, with less than half a dozen people in each. Arrange these work groups so that each person is in at least partial view of the other members of his own group; and arrange several groups in such a way that they share a common entrance, food, office equipment, drinking fountains, bathrooms.

> Lay the workgroups out with respect to each other so that the distances between groups is within the constraints of OFFICE CONNECTIONS (82), and give each group office space which leaves room to expand and to contract-FLEXIBLE OFFICE SPACE (146); provide a common area, either for the group itself or for several groups together or both —- COMMON AREA AT THE HEART (129). Treat each small work group, in every kind of industry and office, as a place of learning—MASTER AND APPRENTICES (83). Give it its own stair, directly to the street—OPEN STAIRS (158). Arrange the individual workspaces within the small work group according to HALF-PRIVATE OFFICE 152) and WORKSPACE ENCLOSURE (183) . . . .

It's a not a dictate, but rather descriptive of "these are problems and ways people solved them" along with maintaining a unified vision of the design.

The GoF book became prescriptive instead. People used the patterns in anticipation of the problems rather than because they had them.

https://www.artima.com/articles/how-to-use-design-patterns

> Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution?

> Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.

> Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

---

The Patterns from GoF became the goal without understanding what a Pattern is. It's a way to hold complexity. A function call is a Pattern. Store volatile registers onto stack, put return address onto stack, put parameters onto stack, jump to new instruction, restore registers.

That Pattern is now hidden inside of `foo(bar, qux)` and that hides a lot of the complexity for what is being done.

But we don't come with the idea that to write a good program, you must use functions. Well, you should because they're likely complex enough to need them... but we use them when we need to manage that complexity.

A phrase I used before was that the GoF isn't a cookbook but rather a bestiary of complexity.

The problem is when people use Patterns in anticipation of complexity that isn't there. So when they're putting patterns in places, as a maintainer you see dark and (maybe) empty cages. Do you want to stick your hand in it to see if it will get bitten off?

Don't have empty complexity cages. And when you do need the complexity cage, properly illuminate it with a clear description of what it is and what complexity it contains.

(yes, I can rant about Patterns)

https://c2.com/ppr/wiki/WikiPagesAboutWhatArePatterns/Patter...

And one of the blog posts of yesteryear that influenced me - https://perl.plover.com/yak/design/

I think design patterns should be more descriptive, but people try to use them prescriptively.

Being able to say "circuit breaker" pattern or "visitor" is a time efficient way to communicate complicated ideas. Its value is being able to conserve the limited bandwidth speaking has.

Bad coders will always find something or another to justify their work with and it just so happens the most popular book is often referenced, for good and bad.

100% agree. The worst offenders imho are DRY and inheritance. In most cases it causes garbage code that adheres to some lofty goals but sucks to be maintained. We actually do the opposite of DRY: isolate behaviour, even when shared. If complex enough and shared: build a lib. But one use case = one app functionality. We are so happy and productive with that. Throw in ports + adapters and use cases (= one feature) and you're set.

AFAICT, I think your opinion is fairly widely shared.

In my experience, design patterns cause a lot of problems when developers reach the stage when they understand them enough to know how to implement them, but not when (and even more importantly, when not).

Most design patterns were invented as workarounds to specifics and limitations of certain languages/paradigms, and work great in that case -- but are much more limited, or even downright dangerous, when used in other contexts. As a clear example, the GoF patterns focus on strongly typed OOP languages like Java or C++, and will result in difficult to maintain bloatware if copied directly to dynamic languages like Python, Javascript or PHP (source: been there, done that, got the t-shirt).

I tend to agree. The OOP-all-the-things mantra created many problems; lots of books were printed (more than necessary), and lots of evangelists made their name on unnecessary abstractions over abstractions. One might blame Java for that, but it's a chicken-and-egg problem.

I think you underestimate how chaotic things would get without some basic concepts like patterns laid out. Like so many things in this industry, disproportionate attention is drawn to perceived problems rather than things that quietly work well with the same tech.

Likewise. I also hate the corollary, in non-technical, philosophical conversations: changing the meaning of the word in the belief that doing so somehow confers or demonstrates insight or understading.