APIs should be impossible to misuse

It should hard or impossible to misuse a good API

Josh Block
https://www.youtube.com/watch?v=aAb7hSCtvGw

The above statement validates my preference for using the Builder Pattern to facilitate clients to provide named constructor arguments in a sense. E.g. if a constructor has several string parameters, rather than rely on flaky javadocs and parameter names to inform the user what to provide, I would prefer to provide builder methods that unambiguously let the user know what to provide. For validation of inputs, I make the null checks, etc, in the private constructor. That makes it about as hard to misuse the API/constructor as possible in Java.

Constructor Parameters known only at Runtime

it's assumed here that your Factory knows what the parameters for the constructors should be. If this is only known by the client of the Create method, then I would say the indirection isn't necessary and the client should construct the rule itself

http://stackoverflow.com/a/23765599

So, Factory Pattern may not be appropriate when the constructor parameters need to be provided by the client.

As for "DI abuse," see http://stackoverflow.com/a/1056229 on direct instantiation rather than injection of stateless services:

The abuse of DI leads to stateless objects which really should be stateful ... such code is by nature domain/use-case specific. In such a case ... it makes much more sense to have the [client] directly instantiate the business service class, passing data provided by the user through a constructor

Abstract Factory and "DI Explosion"

On the problem of creating objects from both stateless services and runtime values, Mark Seemann suggests the standard Abstract Factory pattern while seeming to acknowledge that it may be overkill for simple cases (i.e. say we have a lot of these objects to create, e.g. subclasses of say HystrixCommand, do we really want to create a Factory implementation for each subclass?)

Yes I know this, though in my case I hesitate because for simple cases it's overkill to duplicate constructor with interface, factory, factory's constructor, Create method, etc. While good for complex cases, it's too "DI explosion" for simple things I think. And the question remains about automatic registration DI container. – queen3 Nov 6 '09 at 11:16 @queen3: I understand what you mean, but I'm not aware of any DI Containers that can do what you ask.

http://stackoverflow.com/questions/1686760/which-di-container-will-satisfy-this/1686887#1686887

Singleton Vs. Factory Pattern

Most commonly, singletons don't allow any parameters to be specified when creating the instance - as otherwise a second request for an instance but with a different parameter could be problematic! (If the same instance should be accessed for all requests with the same parameter, the factory pattern is more appropriate.)...

• The factory pattern can be used if you need a single instance of a base type, but the exact type isn't known until runtime.

http://csharpindepth.com/Articles/General/Singleton.aspx

Fowler's Observations Outdated?

Fowler’s initial thinking was confined to HTML web presentation problems. He expanded the inventory in subsequent years through a series of posts that can be reached from here. The combined corpus of patterns still resonate for WPF and Silverlight developers even if the details aren’t a perfect fit for these more recent technologies.

http://neverindoubtnet.blogspot.com/2009/05/birth-and-death-of-m-v-vm-triads.html

Singleton Misused

 I saw a singleton used to store a reference to a web service, and then the developer called it from everywhere. So instead of properly designing her class library, she just had a spaghetti bowl of code interaction.
http://forums.silverlight.net/p/14017/45946.aspx