I think a lot of the complaints about the AbstractFactoryFactoryProvider nonsense in many java programs is that it unnecessarily adds complexity to projects tha

I think a lot of the complaints about the AbstractFactoryFactoryProvider nonsense in many java programs is that it unnecessarily adds complexity to projects that do not require it. In the examples provided there were clear performance characteristics and constraints that provided clear justification for these patterns. Basically design patterns like this are a way to manage complexity and add flexibility to a program. However, if the level of flexibility is unnecessary then the patterns themselves become a source of complexity. This is definitely something i struggle with in my development (which is mostly java). Deciding when you need to introduce an interface (or use a delegate ...) to solve a problem vs. just creating a more direct fix (adding a member variable and a few if statements is probably a very fundamental design problem in all software. The response of 'convention over configuration' is just a way of saying that most of the time sticking with a convention is going to be the faster (to code) and simpler path forward. It's optimizing for the common case and building a real time graph database client is not the common case :(