>solutions to imaginary problems

This is a fundamental misunderstanding of what patterns are. The GOF book is used to this though.

A design pattern is someting that will naturally crop up if you adhere to certain design principles. If you follow a principle of separating instantiation logic from other logic then you will start to see factories. If you combine multiple complex parts of your code into simpler ones then you will see facades.

GOF is a reference book for some patterns that have been observed as being common, with examples that are essentially academic. It is not a how-to guide for OOP.

But many programmers use it as a how-to guide. I've had people tell me "but that's how it's done in GOF", even if the design pattern was a poor fit for the problem at hand, just because there was some superficial resemblance to one of the examples in the book.

Ask them to re read chap.1 or 2 where it says black-on-white that this is not a set of mandatory rules. (Same for Clean Code by the way which is often taken as gospel against the wishes of its own author!)

I remember trying really hard to find case where I could use a pattern in my code as a junior dev.

but this is not the fault of the book but of bad teaching.

That exact sentiment exists deep in my comment history here: I think I used the word "blueprint" if you care enough to fact check that. That is why I said I don't hold issue with the content of the book.

My issue is that the book is useful. It helps solve the artificial complexity introduced by OOP.

Agreed that it's never good to have new social problems created by whatever you did to solve the previous problem. But that's the nature of doing stuff.

I own a car. Great, now I have maintenance concerns. But it's still a net positive, which is why we do it.

If oop creates more work than the value of brings, then we should scrap it. But I've seen some pretty bad procedural code, so I don't think that's a given.

I see. It was the ambiguity over your usage of 'imaginary problems'. But yes - your previous comments seem to suggest we're actually on the same page regarding patterns.

But even factories and all these terms are very vacuous and only present because objects are giving bad solutions.

I put it to you that the OOP concept of a factory exists because in OOP your factory is often (though not always) a type, and types tend to need names.

In e.g. FP there are no objects and therefore no instantiation but you can separate this kind of logic all the same, except you wouldn't call it anything, or would name it like any other function.

For the record I've been doing mainly OOP and have dabbled in F# so I'm happy to learn something today.

That's the whole point. OO gives a class as base, forcing you to reextract limited instanciation logic into another thing, when it's just functions from a to b. And people get to waste time on this.

No - that's not what factories are at all.

If you want a simple function to create objects, you have those in OOP languages. They're called constructors. They don't even have names independent of the thing they construct, so they're as lightweight as you can get. And if you do want names, you have static methods or top level named functions (depending on language).

Factories exist for a few different reasons:

1. When there are more things to configure about the newly created objects than makes sense to pass as function properties.

2. When an API designer wishes to provide backwards compatibility to his clients, which adding function parameters doesn't do.

3. When there's a need to separate how something is constructed from where it is constructed, i.e. you create a "factory" or "builder", configure what you want it to do, but then don't directly use it. Instead you pass it off to some other code that uses it when it needs to.

These are fundamental concepts. They aren't some side effect of how OO languages work. I think the disdain for them comes largely from programmers who haven't actually done many different types of programming. If all you've ever done is write web apps then yeah they're sometimes going to seem a bit useless. If you've shipped a type safe library API that you've needed to maintain compatibility for over a period of many years, maybe that will be used in ways you didn't anticipate so you can't just arbitrary refactor yourself out of a hole, suddenly these sorts of abstractions start to look pretty good.

point 3 is exactly what I'm saying

But the concept of a factory is independent from whether you name it. In Java you can write a factory like this:

    () -> new Thing(foo, bar);

Behind the scenes it's a class, but you don't write it as such and you don't name it. Nonetheless, it's still a factory.

It's vacuous concept.

Also you're leveraging anonymous function syntax which is, interesting, to say the least. In Java 8- you'd have to write boilerplate class named after a pattern. Lastly creating something from outside information was done since forever, it's trivial when you don't invent ceremony around it. Hence my conclusion, it's a waste of time and effort.

No, because you still need to name the thing the function is assigned to. What exactly should the user of the function call it? thingMakingFunction? You need a consistent way to refer to "a function call that creates an object in a particular state" and factory is as good a word as any.

Yes, in Java 7 or below it'd have required more verbose syntax. So what? That came out 8 years ago and Java isn't the only OO language with a notion of factories. C# had delegates much longer than Java had lambdas, and it also needs a way to talk about "a bit of code that produces objects complying with a contract", so also talks about factories.

Factories really exist because classes are not programmable in many popular OO languages as they are in Smalltalk. Languages inspired by C++ (Java, C#) tend to have factories. Microsoft used the unfortunate term "ClassFactory" in COM/OLE when they really meant one or the other, as it is a factory of objects just like a Smalltalk class.

Other OO languages don't have lots of explicit factories. I'm thinking Objective-C (abstract classes can choose the appropriate subclass for new objects), Python (packages tend to have instantiation functions), Ruby (very flexible), CLOS, etc. So the factory is really a design pattern that popped up to address a specific language deficiency caused by losing a lesson discovered in the late 70s (metaclasses).

Other design patterns are really quite useful and I don't see how they can be called deficiencies. Facades, for example, are widely used in OO and non-OO systems. Template method is duplicated similarly in procedural languages that allow dynamic dispatch, in any place where you need a policy that delegates parts of its fulfillment to a more dynamically selectable part. Iterators, strategies, these things have widespread use. Builder and Prototype are frequently used outside of OO. Adapter, Bridge and Proxy also appear in various ways without OO. Many of the other patterns are OO specific mainly because there is no desire to send a message to an object in other languages. For example, Flyweight is unnecessary if you don't send messages to objects.

Without OO, a lot of domains would end up with some sort of implementation of the same thing. OO itself is a pattern in this sense. You can write Javascript in a functional way, but it makes sense to encapsulate the HTML AST and not have its memory manipulated directly by the language. Does it make a lot of difference whether you put the node as the first parameter to a function or whether you use it as the target of a message? As some functions apply to only certain kinds of nodes, does it make more sense to document those functions by the list of known nodes that they apply to, or as a hierarchy of nodes?

People often say that inheritance is the problem, but you look at a successful (in terms of utility) object system like Smalltalk and it has quite a lot of inheritance. Refactoring leads to that. Sometimes a parent class might exist just to provide one implementation of a single method for two different kinds of object. Whether this is accomplished through inheritance, mix-ins, monkey-patching, protocols, multiple dispatch, or whatever, is somewhat immaterial. But when a language makes that difficult, and you have to copy-paste to get the same functionality in multiple places, that can be a problem.

Fair point I limited my view onto java. Other systems have various degrees of freedom.

I'm sorry but this is absolutely ridiculous. I sometimes teach programming to uni students, we make toy software like paint programs with a GUI in Java, networked game in C, that kind of thing.

I always have a good proportion of the class coming up with many patterns entirely on their own without any prior exposure, and I love their looks when I show them that the nebulous concept they came up with actually has a name and is well defined (and the best solution to the problems they encounter given the tools they have).

If a good proportion of an undergrad class is intuitively coming up with solutions that have some commonality, is that commonality really valuable? Observing it is neat, I just take issue with people treating design patterns as a northstar for quality software development

Design patterns as a concept exist without OOP. Even in procedural code or functional code you have concepts like a strategy pattern, or how do I get version X vs Y of object A. These things arise in any code you are writing a sufficient complexity.

My experience with the book and its patterns has been that there's an issue and some developers recognize that it could be best resolved with x, y, or z pattern. Then the developers go to extreme length to make sure the implementation adhere to the the 'principles' or 'spirits' of those patterns, so much so that it creates unnecessary complexity (e.g., unneeded layers of abstraction) and friction in other components (to accommodate the 'purity' of that implementation). What's worse, it's very difficult to challenge such implementation in code reviews, since it's originated by GOF, which automatically makes it legitimate. The worst part, though, is that you have to maintain the implementation, any deviation from those patterns is seen as corner-cutting.

> it's a book filled with solutions to imaginary problems.

Have you even read it? I'd say it has more deep real world examples than almost any other SW engineering book I've read.

IME it happens often that these categories overlap, when software gets entangled in incidental compexity.