Design Patterns  «Prev  Next»
Lesson 1

Introduction to Design Patterns Course


Welcome to GOF Patterns which is the acroynm for Gang of Four Patterns.
The first module in this course presents you with the groundwork in preparation for the material that you will be reading.

Course goals

In this course you will learn what the GOF (Gang of Four) patterns are and how they help solve common problems encountered in object-oriented design. After completing this course, you will be able to:
  1. Use creational patterns to create objects when constructors will not serve your purpose.
  2. Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.You will learn how to use behavioral patterns to reduce complicated flow control.
  3. Furthermore, you will use behavioral patterns to encapsulate algorithms and dynamically select them at run time.
  4. Structural patterns deal with the composition of classes or objects.
  5. The 2 most common techniques for reusing functionality in object-oriented systems are
    1. Class Inheritance and
    2. Object Composition
  6. You will learn how to use the Gang of Four Pattners (Design Patterns) to replace inheritance[1] with composition.[2]

The pattern name is a handle we can use to describe a design problem, its solutions, and consequences. Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about these patterns with our co-workers and to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others.

The problem describes when to apply the pattern and explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.
The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements solves the design problem.

What Is a Design Pattern?

A design pattern is a general reusable solution to a commonly occurring problem within a given context. What does that mean?
Programmers often encounter the same problem repeatedly. Rather than have everyone come up with their own solution to common programming issues, we use a best practice type solution that has been documented and proven to work.
The word general is important. We cannot just copy and paste a design pattern into our code. A design pattern represents an idea, and we should write an implementation for that pattern and implement that in our code.

Advantages of Design Patterns

Using a design pattern has a few advantages. We get to use a solution that is known to work. The tradeoffs, if any, are well documented, so we do not stumble over problems that have already been solved. In addition, design patterns also serve as communication aids. Your project manager can say, "We will use a singleton,"" and that one word is enough to tell you what is expected.
When books or web pages document patterns, they do so using a consistent format. We pay homage to this universal format by including sections for the
  1. Problem,
  2. Solution, and
  3. Benefits
of the singleton pattern. The Problem section explains why we need the pattern, what problem we are trying to solve. The Solution section explains how to implement the pattern. The Benefits section reviews why we need the pattern and how it has helped us solve the problem. Some of the benefits are hinted at in the Problem section. Others are additional benefits that come from the pattern.
[1]inheritance: The concept of classes automatically containing the variables and methods defined in their supertypes.
[2]composition: Creating objects with other objects as members. Composition should be used when a has-relationship applies