Comment by troad
5 days ago
> It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself.
The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place.
Objects. Just say no.
Bit of an extreme position, no? Languages without OO tend to end up reinventing it. Like the Linux kernel style of "big C structure with function pointers": that's just a vtable which you have to maintain by hand. Or, god help you, trying to do COM in C.
What's a good codebase that is very large but without either OO or pseudo-OO?
I totally agree one ought not use a non-OOP language for OOP. Right tools for the job and all that.
I work on large (but private, so I cannot share, sadly) FP-style codebases. The code style is stateless functions grouped in modules that operate on data-only structs in a factory line manner. Typed boundaries for correctness, short and maintainable functions for clarity. No member functions, so no vtables.
I've never seen such code need or use OOP design patterns. I'm just very gently pushing back against the idea all code devolves into OOP spaghetti in due course. It doesn't! There are better ways. :)
Mmm, no, I don't see why OOP has anything to do here (any examples?).
I did not use any inheritance. In general I would say OOP craziness faded long ago (in Java too), together with XML. Interfaces -- yes, are very much alive though.
I'm not using OOP to mean presently unpopular facets of OOP, to the exclusion of presently popular ones, I mean all of OOP. It's pretty hard to need factories, let alone factory factories, when one isn't using objects or classes.
A friendly joke in response to the claim that sufficiently complex code always ends up sprouting OOP abstract nonsense.
Unless you are using a strictly FP language, you are always basically using objects.
And all the stuff like factories and everything exist in FP as well, it's pretty short sighted to say otherwise. These are patterns that may or may not be useful in a given case. Sometimes a language feature can replace them (e.g. pattern matching ~ visitor pattern, but not even this is a full match see closed vs open hierarchy), but in most cases you just call them something else/don't have that problem because you are not writing that big of a software.
2 replies →