History: Objectives: Design Patterns

Objectives: Design Patterns
After completing this tutorial, you will be able to:

1. Explain what a pattern is.
2. Explain the origin of pattern usage.
3. Utilize patterns in future programming projects.
Before starting this tutorial, you should:
1. Have experience writing programs in a high level language, using multiple
modules (4 or more is what I have in mind).
2. Be familiar with C++. Although you can do without this knowledge, the examples
will make much more sense.
3. Basic familiarity with Booch or OMT class diagrams.
4. You'll need some time. This isn't light reading!
Knowledge about the items above will yield a much greater and indepth understanding of the concepts discussed in this tutorial, and the
presentation. A reader without these skills can still benefit from the
material here, and will at least walk away with knowledge about what a
design pattern is all about.
The primary purpose of this presentation is to give the reader an
introduction to the concept of design patterns in programming. After
completing the tutorial you should be able to put to use the patterns
that were discussed, and have the ability to go out and find new
patterns in publications etc... What this tutorial is not trying to do is
explaining in great detail each of the example patterns; this is done
very will in the Gamma95 reference.
Conceptual Overview: Design Patterns

A pattern is a fully realized form, original, or model accepted or
proposed for imitation...according to a dictionary.
History
The origin of design patterns lies in work done by an architect named
Christopher Alexander during the late 1970s. He began by writing two
books, A Pattern Language[Alex77] and A Timeless Way of Building
[Alex79] which, in addition to giving examples, described his rationalle
for documenting patterns.
The pattern movement became very quiet until 1987 when patterns
appeared again at an OOPSLA conference. Since then, many papers
and presentations have appeared, authored by people such as Grady
Booch, Richard Helm, and Erich Gamma, and Kent Beck. From then
until 1995, many periodicals, featured articles directly or indirectly
relating to patterns. In 1995, Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides published Design Patterns: Elements of
Reusable Object-Oriented Software [Gamma95], which has been
followed by more articles in trade journals, and an additional book by
&ltTo be filled in later&gt.
Patterns Defined
Patterns are devices that allow programs to share knowledge about
their design. In our daily programming, we encounter many problems
that have occured, and will occur again. The question we must ask
ourself is how we are going to solve it this time. Documenting patterns
is one way that you can reuse and possibly share the infomation that
you have learned about how it is best to solve a specific program
design problem.
Essay writting is usually done in a fairly well defined form, and so is
documenting design patterns. The general form for documenting
patterns is to define items such as:
1. The motivation or context that this pattern applies to.
2. Prerequisites that should be satisfied before deciding to use a pattern.
3. A description of the program structure that the pattern will define.
4. A list of the participants needed to complete a pattern.
5. Consequences of using the pattern...both positive and negative.
6. Examples!
Tutorial: Design Patterns

Back to overview.
Read the Overview before proceeding with this section!
I recently read something to the effect that mastering the use of a set
of patterns is the ultimate goal of someone intending to seriously study
design patterns. That said, here we go...
There are 3 examples in this tutorial. They are progressively more
complex. Here's the first one, Singleton, rather simple.
Example 1 : Singleton
[Gamma95]
Rationalle and Motivation

The singleton pattern applies to the many situations in which there
needs to be a single instance of a class, a single object. It is often left
up to the programmer to insure that the An important consideration in

implementing this pattern is how to make this single instance easily
accessible by many other objects.
Classes
There is actually only one class that needs to be written specially to
implement the Singleton pattern. A second client class will always be
involved take make requests from the singleton.
Here is what a Booch [Booch94] class cloud might look like:
Advantages
What are the advantages to using this pattern?
Single instance is controlled absolutely. When implemented as the
pattern recommends, the class will have direct control over how many
instances can be created. This is in contrast to making the programmer
responsible for insuring that there is only one instance.
This pattern is easily extensible to allow a controlled number of
"singleton" objects to be created. The most important modification
needed to accomplish this change is in the operator that has control
over access to the instances. In this case, the Instance() function would
need to be changed.
Examples Here is how a generic singleton might be written in C++. If
you want to try it, here is the source code: singleton_ex.tar
class Singleton {
public:
static Singleton* Instance(); // gives back a real object!
static proof(void);
// proof that the object was made
protected:
Singleton();
// constructor
private:
static Singleton* _singleton;
};
And the implementation like:

Singleton* Singleton::_singleton = 0;
Singleton* Singleton::Instance()
{
if (_singleton == 0)
{
_singleton = new Singleton;
}
// end if
return _singleton;
// end Instance()
Food for thought...

What about sub-classing? How can we make the implementation more
flexible? Possibly for reuse, or maybe for using multiple singletons in a
single program. So what really happens if you try to explicitly declare a
Singleton object?
Example 2 : Facade
Rationalle and Motivation
The facade pattern can make the task of accessing a large number of
modules much simpler by providing an additional interface layer. When
designing good programs, programmers usually attempt to avoid
excess coupling between module/classes. Using this pattern helps to
simplify much of the interfacing that makes large amounts of coupling
complex to use and difficult to understand. In a nutshell, this is
accomplished by creating a small collection of classes that have a
single class that is used to access them, the facade.
Classes
There can be any number of classes involved in this "facaded" system,
but I would think that the minimum is four classes. One client, the
facade, and the classes underneath the facade. In a typical situation,
the facade would have a limited amount of actual code, making calls to
lower layers most of the time.
Advantages/Disadvantages
As stated before, the primary advantage to using the facade is the
make the interfacing between many modules or classes more
managable. One possible disadvantage to this pattern is that you may
lose some functionality contained in the lower level of classes, but this
depends on how the facade was designed.
Examples
Imagine that you need to write some program that needs to represent
a building as rooms that can be manipulated. Manipulated as in
interacting with objects in the room to change their state. The client
that has ordered this program has determined that there will only be a
need for a finite number of objects possible in each room, and a finite
number of operations that can be performed on each of them.
You, as the program architect, have decided that the facade pattern
will be an excelent way to keep the amount of interfacing low,
considering the number of possible objects in each room, and the
actions that the client has specified.
A sample action for a room is to "prepare it for a presentation". You

have decided that this will be part of your facade interface since it
deals with a large number of classes, but does not really need to
bother the programmer with interacting with each of them when a
room needs to be prepared. Here is how that facade might be
organised.
Consider the sheer simplicity from the client's side of the problem. A
less thought out design may have looked like this, making lots of
interaction by the client necessary.
Food for thought...

The compilers that we use everyday to process the computer code that
we have written is a prime example of the facade pattern in action.
What other examples are there that you can think of?
System Requirements: Design Patterns

No specific tools are needed to use Design Patterns.
It would probably be appropriate to have a compiler for your objectoriented language of choice. Typical examples are C++ and Smalltalk.
Language features such as polymorphism, inheritance, classes, and
objects are often refered to, directly or indirectly when patterns are
discussed. It is therefore helpful to have the features available in the
target language.

History: Objectives: Design Patterns

Uploaded by

Copyright:

Available Formats

History: Objectives: Design Patterns

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

History: Objectives: Design Patterns

Uploaded by

Copyright:

Available Formats

Objectives: Design Patterns

After completing this tutorial, you will be able to:

Conceptual Overview: Design Patterns

Tutorial: Design Patterns

Rationalle and Motivation

up to the programmer to insure that the An important consideration in

And the implementation like:

Food for thought...

A sample action for a room is to "prepare it for a presentation". You

Food for thought...

System Requirements: Design Patterns

You might also like