Factories are a pattern that is not unique to Java. They're used prolifically in C++ at least, and I'm sure in other languages.
The factory pattern is tightly coupled with polymorphism. If you're not using polymorphism, then you may not typically need factories. But if you are, then at some point you're going to have some conditional logic about what concrete type of class you're going to create of a particular interface.
Modern Java is lending itself more towards data oriented programming, and coders are trending in that direction. This may or may not last, like every trend. But even then, at the moment this tends to still involve using sealed interfaces and records, so you still have some form of instance creation and polymorphism.
How do you avoid factories? Doesn't you code end up littered with worse code?
> How do you avoid factories? Doesn't you code end up littered with worse code?
Easier for me to use "public abstract class" and then leave open methods inside like "protected abstract doAction();" that are forcefully implemented on each variation of that class.
There is still just one base implementation, I guess the main difference is using strong typed classes that keep the specific code inside specific classes. With factories one tends to end up with a very large source code file that details with too many specific different topics, was making maintenance and testing harder afterwards.
Or maybe I just never really understood properly the value of factories.
Yeah sorry, I don't mean to cause offense but that doesn't make sense. If you've got abstract methods that require implementation in concrete classes, you've got polymorphism, and at some point you're going to be choosing which concrete class to instantiate.
If you always know which concrete class to instantiate and use at each point in the code, it doesn't sound like you need polymorphism in the first place.
Usually when I have polymorphism I have some algorithm that operates on an array or graph of mixed instances of BaseClass. For any particular graph I know statically which concrete nodes I want and their arrangement. Factory really only made sense to me if you want to delay the actual creation of the array members, if the decision comes from something external, or if their creation is deeply entangled with their environment in a way you couldn't otherwise avoid repeating.
The factory pattern is tightly coupled with polymorphism. If you're not using polymorphism, then you may not typically need factories. But if you are, then at some point you're going to have some conditional logic about what concrete type of class you're going to create of a particular interface.
Modern Java is lending itself more towards data oriented programming, and coders are trending in that direction. This may or may not last, like every trend. But even then, at the moment this tends to still involve using sealed interfaces and records, so you still have some form of instance creation and polymorphism.
How do you avoid factories? Doesn't you code end up littered with worse code?