Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Factories
You don't always want to be messing about with private constructors and private classes. They were often made private for a good reason, and you shouldn't be touching them if your goal is only to have an instance of them.
It may well be that you need an instance of an object that has only private constructors. That suggests that there should be a factory for such objects floating around somewhere. If the constructors are in fact private, the factory is almost certainly a static method somewhere in the class. (I realize that among the sort of people who call design patterns "GoF," this isn't technically a factory.) If it's not actually private, but is merely package-protected, the constructor call must be elsewhere in the package.
Often that factory method, in the same or a different class, is static. If it's not, you have to repeat the search procedure to figure out how to create an instance of your factory. Presumably that search will ground out somewhere; there's a limit to how much abstraction even the most dutiful programmer will heap on the code. I frown on too much abstraction, because it increases code and maintenance issues while frequently failing to provide any actual portability or reusability. You've failed to properly guess what the future will hold, and you have to change the code to reuse it anyway.