Can a class be considered as a factory even though it only creates one concrete type of objects?

Question

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?

Answer 1

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

Answer 2

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.