Ah, the good old Design Patterns book, responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since.
This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation.
The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription.
Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary.
One can go to the amazon.com page for Design Patterns and click "Look inside" for the "First Pages" and see that the authors wanted to present a catalog: https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
> This is a misunderstanding of the DP book.
It is discussing an effect of the book, not the intent.
> It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies.
Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.
Do you truly believe that specific DP book caused that effect?
I don't. The DP book is extremely dry reading and most programmers have not actually read it. ([In terms of readership/ownership ratio] It's a book like Stephen Hawking's "Brief History of Time" ... everybody knows about it and some might have it on the coffee table but very few actually read it.)
I do think the _phrase_ of "design patterns" (not the book) has become a sort of gravitational force such that any discussion about "overcomplicated design" seems to fall toward that particular phrase. Or put differently, "bad designs" is now a synonym of "design patterns" so much so such that you can't even say "design pattern" and have it be interpreted as a neutral term. It's become a trigger word.
>Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts
Yes, I agree that would be equivalent. However, I don't think the existence of tvtropes compels directors like Michael Bay to repeat the "walk away calmly from explosion in the background" scene. The motivation to repeat that "cinematic pattern" comes from somewhere else. Likewise, the majority of bad/overcomplicated abstractions in source code come from somewhere else besides that particular DP book.
[1] example from WSJ that mentions the common meme about ABHOT: https://www.wsj.com/articles/the-summers-most-unread-book-is...
Context: My formal physics education ended in high school.
It is fast paced and packs a lot of information into each episode, so I do end up rewinding sometimes. And being a passive video, I think retention won't be as high. However, the short videos are very approachable and bite sized. It's very well done and the host is quite entertaining. The past year, my interest in space and physics has increased a bunch. It feels like learning the deeper history and context in which all of humanity is embedded.
The problem is most people have a superficial knowledge of the patterns in the book (a list is easy to put together along with a short summary so most people have read one). They then go looking for how to apply the patterns to their domain so they can check the pattern box, without thinking about the large picture. They never consider that patterns exist to solve a specific problem and if you don't have that problem you shouldn't use the pattern.
The classic example is the singleton: it solves a tricky problem that large systems sometimes have. However few people realize that a singleton is a fancy name for a global variable and have all the downsides of a global variable.
There are several patterns that are a specific way of creating a layer of abstraction. Abstraction layers are often very useful, but as the saying goes: "all problems in programing can be solved by adding a layer of abstraction - except too many layers of abstraction". I've seen cases of layers of abstraction that didn't solve any problems.
As such the original point: DP, by giving patterns names has created more harm than good. This is not the fault of the book though: the names were needed and the patterns are very useful when applied correctly. However before the book people would re-invent the patterns (badly) only when they needed the pattern.
Really? It's been twenty years (maybe a bit more?) since I read the book, but I think this was pretty explicit, was it not?
This doesn't match my experience but I think that's because you're conflating two related ideas: while few people may have deeply read DP, that's not a requirement for it to have had a strong influence on them, any more than it is necessary for someone to have deeply read and understood their holy book to have strong religious beliefs.
I make that comparison because the worst projects I've seen were heavily based on DP but in a bad way because it was used more as a club than a means for self-improvement. Architects threw it around to bolster their status, a strong push towards ritual cargo culting rather than making sure the problem was well understood enough to know that the code being written matched the actual business case, and any criticism was met with a flak shield of “This is the best practice way according to DP”.
That's not necessarily DPs fault — although there is a discussion to be had about valuing comprehensibility if you want to make meaningful improvements — but it was definitely an effect shaping software development for the worse for over a decade.
I believe that it, and specific choices made in the selection and presentation of patterns in it, contributed significantly.
> The DP book is extremely dry reading and most programmers have not actually read it.
Perhaps, but the influence of a book (especially one which directly inspires other books) often extends beyond its direct readership.
Yes, definitely. People used to cite the GOF book left and right while over-engineering crappy CRUD apps.
GoF/Design Patterns was published in 1994. Java, the standard-bearer of overapplying Design Patterns, was first released in 1995, and it only grew into the AbstractAdapterFactoryImpl cliches after that. Based on that timeline Im not really sure how you can argue that GoF had nothing to do with DP madness, at least as exemplified by Java.
Just because GoF was originally meant to be descriptive does not mean that it can't be interpreted as prescriptive, especially by your stock work-a-day software engineer or peter-principle'd software architect. Despite whatever intentions the GoF may have had, by giving these patterns a name, they in a sense codified them, giving people something to point to when justifying otherwise poorly thought out design decisions.
> The DP book is extremely dry reading and most programmers have not actually read it.
The thing about GoF is that you don't really have to read it to apply it--and not actually reading it only increases the odds of mis-applying patterns if youve encountered them elsewhere.
That may be, but it's a very common misunderstanding of the book by junior developers who read the book as a list of recipes to use anywhere they might be applicable.
Is it the book's fault that it's understood this way? I don't know. Regardless, the book + this persistent understanding and use of it are, as grabcocque says, "responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since."
Certain other design patterns books in the software field (Patterns of Enterprise Application Architecture and Enterprise Integration Patterns, for examples that happen to be on the shelf next to me at the moment) don't share those features.
In any event, it doesn't really matter what the original intent of the GoF book is because in practice, people treat design patterns as, well, what the word "pattern" would suggest: "something designed or used as a model for making things <a dressmaker's pattern>".
This is further indicated by the term "anti-pattern," which basically means, "something you should avoid." If you should avoid the "anti" then it stands to reason you should follow the "pattern."
For even more demonstrations of this fact, look at subsequent design patterns book, like one by the Head First. These explicitly treat patterns as improvements to be made over some previous attempt at a coding problem. Or hell, check out this description from https://sourcemaking.com/design_patterns -- "Design patterns can speed up the development process by providing tested, proven development paradigms." " Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns."
Whether it was the original intent of the GoF or not, design patterns are mostly perceived to be _good things_ that should be adhered to.
Now, as many have suggested, the wisdom of reaching for design patterns has been increasingly viewed with skepticism, and rightly so. It'll be interesting to see over time how much weight they carry and where the equilibrium lies. My guess is that certain patterns will essentially fade from relevance (if your language has first class methods, do you really need Strategy, for example?) While some (adapter, facade) remain useful ways of handling various problems.
Mainstream developers who attend schools that produce Java developers believe that this is a recipe book. I have seen this book used at conference talks for nearly 20 years. Countless blog posts aimed at beginners reference this book as the way to solve problems.
The book itself is pretty explicit that they are not recipes, but that doesn't mean it isn't used that way.
Don't blame the book - blame the curriculum that's based on it.
Giving name like flyweight to a simple "compression" scheme... The whole thing felt like "duh" to me. Sure it give common ground to people; but none of it felt like something to be written down, even less worshiped like it was.
I also strongly feel about the critics saying that it targets poor OOP languages (cpp, java <5), rendering the whole thing moot in other paradigms.
Edit: I agree with your opinion. Just wanted to show that this problem is much older and related to other languages too (probably with the similar OOP implementation).
This is true, but it's an effect, not a cause of the book. "Design Patterns" is older than Java. They wrote it based on patterns they saw mainly in Smalltalk and C++.
> prescribed their use generally
Like "A Pattern Language", "Design Patterns" reads more descriptively than prescriptively. It's, "Here's a thing we saw people do. Here's what problem they were solving with it. Here's the context of their problem. Here's the positive and negative consequences."
Perhaps. But consider the background. People write code that isn't very well designed all the time. Maybe you just see these patterns misused so often because you can identify and name them. This is entirely the point behind the book – so we can identify these common patterns and talk about them at a higher level.
You've probably seen bad code where you can't describe what's wrong with it succinctly a lot too. But you don't have the option there of saying "oh, they've used a factory there when they shouldn't have" because the bad code doesn't follow a pattern that you know / have named. So all of those cases just get filed away in the fuzzy "bad code" category instead of being an example of a pattern being misapplied.
By definition, almost, something being a pattern is going to be something you see misapplied simply because that's part of the purpose of design patterns – so you can comprehend these problems better.
As with all things - there are some good ideas there and some bad. And as I understand it, the book simply presented patterns - programmers were already using at that time. So the book's existence in itself wouldn't cause bad code IMO.
Now if someone were to write a "modern design patterns" book, people will probably write about:
1. Actor pattern and concurrency using message passing.
2. Immutability and - designing types with no shared mutable state.
3. Dependency injection
4. Pattern matching
5. MVC
6. mocks and stubs and fake objects?
7. ...
And same as before - some of these ideas when applied to certain cases could be bad.
Based on my recollection of the original Design Patterns book, all of the patterns you list are included in the original book. Caveat: I haven't opened the book in over 5 years, but I'd be surprised to learn that any of the 6 patterns you list are not in the original DP.
And afaict - none of the patterns I listed are mentioned verbatim.
I have the misfortune to remember what some object-oriented codebases looked like before "Design Patterns".
While people—generally those who haven't read the book or completely glossed over the section on the consequences of each pattern—have certainly over-used design patterns, I'll still take that over under-use of them.
An over-engineered too-many-design-patterns codebase is annoying and tedious. A hundred thousand lines of code filled with half-way-reinvented design patterns with its own made up terminology, hard coupling everywhere, piles of global state, and no real architecture to speak of at all is a nightmare.
But I guess the Problem is how OOP is teached.
Before I learned about design patterns I only saw car or animal examples. Design patterns were the first real world OOP stuff I saw at university.
I learned OOP with Turbo Pascal 5.5, for MS-DOS, around 1990. Started using Turbo Vision with Turbo Pascal 6.0.
Eventually also started coding with Object Windows Library in Turbo Pascal and Turbo C++.
Borland manuals were my introduction to OOP, followed by books like "Designing Object-Oriented C++ Applications using the Booch Method.".
Only later I got to learn about the multiple ways of doing OOP (CLOS, Beta, SELF, ...).
I mean, I did OOP in some languages, because, well, they had object like constructs. For example VBA had all these Excel tables modeled as objects you could access and modify via code.
Then there was C++ and Java with their factories and factory factories and whatnot.
And lastly the examples of cars that have wheels and animals that inherited stuff etc. pp.
So I had different concepts in my mind, all being objects.
On the one hand the examples of university.
On the other hand the tangible Excel table of VBA that I understood. "At table is an object with some methods and properties"
And then the "real programmer stuff" like a controller, a presenter, a singleton, a emitter... Things that were really abstract to me, because they didn't map directly to tangible things I saw in the software as a user.
Design patterns somehow made this more easy to grasp.
But I first started to understand the whole thing after building my own API in PHP (started after it got classes haha) that had module- (controllers), protocol- (views) and data-objects (models).
Everybody independently created singletons and factories and builders, we just all called them different things.