
Design Patterns: Factory Pattern, Part 1 - henriguy
https://henricodesjava.blog/2017/10/29/design-patterns-factory-pattern-part-1/
======
alkonaut
I wish new programmers weren't shown these "classical" OO design patterns
without a corresponding functional pattern. Most of the time the corresponding
functional pattern is "pass a function".

Most cases of a factory is basically a Func<Inputs, Output> type function
definition. Now that all the big OO languages support it, I'd go for passing
creator _functions_ around over defining factories, for nearly all use cases.

This approach works for nearly all the classical GoF patterns.

~~~
harimau777
Are there any resources that you would suggest for learning about functional
patterns?

~~~
alkonaut
This page has a few of my favorite resources. Especially the first set of
slides there is great.
[https://fsharpforfunandprofit.com/fppatterns/](https://fsharpforfunandprofit.com/fppatterns/)

------
humanrebar
> NYCStyleCheesePizza

> ChicagoStyleCheesePizza

Chaining M by N adjectives together to form a type hierarchy is a design
smell. Odds are, you just need to add 'toppings' and/or 'style' members to
your structure.

But, to praise the Factory pattern, you can walk back your gratuitous class
hierarchies if the concrete class name is an implementation detail of your
code.

------
Const-me
There’re too many classes (and too much code in general), coupled very tightly
to each other.

The example code is very error prone. These string item names are easy to
mistype, the compiler will OK that, if you’re lucky you’ll find a runtime
error, otherwise you’ll introduce the bug. Enums are usually better.

That “code likely/unlikely to change” stuff is just a guess. If neither of
them changes, the proposed approach introduced a lot of complexity for no
value. But if the “code likely to not change” ever changes (e.g. extra steps
dependent on pizza or store), the proposed approach won’t work at all, it’s
either redesign or hacks.

Personally, 80% of times I used factory pattern was while implementing
deserializers (esp. in C++ that lacks reflection). The other 20% is when I
instantiated concrete classes based on come config values of user input. Oh,
and all my class factories were just functions, there’s no need for separate
factory classes.

------
beeforpork
I always wonder: these 'patterns', do they simplify programming for beginners?
What are they for, really? Why is there a whole set of standard patterns even
with standard names that people find useful? Do they really find them useful?

It seems simplistic to me to cut the world into pieces of 'if you have this
problem, you solve it with this pattern, dude.' Isn't this missing the point
of really understanding the problem? Especially because (a) the problems are
usually not exactly like (so often applying a standard pattern makes the code
overengineered) that and (b) the proposed pattern often more reveals the
limitations of the underlying programming language, so why is that not
mentioned in the motivation of that pattern? Like the 'visitor pattern' \--
does any pattern intro tell people that this exists only because Java and C++
have no multiple dispatch? Does is not just awkwardly implement what is
naturally expressible in, say, Julia or CommonLisp. Yet I've never seen this
as an explanation for that pattern.

For the excessively applied 'factory pattern', it even has it's own jokes:
Java, the language without verbs (or, only with 'run()' and 'do()').

Instead of having a simplistic cookbook of patterns, would it not be wiser to
teach programmers about problem analysis and programming languages?

TL;DR: I don't understand 'patterns'.

~~~
humanrebar
> Like the 'visitor pattern' \-- does any pattern intro tell people that this
> exists only because Java and C++ have no multiple dispatch?

It's not exactly a secret. The Double Dispatch wikipedia page has a visitor
section:
[https://en.wikipedia.org/wiki/Double_dispatch#Visitor_patter...](https://en.wikipedia.org/wiki/Double_dispatch#Visitor_pattern)

> Java, the language without verbs

Right. But in the C++ standard library, they use a version of the factory
pattern (see make_shared) to allow for some optimizations and nicer syntax.

Separating some construction options from the class definition itself allows
for more separation of concerns with no real loss to encapsulation.

> I don't understand 'patterns'.

I mostly agree that patterns help you work around language limitations. Though
having names for concepts is generally helpful to help move the state of the
art forward. There are "sidecar", "proxy", and "broker" patterns in system
design. If we didn't have those, we'd have to reinvent prose every time we
were describing those maneuvers to our coworkers and (even harder) strangers
in the industry.

~~~
pcr0
Visitor pattern isn't just used to overcome language limitations. In Rails
it's used to dynamically generate SQL statements for different databases.

