What Makes a Pattern10:22 with Craig Dennis
Let's take a look at the format of a well-defined Design Pattern as described by the Gang of Four.
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 up