For all the negative comments about FactoryProviderBeanCreator whatever style of enterprise-programming: There is a point to it all.
The point is software exists mostly within its socio-economic context - software is mostly made for people by people and will be used by people.
The SingletonProxyFactoryBean enterprise-programming tries to solve people-problems, it tries to waddle through dependencies between libraries, frameworks, language specifications, implementations, organizational structure and various teams within an organization.
This angular.js enterprisy-feel tries to do the same - push responsibility onto the others, or separate responsibility down (separation of concerns) where nobody actually has to do anything but "configure". Or "run" it. Or just "buy" it.
Thats the ultimate goal of enterprise and this style of programming - which eventually leads to somebody being required to know a language on top of a language on top of a language to adapt it to the business needs.
Its the same reason why abominations such as SAP and Microsoft Dynamics (or basically any closed source very expensive suite of software) exist - those products are on the altar of Enterprise, they fit well to the organization and culture of capitalism. They fulfill the goal of "just buy it" or "just install it" and it will do _everything_ a manager or team thinks of. So the programmers make it so - sure the program doesnt actually do anything without the correct set of configurations and options, but now its not an application thats developed inhouse, its a product we buy and can get support for, kind of.
I think there is a different point to it all: Java doesn't have first-class functions.
In OCaml (and without doubt other programming languages as well), you can use a function to make "objects"/"values" that you want made ("constructors"). If you want to parametrize the function ("factory"), you just partially apply it to some arguments. If you need to make other objects before you can make the desired object ("dependency injection"), you pass other functions as arguments. If you want to do something else instead of creating a new object (e.g. "singleton pattern"), you write a different function.
Its not a Java problem as this JavaScript demonstrates.
Its not a language feature X problem.
There is something which drives people to make a factory for a dynamic and another static language. Instead of writing the thing they want they write a thing to give them what they want.
'They fulfill the goal of "just buy it" or "just install it" and it will do _everything_ a manager or team thinks of.'
That's really not how SAP or any of the Dynamics products get implemented...
Actually, ERP systems are a good example of applications where the complexity pretty much comes from the requirements - they tend to have staggeringly long lists of things they must do. I wouldn't knock SAP or any of the Dynamics products - they are complex because they have to be.
The point is software exists mostly within its socio-economic context - software is mostly made for people by people and will be used by people.
The SingletonProxyFactoryBean enterprise-programming tries to solve people-problems, it tries to waddle through dependencies between libraries, frameworks, language specifications, implementations, organizational structure and various teams within an organization.
This angular.js enterprisy-feel tries to do the same - push responsibility onto the others, or separate responsibility down (separation of concerns) where nobody actually has to do anything but "configure". Or "run" it. Or just "buy" it.
Thats the ultimate goal of enterprise and this style of programming - which eventually leads to somebody being required to know a language on top of a language on top of a language to adapt it to the business needs.
Its the same reason why abominations such as SAP and Microsoft Dynamics (or basically any closed source very expensive suite of software) exist - those products are on the altar of Enterprise, they fit well to the organization and culture of capitalism. They fulfill the goal of "just buy it" or "just install it" and it will do _everything_ a manager or team thinks of. So the programmers make it so - sure the program doesnt actually do anything without the correct set of configurations and options, but now its not an application thats developed inhouse, its a product we buy and can get support for, kind of.