This entry is a response to the “Design Patterns from a Junior Developer perspective” blog post written by s0954168 .
In the article, the author explains how junior programmers may have difficulty in understanding and using design patterns correctly. Additionally, significant portions of the article are backed by experience of the author and the attempts that were made to learn and apply these common techniques used to aid programmers solve a given problem.
Overall, I agree with the vast majority of things said in this article. Coming from a similar background, I can appreciate the apparent problems of fully understanding the benefits of a particular design pattern that inexperience brings. However, as is implied by use of the word “Junior” in the title, I feel that the article has not focused on the major problem of truly appreciating these patterns: experience (or lack thereof).
The author talks about the origin of the design patterns by mentioning “countless systems implemented in the past” and “somebody has already solved this problem for you”. While this is makes perfect sense as a logical explanation, it misses out on the finer detail. When clever solutions to existing problems have been used and this solution could be abstracted out, one could reuse this solution to discourage other people from making the same mistake and more importantly, to have a common understanding of a solution. So the formal creation of the pattern comes after someone has already used it and has determined that it is applicable in a general sense of solving a particular problem. The more people that are currently working in a particular frame of reference, the more solutions may potentially be created. Thus, the popularity of a programming paradigm could influence the amount of design patterns available.
What I am trying to say with this is that design patterns aren’t a completed set of ways to solve a problem. More patterns will be created, especially if other programming paradigms become more popular, meaning that the existing patterns may be tailored to existing problems. The problem with a junior developer is the potential ignorance that will be exposed by the individual by assuming that every problem can be solved with an existing technique.
A related problem is that because of this perceived completeness, inexperienced programmers may try and fit their problem to a pattern, which is the exact opposite of the intended purpose of a design pattern.
I know I am guilty of this. I think most beginner programmers starting out in larger projects, that could benefit from design patterns, are guilty of this too. I love this quote from an answer on stackoverflow  which sums up both the opinion of the author and myself: “Novice programmers don’t use design patterns. They abuse design patterns.”
Design patterns example
In the article, the author gives an example of a single design pattern: the Singleton. For readers to completely appreciate what the author is talking about in terms of the complexity of understanding where to use a given pattern, I believe an additional pattern would have been a welcome addition. The singleton object is the simplest one, and adding others like Dependency Injection or the Bridge pattern may have been helpful in cementing the case that is the difficulty in knowing when and where to use them.
When to use design patterns?
In this section, the author talks about knowing which pattern to use, as well as knowing when not to use a pattern. As the author mentions, using the patterns in every possible situation may lead to increased code and architectural complexity; the one thing that use of a pattern is trying to hinder. Contradictingly, the author mentions that refactoring is a “perfect example” of when you might be able to insert a pattern. I say contradictingly because when refactoring, the goal is generally to clean up a particular solution. Adding a pattern may needlessly introduce more complexity to a solution. However, this may be a semantic issue; I classify a solution that needs alteration in the entire logic (which is what a design pattern may end up doing) as rewriting as opposed to refactoring. Nevertheless, adding patterns when the intent is to tidy up a solution, seems contradictory and is a point where I disagree with the author.
The one case that I feel the author has failed to mention, and I’ve alluded to earlier, is that experience with these patterns and solving architectural problems is the key to understanding when to use a design pattern. Of course, the title and the article is aimed at junior developers and therefore less experienced individuals. However, the case is never made explicitly that experience matters and so it may be hard for a reader to exactly see why a junior developer may have more trouble in appreciating the use and abuse of design patterns. Peter Norvig  claims in his blog post that just like any other discipline, 10000 hours of work is required before you truly know the domain. A derived conclusion of this is that a programmer needs to spend the same amount of time on general architecture before being able to recognize the applicability of a design pattern for a given problem.
Even though the blog post is about how junior developers can make use of the design patterns, the article could benefit from talking in greater detail about how design patterns help solve a particular problem. Understanding exactly how a particular design pattern applies to a problem, will not only allow a reader to see the difficulty in choosing a pattern, but also why an inexperienced programmer may abuse them. All in all, I agree with the author on grounds of personal experience (I also attempted to use a design pattern for EVERY problem I encountered) and would like to commend the author for writing a post on a topic that every novice programmer should have on the frontiers of their thought when starting out in large-scale project development..