Design Pattern Benefits

Question: Why would you use design patterns?
Answer:The answer is so simple it is almost a tautology: Design patterns are used because they make your job easier.
Design patterns let you write better code more quickly.
However, patterns are not a panacea. Of the five phases of software development, design patterns do almost nothing in the analysis, testing, or documentation phases. Design patterns, as the name implies, have their biggest impact in the design phase of a project.

Software development (as opposed to mere coding) can be divided into five stages:

1. Analysis - understand the problem to be solved; gather user requirements
2. Design - choose the data structures,
   1. algorithms,
   2. classes, and
   3. patterns
   that will model the problem; possibly prototype the system, especially if it has a large user interface component
   
3. Code - implement the design in code
4. Test - debug and correct mistakes
   
5. Document - write the user documentation for the system (should ideally occur throughout the development process)

A number of years ago, each of these stages took roughly 20% of the total time in a project, though today the actual writing of code is likely to be the shortest of the phases. One common source of project overrun is only accounting for what is to most programmers the most interesting phase, writing code.
Many efforts have been made to make the writing of code more efficient.However, relatively little effort has gone into increasing efficiency in the other four stages.

Most of the good programmers I know have a certain style that points to professional programming habits. When you encounter good OOP programming, you will see a certain way of doing everything from naming variables to commenting code. Variable names are clear, and comments in the code tell the story of the code so that other programmers know how to connect to their own modules. I have often found that putting in too many comments get in the way of clearly seeing the structure of the code. So, with the goal of being able to see and sense objects as complete entities, the code is not fractionalized by long-winded comments.

Languages like .NET (dot NET) have sprung up to fill certain marketing and technology voids left open by the languages Java and C++, and have adopted design patterns in one way or another to mimic what was learned by programmers in Java and C++. Even the previously script-oriented syntax of Visual Basic has blossomed into a fully object-oriented language, by means of Visual Basic.NET. Microsoft also added a Java-like language, which has related syntax and framework structure, in the form of C#, which is so much like Java that applying design patterns is a relatively expected hypothesis.
Most programmers new to object-oriented languages seem to have the same dilemma when faced with whether or not to use or learn design patterns:
Why should I? Usually the problem is that the ability and time required for learning patterns-based programming is at a premium and the return seems dubious. Someone not familiar with the why behind the methodology certainly will not continue on to the what and where. So explaining to people new to the concept why they should spend the time learning design patterns can be difficult.
Another issue is availability and ease of dissemination of the relevant data. There have been numerous books and papers written on the uses and methodology of design patterns, but to a junior developer looking to improve basic skills or learn the skills needed to get a job, having to read complicated texts to learn a new methodology or way of thinking may prove challenging.
Senior developers looking to upgrade current skills can have similar issues, in that to augment their skill sets they have to conduct research just to be able to understand the basics. Most of the texts available on design patterns are not easily referenced, and require an expanded understanding of object-oriented methodologies and patterns. There have been a few attempts to make the theory easier. However, these attempts seem to be more adventurousv than useful, and leave project developers a little turned off by the lack of serious content of the work.

As a developer I can assure you I have had the same problems. Whether learning to use patterns or teaching them to others, I found there was no quick and easy reference to explain or learn which pattern is appropriate in which case and why.
I learned more about the basics of object-oriented design by visiting when learning patterns, and had to learn the hard way which methods worked where. One thing I did find was that design patterns were created and have evolved from the work of everyday code practices, and many developers are using them without actually knowing the established 23 patterns. When I first started to pattern, I often had to search through many texts and websites, accessing several sources to understand a particular pattern. This was hard when trying to meet deadlines, since time was crucial, and the only reason I persisted in learning was because I saw there was a lot of value in what I did manage to understand.

The following quiz contains questions with respect to the purpose of design patterns.
Design Patterns Purpose - Quiz

[1]Delegation: This pattern is one where a given object provides an interface to a set of operations. However, the actual work for those operations is performed by one or more other objects.

[2]composition: Creating objects with other objects as members. Composition should be used when a 'has-a' relationship applies.