I have a simple class called Link that contains some properties, and use different classes for creating different types of links.

My code looks like this:

class Link {
  String reference, label, target, ...
interface LinkFactory {
  Link createLink(Person person)
class EditLinkFactory implements LinkFactory {
  Link createLink(Person person) {
    // complex "create edit link" logic goes here
class DeleteLinkFactory implements LinkFactory {
  Link createLink(Person person) {
    // complex "create delete link" logic goes here

I have appended the postfix Factory to the classes creating Links. However, according to Wikipedia, the factory method pattern is used in the following case:

In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created.

In my case there is only one exact class of objects that will be created by each of the factory classes. There is never another one.

I therefore wonder: do my Factory classes correspond to the factory pattern ? Or would this naming be confusing as they do not adhere to the factory pattern according to the textbooks?

  • 6
    The point of a factory is not just to hide the existence of multiple concrete types, but to give you the option to introduce better or more types in the future without breaking client code. Oct 13, 2021 at 11:30
  • 3
    Regardless of what wikipedia might say on the matter, your factories are factories as they encapsulate the logic of creating an instance of Link rather than just letting you do new Link(). But whether you stick the word Factory is up to you. That's purely a style thing and so there's no right answer to it. What people will instead focus on when answering this question is whether in their view you even have a factory.
    – David Arno
    Oct 13, 2021 at 11:49
  • 3
    You aren't specifying the exact class of the objects created. All that you are specifying is that they are at least a Link. It so happens that Link is the most-derived-type of the objects that are returned by the current implementations.
    – Caleth
    Oct 13, 2021 at 12:01
  • 1
    Well, I wouldn't per se call it "opinion-based," David, but it is certainly "too vague." What we need with regard to questions like this are "specific cases." ("I was trying to use this pattern, and so I did (or propose to do) exactly this.") "Hypotheticals" are very hard to address in a forum like this one. Oct 13, 2021 at 15:39
  • 1
    Your question seems to be: "did I implement the factory (and the naming is ok) or does my implementation not meet the factory definition (and the naming could be confusing)". Therefeore I have reworded it slightly to set the focus on the template compliance, the naming being accessory. Questions on naming might lead to subjective answers (which is out of scope here), but compliance to patterns can be assessed on objective grounds. If I was wrong, do not hesitate to revert back.
    – Christophe
    Oct 13, 2021 at 23:24

2 Answers 2


In short

Yes, a factory class may create only one kind of objects. It is fully ok to use a Factory prefix or suffix in the name of such classes.

Some more arguments

According to GoF (still the reference textbook about design patterns), the factory method pattern:

defines an interface for creating an object, but let subclasses decide which class to instantiate.

In the structural description of the pattern, GoF use Creator for naming the interfaces or classes that define a factory method. But their examples use several naming conventions, their recommendation in that matter being:

It's good practice to use a naming convention that makes clear you're using factory methods

Your choice is completely in line with that recommendation and perfectly ok.

Moreover, the fact that your concrete factory implementations create only one kind of Link is not an issue either. GoF explain that a parameterized factory method is a factory that is able to create different kind of objects depending on some parameters. But this is only one of the many implementation possibilities described and not a requirement for a factory.

Note: another pattern, the abstract factory aims to use the principle of the factory for creating objects belonging to a family of related classes. This is one particular kind of factory, and althought it's commonly used, it doesn't hold a monopoly on the Factory pre-/sufix

  • 1
    To elaborate: in some parent class, the Creator might be "protected," or even "abstract." Either way, you can't call it directly on the parent class, but methods in child classes can invoke common creator-services provided by their parent. Oct 13, 2021 at 15:37
  • @MikeRobinson Thanks for bringing this in. Indeed the concrete class that is extended (with factory method overridden), the abstract class that is extended, and the interface which is implemented, are all typical variants for implementing this pattern. I've reworded slightly to avoid favoring the one or the other.
    – Christophe
    Oct 13, 2021 at 23:02

Factories come in different shapes and sizes. Three common ones are:

  • Smart factories - these factories decide between several available concrete types based on some specific business logic. The consumer doesn't know which concrete type they received.
  • Builder factories - these factories return a known concrete type, but their expertise lies in knowing how to instantiate and/or configure this concrete type, so the consumer doesn't have to. The consumer tends to know which concrete type they received (it could still be hidden behind an interface, but not necessarily)
  • Dependency factories - factories which exist to spawn instances when requested, so the factory can be injected long-term but its instances can be shortlived. These factories don't have to also be a smart or builder factory, they could just create specific concrete types with trivial initialization logic.

These names are coined by me. AFAIK there is no standardized name for them.

As you mention "complex logic", it seems you are working with a builder factory. I see nothing wrong with that.

However, I would consider refactoring the subtypes into being methods of a more general purpose LinkFactory class, given that it seems you are dealing with a closed set of CRUD-operation-related links.

  • 1
    I really like those names. I might have to adopt them myself. One question though, could you clarify how you see a builder factory differs from a plain old builder? Thanks.
    – David Arno
    Oct 13, 2021 at 12:40
  • @DavidArno A question on the question: does the GoF builder pattern know its concrete return type ? Or is this a specificity of Joshua Bloch's builder pattern (which meets indeed some criteria of the factory pattern)?
    – Christophe
    Oct 13, 2021 at 23:37
  • @DavidArno: Do you mean the builder pattern? I'd say a builder factory is a one-method-builder, where the consumer doesn't call a chain of methods because they don't need to know the different initialization steps. But you could argue that a builder is really just a more advanced "builder factory" and still counts as one. It's a matter of how you think about it, I guess. Personally, I think of factories inherently as being called using a single method to get the object, but I'm not sure if that is explicitly described in the pattern.
    – Flater
    Oct 14, 2021 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.