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.
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.
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.
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?
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.
To reason about code. To explain to others what the code does. Also to document code.
> 'visitor pattern' -- does any pattern intro tell people that this exists only because Java and C++ have no multiple dispatch?
Visitors are sometimes useful when you do multiple different filter/search/transform operations on the same tree data structure, especially if the tree contain heterogeneous elements i.e. walking is not trivial. Visitor pattern allows you to write tree-walking code once, and reuse it with different operations = different concrete visitors.
[+] [-] alkonaut|8 years ago|reply
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|8 years ago|reply
[+] [-] humanrebar|8 years ago|reply
Just call them "factory closures" and everybody wins.
[+] [-] humanrebar|8 years ago|reply
> 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|8 years ago|reply
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|8 years ago|reply
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|8 years ago|reply
It's not exactly a secret. The Double Dispatch wikipedia page has a visitor section: https://en.wikipedia.org/wiki/Double_dispatch#Visitor_patter...
> 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.
[+] [-] Const-me|8 years ago|reply
I don’t think they do.
> What are they for, really?
To reason about code. To explain to others what the code does. Also to document code.
> 'visitor pattern' -- does any pattern intro tell people that this exists only because Java and C++ have no multiple dispatch?
Visitors are sometimes useful when you do multiple different filter/search/transform operations on the same tree data structure, especially if the tree contain heterogeneous elements i.e. walking is not trivial. Visitor pattern allows you to write tree-walking code once, and reuse it with different operations = different concrete visitors.
[+] [-] unknown|8 years ago|reply
[deleted]