Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Introduction to Design Patterns!
You have completed Introduction to Design Patterns!
Preview
Let's take a look at the format of a well-defined Design Pattern as described by the Gang of Four.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Before we start digesting these patterns,
0:00
let's quickly revisit our
design pattern definition.
0:02
The context is the situation
in which the pattern applies.
0:06
In our adapter design pattern example,
the context is that we have objects,
0:10
the outlet and my hair dryer, that don't
interact the way that we want them to.
0:14
The problem refers to the goal that you
are trying to achieve in this specific
0:19
context as well as any constraints
that may occur in that context.
0:23
Again, I'm traveling, and
I want to use my hair dryer, but I can't.
0:28
The solution is what we are after,
a general design that anyone can apply.
0:33
It resolves the goal and
the set of constraints.
0:38
Hey, why don't we use a power adapter?
0:41
Now, in order to express
all that information,
0:44
the Gang of Four suggests a specific
format for describing a design pattern.
0:47
That format includes
four essential elements.
0:52
The pattern name.
0:56
This is how we create
the shared vocabulary.
0:57
The problem describes when to
apply the pattern and the context.
1:00
Sometimes this might contain
a list of conditions.
1:05
The solution portion describes
the elements that make up the design,
1:08
the relationships, responsibilities,
and collaborations.
1:12
Again, this is not code.
1:15
Rather, it's a high level abstraction that
will apply to many different situations.
1:16
It often contains diagrams to
help further explain things,
1:21
we'll go over one of those here in a bit.
1:24
Consequences is an important section.
1:26
Patterns can have costs.
1:29
Some take more time than others,
some are more complex than others, and
1:31
some create more required files,
which take up more space.
1:34
This section discusses the tradeoffs
of using this pattern.
1:38
You should use the information here
to determine whether the benefits of
1:42
using the pattern actually
outweigh the costs.
1:45
I wanted to stress these elements
because I find them pretty important in
1:49
understanding the pattern.
1:52
These patterns have spread quite
far since their inception.
1:54
And you'll find tons of websites and
wikis listing these patterns.
1:57
In fact, the first wiki was created
to share and discuss design patterns.
2:01
I want you to be aware that
not every site that lists
2:06
design patterns include all
these essential elements.
2:09
Sometimes sites leave out the consequences
section for the design pattern, and
2:11
that's no good.
2:15
You should always understand the possible
pitfalls of using a pattern.
2:17
Also, many of the catalogs out there
have taken liberties in how they label
2:21
the different sections.
2:25
So there very well may be synonyms for
the essential elements of name, problem,
2:26
solution, and consequence.
2:30
Ready to take a look in detail at
one of these patterns I've been
2:33
yammering on about?
2:35
Let's take a look at one site that does
a great job at describing design patterns.
2:38
It's one of the top search results when
you go searching for design patterns.
2:42
It's called oodesign.com.
2:45
Here, I have it up here.
2:47
So as you can see, there are a lot of
different design patterns here, and
2:49
they're grouped in these
different categories.
2:53
So let's do this, let's look for
a specific pattern and
2:55
then we'll take a look at it.
2:57
So here, here's the adapter pattern.
3:00
Hey, look, here's our friend adapter.
3:02
Now, after we browse how
this page is laid out,
3:04
we'll go over how patterns are typically
categorized in more detail.
3:06
Okay, so here the motivation header is
used to describe the problem, okay.
3:10
Cool, look, they're using
a camera memory adapter analogy.
3:16
So the example here has definitely been
updated since the original Gang of Four
3:20
book was published.
3:23
I'm pretty sure that plugging
camera memory into your computer
3:24
didn't exist when the original
pattern was created in the mid-90s.
3:27
See how these examples
can evolve a bit and
3:31
are totally left up to
the publisher's discretion?
3:32
I really like this intent section here.
3:35
It gives a nice overview
of the solution at large.
3:38
So it says convert the interface.
3:41
Ooh, this is a good time
to talk about something.
3:43
You see how this intent here,
it uses the word interface.
3:46
Now, if this terminology is new to you,
3:50
interface refers to the public facing
operations that your object can perform.
3:52
You know, the I in API,
application programming interface.
3:57
Now, not all languages have
a keyword named interface.
4:02
Some languages use the keyword protocol.
4:07
Some languages with looser typing refer to
implementing an interface using the cute
4:09
analogy-based term duck typing.
4:14
Duck typing kind of goes like this.
4:16
If it looks like a duck and
quacks like a duck, it's a duck.
4:18
So basically, this intent here is
suggesting that by creating an adapter,
4:22
you can make it, well,
4:26
quack like the client is expecting while
leaving your original object intact.
4:28
Okay, now let's move to the third
essential element of the design pattern,
4:34
the description, the solution, or
as it's labeled here, implementation.
4:37
This is what is known as a class diagram
in a standard format named UML or
4:43
Unified Modeling Language.
4:48
Now, if this is new to you,
it might look a little overwhelming and
4:50
like a super confusing flow chart.
4:53
But don't worry, once you get the gist of
what the diagram communicates, it's not so
4:55
difficult to understand.
4:59
So let's break it down a bit.
5:01
Now, each of these target boxes here,
right, represent a class.
5:03
So see how the word target
here is in italics?
5:10
Italics identify an abstract class,
meaning that the class contains required
5:14
behavior that must be defined
before it can be used.
5:19
The required behavior here that's being
expected is defined in the operations
5:23
area here.
5:28
And it's called request.
5:29
Note that request here is just an example.
5:31
It's a sample method name that
will help you visualize the class.
5:34
Actual method names will depend entirely
on what the client over here is expecting.
5:38
Now, there's an arrow here between
the client and the target, and
5:44
it's known as a directed association.
5:48
It's stating that the client depends
on the target abstract class.
5:51
Here, again, it's saying,
5:55
the client depends on an object that
provides the method with the name request.
5:57
And not vice versa, right, it's a one way.
6:02
So, again, this can be read as,
6:06
the client depends on an implementation
of the target abstract class.
6:08
[LAUGH] I realize that was a ton of
information that I just threw at you.
6:13
Sorry about that.
6:18
Now, not all languages have
built-in abstract classes.
6:19
So that might be new to you.
6:22
But don't fret too much about it.
6:24
The important thing to understand from
this diagram is that in order to adhere to
6:25
the specific class's needs, a method
with the name of request must exist.
6:29
So you can kind of view this
request method as the interface or
6:36
protocol that we talked about earlier.
6:39
It could be named quack.
6:41
Naming here doesn't really matter.
6:43
Okay, so
let's keep moving through the diagram.
6:45
It'll make more sense here in a second,
I promise.
6:48
All right, so next up in our class
diagram here is the adapter.
6:51
So see an arrow pointing
up from the adapter?
6:56
Notice how adapter is not italicized.
7:00
It's a concrete class.
7:02
That means a class that actually
implements the request method.
7:04
And the interface up here is just
a concept, and an abstract one at that.
7:08
But in the class here, it's a realization.
7:13
Code has been written that defines
what happens when request is called.
7:16
You've got it?
7:21
So note here that there's
this open arrowhead.
7:23
Can you guess what that
arrow is depicting?
7:26
That's right.
7:29
It's stating that the adapter
fulfills the requirements of target.
7:30
This type of arrow is what is
known as a generalization.
7:34
It's a way of showing inheritance.
7:38
So in other words, adapter is a target,
7:41
and therefore it can
be used by our client.
7:45
And that makes sense, right.
7:49
The client wants an object that
has the operation of request,
7:50
which our new adapter, it totally does.
7:54
Okay, and last and
definitely not least in our class diagram,
7:58
over here is our original object,
the adaptee.
8:02
Now, nothing changes about this class.
8:06
And again, there's a directed association.
8:08
And it shows that the adapter knows
about and depends on the adaptee.
8:11
An adapter doesn't do too much
good without having an adaptee.
8:17
The adaptee has whatever method it wants,
and you'll see,
8:20
over here there's a note,
it says it has adaptee.specificRequest.
8:23
And what that's saying is that
when request here is called,
8:26
it's actually calling the adaptee-specific
request, it's just kind of wrapped, right.
8:29
Can you imagine that?
8:33
And again, these methods here
are really just an example.
8:35
Really, whatever the client expects,
whatever this client expects,
8:37
the adapter implements.
8:41
And it translates whatever has going on in
the adaptee to meet these method names,
8:43
that's it.
8:47
For more on UML and class diagrams,
please check the teacher's notes.
8:49
We'll run through a few more
later in this workshop.
8:53
So you'll get more time practicing,
translating these useful diagrams.
8:56
Now, don't worry, I don't expect
you to create these just yet.
9:00
Okay, so onwards through the description.
9:04
Here the pattern starts
talking about applicability,
9:07
which really helps nail down the context.
9:09
Then here is the ever-important
consequences section, or
9:12
as it's often called here,
specific problems.
9:16
Most patterns also have a see also
section which lists similar patterns.
9:19
You should always check these out as they
might be the pattern you're looking for.
9:23
Quite literally, it's the original
wikihole where clicking one link leads you
9:27
to another interesting page, which leads
to another, which leads to another.
9:31
All right.
9:36
So now that we know how patterns
are more or less laid out and
9:37
how to roughly read class diagrams,
let's dive a little deeper.
9:40
But before we do that, I wanted to remind
you that any time you see the word adapter
9:44
in a class name, it is most likely talking
about this pattern that I just showed you.
9:48
If you want to see this pattern or
9:53
any other pattern in action,
you can search on GitHub.
9:54
Adapter currently yields
about 63 million results, so
9:57
you should be able to
find some great examples.
10:01
As you saw in the OO design pattern site,
10:04
patterns are typically
grouped into categories.
10:06
The three main categories defined by
the Gang of Four book are creational,
10:09
behavioral, and structural.
10:13
Let's take a look at each one of these
categories over the next few videos and
10:15
really get familiar with their names so
10:18
that you can recognize them
when you encounter them.
10:20
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up