Avdi Grimm responded [0] to this (relatively old) article with what I think is a salient point: traditional design patterns are good, but Java makes expressing these design patterns very obtuse and heavy-handed. Nick Kallen conflates using intelligent design patterns with calling out every use of said design patterns in bold-face.<p>Writing Java feels like "now I'm going to make a <i>Factory</i> <i>Factory</i>! See, it says FactoryFactory right there in the class name!"<p>It's entirely natural to use intelligent design patterns in other languages than Java - so natural, in fact, that you don't have to invoke said patterns by name to use them!<p>[0] : <a href="http://avdi.org/devblog/2010/02/09/everything-you-love-about-java-is-everything-i-love-about-good-design/" rel="nofollow">http://avdi.org/devblog/2010/02/09/everything-you-love-about...</a>
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.<p>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 :(