Link Details

I voted up even though I disagree. I think its important for all developers to be able to recognize when its best to use a design pattern, isn't that the point of design patterns , solutions to common problems. Its not good to just force use of a pattern, but the difference between a junior and senior level developer should be the ability to know when to use certain patterns, to solve your problem.

Rubbish...the whole point of patterns is 'solutions to common problems'. Ignoring the use of patterns in your design if a pattern solves a problem your solution has is asinine. This smacks way too much of NIH.

I don't need to build a system 3 times to discover that I should use a decorator or a composite in certain places in the implementation. Part of being an experienced software developer is balancing YAGNI with knowledge of ways in which the requirements are likely to evolve (especially when doing iterative agile design) and making sure that those likely changes don't require you to throw everything away and start over. You don't utilize patterns in your code just to say "I used patterns", you use them to solve a problem in your implentation that the pattern addresses.

"Rubbish...the whole point of patterns is 'solutions to common problems'. Ignoring the use of patterns in your design if a pattern solves a problem your solution has is asinine. This smacks way too much of NIH. I don't need to build a system 3 times to discover that I should use a decorator or a composite in certain places in the implementation. Part of being an experienced software developer is balancing YAGNI with knowledge of ways in which the requirements are likely to evolve [...] You don't utilize patterns in your code just to say "I used patterns [...]"

I agree completely. Part of being an *experienced* developer is using your hindsight in determining how you can kick things off. I try to stay clear of NIH, and the article is mainly oriented towards junior developers who are rushing towards thinking about patterns than the problem they are trying to solve. Nevertheless, it's not rare for me to see someone who has been programming for several years to get trapped in the patterns-mindset. They are a tool for you, not the other way around.

>Rubbish...the whole point of patterns is 'solutions to common problems

i had a quick look at the article, and it is saying sensible things. i see many young developers who literally design by pattern, resulting in ridiculous architectures that struggle. a good designer actually internalises the principles behind the patterns (many of these are in SOLID) and then will find in hindsight that the patterns are there in the work.

there are 2 problems with taking a pattern-oriented approach to design. the first is that they simply encapsulate what people do anyway. i pointed out to Richard Helm when we spoke at a conference back in '96 that most of the patterns look silly to a smalltalk developer, as many of them come for free in the language. secondly, the aim of patterns is to communicate design knowledge. the next step in design knowledge is when the designer doesn't even need to think in terms of those patterns, but simply has absorbed the principles espoused in them.

this doesn't mean that patterns aren't useful, but they aren't used in the correct way by a majority of designer/developers.

Nice article. I would definitely agree that it's terrible when you see patterns used just for the sake of it. As you say in the article, it's important that you know design patterns, but I find that sometimes they are applied and make for overcomplicated code.

for a horrendous example of the zealous overuse of patterns, you only have to take a brief look at the java.io package. decorators on decorators on decorators. virtually noone has kind words to say about this.

Do people really have this problem? Junior developers trying to apply patterns to a nonexistent problem? Most junior developers Ive seen, even the ones coming straight out of Ivy-League colleges, know very little about patterns. Most learn about patterns gradually as they improve their craft. My biggest problem is that junior developers dont give a crap about writing maintainable code, let alone "overengineering". I'd take one of these overengineering types any day -- at least they are interested in learning.

>Do people really have this problem?

some developers do. i find it tends to be those who have had a couple of years of experience and are starting to delve deeper and read up on s/w engineering. in some cases, patterns become a religious experience for them and they go overboard. can happen to even the best of us.

>My biggest problem is that junior developers dont give a crap about writing maintainable code

we get that also. we try to weed them out in the interview processes, but are not always successful.

as for which i prefer, it's the lesser of 2 evils question. the only problem i have is if the junior developer won't learn when i discuss with them about either writing unmaintanable code or using patterns inappropriately. that's usually very rare and a sign they don't care.