What should be the name for a class which builds something but is not really implementing

Builder

pattern. You simply have one method

Foo.build(param)

in the class interface which gives you the instance. Such classes use some other builder hierarchy by feeding received configurations in

param

and gives you concrete instance, IE, abstracting away builder logic. For instance, I have a custom notification builder class which is using

NotificationCompat.Builder()

internally and giving

Notification

instance on invocation.

You could top level builder functions:

buildMyNotification {
  title = "Hello World"
  timeout = 10.seconds
}

or

MyNotification(
  params = NotificationParams(
    title = "Hello World"
    timeout = 10.secons
  )
)

operator fun invoke

on the

interface

is another option

This can’t be a function. I want to have multiple subclasses implementing this. Like there will be Alarm Notification Builder, Sticky Notification Builder and I want to have proper DI setup for all of these. The concern is not how to implement it, but what to name this class. Let’s say it’s building

Notification

object, I don’t really want to name it

MyNotificationBuilder

, because I’m not implementing builder pattern and the name might give wrong ideas. Some of the options I came up with • MyNotificationCreator • MyNotificationComposer • MyNotificationFactory (to some extent we can call it a factory because I’ll be having multiple subclasses creating their own variant of

Notification

)

Factory?

I still don't get why it can't be a function. There can be multiple functions of the same type.

Are you working on something that looks like this?

From your first message I would say you are describing an oldie but goodie Factory - so that is the name I would go for. That said, your second message made me suspect you may be trying to implement a variation of Abstract Factory (?). Maybe you want to check this: https://refactoring.guru/design-patterns/abstract-factory