What should be the name for a class which builds s...

# naming

[Kshitij Patil]

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.

[mbonnin]

You could top level builder functions:

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

or

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

[Javier]

operator fun invoke on the interface is another option

[Javier]

interface Foo {
  
    companion object {

         operator fun invoke(param: FooParam) = object : Foo {
             ...
         }
    }
}

// Consumer
fun main() {
  val foo = Foo(param = FooParam(...))
}

[Kshitij Patil]

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)

[kqr]

Factory?

[Dmitry Khalanskiy [JB]]

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

[louiscad]

Are you working on something that looks like this?

[Marcello Galhardo]

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