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