Some have said that code with a lot of DesignPatterns crammed into a few classes has a high PatternDensity. It seems to say that this is a sign of high complexity and a bad thing.

On the other hand TheTimelessWayOfBuilding seems to promote high PatternDensity as a sign of good architecture, at least in building architecture.

----

From the JavaUnit "Cook's Tour":

''"Designs with high pattern density are easier to use but harder to change. We have found that such a high pattern density around key abstractions is common for mature frameworks. The opposite should be true of immature frameworks - they should have low pattern density. Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage."''

------

My guess is that the problem isn't really a question of how many patterns, but a question of EssentialComplexity vs. AccidentalComplexity. High PatternDensity is not a bad thing, but applying every pattern in the GoF book without thinking is. -- AndersBengtsson

------

Design patterns add flexibility; thus, they generalize. Thus trying to incorporate them from the beginning of a project falls under the category of PrematureGeneralization. -- KarlKnechtel

----
See also: PatternOverdose