If I have two separate "factories" that doesn't extend to an abstract parent factory, is it still a factory pattern?

Question

Is this still considered a factory pattern? My client knows which superclass they need so they also know which factory to use. But these "factories" doesn't extend to a single abstract factory, unlike what has been demonstrated in my textbooks, so I'm a bit confused.

Answer 1

There isn't a heck of a lot of difference between 'a factory that doesn't implement or extend something' and 'a batch o static methods'.

If a road leads to nowhere, is it still a road?

If a tap doesn't have its water line hooked up, is it still a tap?

These are fun philosophical games. The point is: It looks like a factory - it is a factory. But it isn't doing what factories are for. It has no purpose.

Generally speaking I'd advise getting rid of the factory entirely and adding the methods you had in there to the class directly, marking them static instead, if there is no purpose to be had here. That's just a simplification - you haven't explained the exact details of your problem. It's unlikely, but possible, that a factory that implements/extends nothing is a good move here.

The point of factories is simply to be exactly like static methods, except that static methods can never override (implement) an API, because that's not how java works. Instance methods can. Hence why the factory pattern exists: So that you can do class-level methods that nevertheless implement something.

If your factory doesn't implement anything, it's just an awkward, roundabout way to write a container for static methods.

Perhaps you will counter with "My textbook told me static is bad" - and we really start digging deep into a more central tenet, which is that pithy maxims like that are completely useless if you don't grok them. None of those rules are actually absolutes. They are oversimplifications; mnemonics to remember good programming practices by. They will steer you wrong if you treat them as actual laws instead of things that are convenient short statements to remember actual practices.

For example, 'static bad'? That's really just a simplification of saying 'shared / global state is hard to test and usually pre-defining the global-ness of state at the level of an individual class whose state is being globalized tends to be a case where the author of said class is simply not imaginative enough.'.

Yeah, quite a mouthful and much harder to understand.

At any rate, whatever your book is trying to tell you, there's no such thing as a black and white view on the concept of a factory. Is what you have a factory? I dunno. The Java Lang Spec doesn't mention that word anywhere, so, it's a pithy word that is trying to describe a whole boatload of properties, and there is no perfect consensus amongst programmers as to which properties, precisely, the word actually entails. So perhaps it's not as useful to try to suss out if this is to be called a 'factory' or not. There is no deity with the absolute final law on that.

What would be useful is to figure out what you are trying to accomplish and which code style leads to code that is easy to maintain, easy to read, easy for other programmers to understand, and easy to modify in face of changing requirements.

Without the need to abstract class-level operations, a factory is a solution in search of a problem.