When Is The Use Of Design Patterns Not Appropriate

It's worth asking of any approach to software development "When is it not appropriate?"

A reasonable answer can improve the credibility of the approach as well as helping people who, maybe unwittingly, are trying to pioneer the approach in a new area; at least they should go into it expecting to have to solve basic problems or adapt the approach to suit.

Let's assert that the use of DesignPatterns is always appropriate (including the case of considering them and then using none!)

IMHO pattern recognition and use is a fundamental part of the design process. Therefore any design exercise will involve the use of patterns. It may be that the patterns one uses are not the GangOfFour patterns, or have not yet been published. It may be that one is working in such a new area that there are no existing patterns for the problem domain; in that case, one will build up sets of personal ProtoPatterns which one will reapply on later design exercises.

So when is it inappropriate to use a known solution to a common problem? Obviously, when the problem isn't actually there yet.

The use of patterns is not appropriate when it's overdone. I have met programmers that focused too much on the patterns used and not enough on the actual job to be done. Some patterns are actually an artifact of the limitations of the language used. [See also AreDesignPatternsMissingLanguageFeatures] In highly expressive languages like LispLanguage or PythonLanguage, they tend to just disappear. Some programmers force these patterns onto the language anyway because "it's in the book".

I am not sure if "using" DesignPatterns is a good idea in the first place. Don't get me wrong, I am a big fan of design patterns, but if we do a good OO design, won't we end up with a design pattern if the forces are right? Too often, I have seen people "use" design patterns because they know how to. When you have a hammer, everything looks like a nail. The easier a pattern solution is to understand, the higher the likelihood that it will be abused. The SingletonPattern is the most obvious example.

QuickQuestions

Q Do people find a need to document what design patterns have been implemented where? Or is the use of DesignPatterns always so clear that these get recognised immediately?

A1 I have not found it helpful to document design patterns separately. Class names can be used to indicate their role in a pattern, e.g., "SchedulerFacade" or "KeyboardSingleton" though this can become irritating if over-used. Use of DesignPatterns is not necessarily self-evident in the code, but arguably doesn't matter once the code is written.

A key role of DesignPatterns is to help readers understand what you've built. Another key role is to help produce software that is built of reusable components. You can say that it's arguable that it doesn't matter once the code is written, but these key roles suggest that DesignPatterns are more important once the code is written. -- DonBranson