Java – design pattern for describing a variable subpart of a config file

The Design Patterns book is descriptive, not prescriptive; it describes the patterns the GoF have observed in the wild; patterns that solve problems.

Some problems can be solved in more than one way.

The alternative you describe is also my preferred approach, but it's also described in the book: it's a combination of the Abstract Factory and Strategy patterns. You use an Abstract Factory as a Strategy.

I don't understand why one would go through the trouble of subclassing a class and making it abstract just for the benefit of allowing it to use a factory in a loosely-coupled manner.

For the exact same reason that you would combine Abstract Factory and Strategy. However, the best solution partly depends on your language.

If, for example, you were programming in Eiffel, Factory Method would probably be easier, because Eiffel has multiple inheritance, but (IIRC) no interfaces.

Also, if you're using a language where you can create a derived value on the spot (such as Java or F#), Factory Method might actually be easier than the Abstract Factory/Strategy combo.

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.