I'd call this the "Elephant in the Room" (anti)pattern. You are focusing on the minutiae whilst ignoring the bigger problem. If you have a class that requires 15 constructor parameters, then this a warning sign that the class is doing too much and thus needs too much configuration.
The "pattern" you need here therefore is the Single Responsibility Principle. Examine the class, work out how many (likely quite distinct) things it's doing and start breaking those out into smaller, more focused, classes. Each will only then need a few constructor parameters.
To begin with, this will create more classes; but they'll be good classes. As you apply this to the mutated mess of similar classes, you'll be able to replace large parts of those with your new classes and what's left will again be better quality, more focused classes.
You've done a good job of abstracting the notification, but you haven't applied similar abstraction to the job of creating the notification target.
What you're doing is not a "Factory Method", because, as you are observing, it doesn't use a single method that decides, usually by the parameters supplied, which true class to create. In your code, the client is choosing directly between the methods; whereas in the factory method pattern, the immediate client shouldn't really know or care.
Neither is this an "Abstract Factory" because the client is also supposed to not know or care. In this sense, the abstract factory pattern builds on the factory method pattern.
The code isn't a builder pattern either, because the NotificationFactory
directly instantiate the object without any further ado.
Further, your client is required to use new
in invoking the NotificationFactory
, which has a bit of a smell: you're calling it a factory, but the client actually has to use new
(to create the parameters), which is what the factory is designed to obviate. The idea of the factory is to create a loose coupling between the user of the factory and what's being created. Because of the specific new
used for the parameters, this makes tight coupling.
What I would suggest is that you analyze your use case and see if there is a need for a factory. If not, simply revert to using new
directly.
When need to separate the responsibility for choosing the method of notification from the creation of the instance, then you should introduce a factory.
Best Answer
Whenever creation of new object requires setting many parameters and some of them (or all of them) are optional.
E.g. (for Java but you can easily transform to other language)
instead of
You can also create easily objects for test with such a builder e.g.