The irony here is that the root of the "FactoryFactoryFactory problem" actually finds itself in composability, which itself is a feature of the -drumroll-
> functional programming paradigm
It's very common to see/use F(F(F...))) paradigms in lambda calculus homework exercises and its more modern/useful derivatives (yes, like Scala) where the real "meat" of the logic is the center of this Tootsie Pop. We need to change the shape of a thing to make it fit some function that takes the thing (where every step of the way, we're greeted with: no, not like that). Often times, the function expects a functional type, but we just have an object. Better Factory it up!
So at some point down that rabbit hole, you're like "fine, what about a FactoryFactory?" ok cool, that works (because the engineer 15 years ago wanted it to be more "general"). Just add a ".build()" and commit. Merge. Done.
I don’t think that’s such an irony. In FP, minding the conceptual overlap, you could conceivably name every function with a Factory suffix. After all that’s what a function does, return a thing it created. Taken to its logical extreme, one would expect far more Factory suffixes for a real program of any significant complexity. But that’s kind of a silly naming convention when every function produces a new value and there aren’t non-Factory things lurking around producing unknowable realities.
It’s even better in Haskell: Haskell only has single-argument functions, so multiple arguments are really function factories, and sometimes they produce other function factories. So, the type signature of a FactoryFactoryFactory is something like foldr:
> It's very common to see/use F(F(F...))) paradigms in lambda calculus homework exercises and its more modern/useful derivatives (yes, like Scala) where the real "meat" of the logic is the center of this Tootsie Pop.
Agreed. That would be compose in Scala[0]. Or F |> F |> F if using the thrush combinator[1].
> Often times, the function expects a functional type, but we just have an object. Better Factory it up!
Why?
> So at some point down that rabbit hole, you're like "fine, what about a FactoryFactory?"
This is where you jumped the shark. Doing composition by encoding it as a one-off unique type ("<prefix>FactoryFactory") appears to be a "poor man's monad transformer."
Unless, of course, the intent is to just get the change req "down the road."
> functional programming paradigm
It's very common to see/use F(F(F...))) paradigms in lambda calculus homework exercises and its more modern/useful derivatives (yes, like Scala) where the real "meat" of the logic is the center of this Tootsie Pop. We need to change the shape of a thing to make it fit some function that takes the thing (where every step of the way, we're greeted with: no, not like that). Often times, the function expects a functional type, but we just have an object. Better Factory it up!
So at some point down that rabbit hole, you're like "fine, what about a FactoryFactory?" ok cool, that works (because the engineer 15 years ago wanted it to be more "general"). Just add a ".build()" and commit. Merge. Done.