 Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green, and with me is Phil Jepixi. Hey, Robert. Hey, Phil and I are continuing our series on design patterns. Correct. And today we are going to talk about the template method pattern. True. So let's, as we've done with the other ones, pull up the definition, courtesy of Wikipedia, and the template method pattern defines the program skeleton of an algorithm in an operation deferring some steps to subclasses. Whole lot of mumble, jumble words, right? Really what we're talking about is we want base classes to have specific implementations of certain steps of a process. Okay. Right? We want the process to happen in the right order. We've been using the e-commerce example through all the episodes so far. Take the order, pick the order, pack the order, ship the order. Right. Right? Think about making a pizza. Mm-hmm. You certainly want to take the order, process the payment, which we forgot to mention just prior. Make the pizza, cook the pizza, cut the pizza, box the pizza. Well, we got to box it. Box it. Right? See, that's where we have a template. As soon as, maybe, or plate it. Or plate it. Right? Well, let's say it's going out for delivery. Yeah. So you don't want to get that order messed up. No. Right? You don't want to put it in the box and then put it in the oven. That would be bad. Right? Right? So we want this. But that can't possibly be the pattern. No, that's not the pattern. Do things in the right order. But that's part of it, right? So we've got this template to do things. Yeah. Right? So defines the program skeleton of an algorithm. So the algorithm is, how are we going to make this pizza? But it's the deferring some steps to subclasses that makes it part of the pattern. Because if it's just, oh, what are the five steps you need to do to make a pizza? Get them in the right order. That's not the pattern. No, because you could do that with the command pattern. Right. Right? Well, you could do that by writing the right code for crying out loud. Well, yeah. Right. Okay. So you can read the fine certain steps of an algorithm without changing the algorithm structure. Mm-hmm. Right? So let's say if cooking the pizza, you're only going to half bake it. Or you're going to twice bake it or things like that. Right? So a derived class can change how that particular step works. Okay. But I haven't rewritten the algorithm. The algorithm itself is still the same. Cool. Right? Right. All right. So let's look at the code. And this is one of the rare ones where I don't have unit tests around it. But it's a pretty self-explanatory pattern. Mm-hmm. But I think there's a lot of... It's pizza that's going to pass. Yeah. There's a lot of... Pizza is good, right? It's how you get all the developers in one room, right? You bring in free pies. So here is my abstract base pizza store. Okay. And I have to thank the... You know what? We haven't been mentioning resources in any other episodes. But one of the things that we're going to put in is a link to the headfirst design patterns. And we'll put that in all the show notes. That's an awesome book. And so I want to thank them for inspiring the whole pizza theme that we'll see in several other patterns as well. So here are our pizza steps. Take the order. Process the payment. Make the pizza. Cook the pizza. Deliver the pizza. And then we're returning this out of the method. Didn't really need to do that. Okay. But we are. And we've got some things that aren't going to change regardless of the type of pizza. Right. Processing the payment and delivering it happens the same. Yes. Regardless of the type of pizza. I'm going to charge a credit card. I'm taking cash. However that works. You got to calculate the price. Calculate the price might be something that varies but not actually processing the payment. And delivering the pizza is the same across all pizzas as well. It's entirely possible that depending on the pizza you make you could deliver it differently but. It is possible and then you would have to extend this to overwrite that. Yep. Right. Okay. So we've got these base implementations for processing. So it's the fact that take order make pizza cook pizza that's always going to happen but how it happens can be different and therefore you put it in an abstract class. That's what makes this the template method pattern. Yeah. And to be clear it doesn't have to be abstract. I could have made those virtual and have a standard implementation which for example we could have done with the deliver pizza. Okay. So if it's a hot pizza it's always delivered the same way. Right. But let's say you're going to order a or deliver a half baked pizza at the one that you finished cooking at home. Maybe that has a different delivery style. Maybe it has to be refrigerated. Okay. Who knows. Right. But the fact that the implementations of these live somewhere else and are brought in at runtime that's what makes this the template method. Going back well they're actually brought in at design time not runtime. Because we've got these classes built we're not changing the implementation at runtime. Okay. We're defining the implementation at design time. At runtime we could pick a different style of pizza store. But that's not the strategy pattern. We're just picking a different implementation. Okay. Right. So again we've got the program skeleton defined and we're deferring some steps to subclasses. So we've deferred the make pizza cook pizza and take order to a subclass. Okay. Now the reason to take order I love my Chicago style pizza. My wife loves the New York style pizza. But you take the order differently. Right. Because it's a different set of ingredients and different options. So that really needs to be subclass. So I've got my New York style pizza store. And there's no real implementation here because again I'm just trying to show the pattern. Right. Okay. But for take order I'm going to operate on this pizza for delivery which is defined in that abstract class. That's the eye pizza in the abstract class. And this is probably a great place for the basic factory pattern. We haven't aired that show yet but it'll be coming up as part of this series. But just know that we're going to return some sort of eye pizza. Probably be a thin crust. It's New York style. Spicy ingredients, lots of sauce. Right. And then we're going to make the pizza. And it's going to be thin crust. So we have to cook it less. Maybe blue Chicago style pizza would have to cook it longer. Right. So it's a specific implementation is deferred to the derived class. That's like make and cook. Right. Both fall into that. Right. Right. So probably cooked in a wood-fired oven for New York style pizza and a different style of onion for Chicago style pizza. Right. So that's the crux of the template method. One thing that you'll notice when we get to the factories. So you would then have a separate class for the various types of pizza. Correct. And if you created a new type of pizza that you were offering you would just have a new implement a new class different style pizza store which still has a take order make pizza cook pizza the steps are the same but how you do it is differently but regardless you're always processing the payment and delivering in the base class. Correct. Okay. And what you just maybe inadvertently called out is one of the problems with the template method is if I have a Upper East Side style pizza where the only difference is maybe the types of ingredients not pepperoni cheese but the type of cheese or the type of pepperoni now I have to create a whole new derived class handle that one method. Okay. Right. When we get into the factory patterns and there's three at well two and an honorable mention but we'll just call it three you'll see where it takes the template method and fixes that problem but for a lot of implementations this is great because again going back to that e-commerce thing if I have probably the level I would do is books perishables fragile right and so again taking the order processing the payment picking packing shipping but if I know that perishables need to be shipped a certain way impact a certain way and fragile versus books or things like that right so now we've got the take order and delivery in the base class I'm going to send it out to UPS or United States Post Office or I gotta make sure I hit everybody since you don't have sponsors FedEx I'll be like NASCAR here I'll just have stickers all over me for delivery companies yeah that would be the template method right so we've got this base but but you can have an explosion of classes with this right because every time I need a variation now I'm making another yeah now I could also implement this I'm using the strategy pattern right where I can I where the take order make pizza and cook pizza change at runtime based on the type of pizza that's being ordered yes we covered strategy pattern in the previous episode so what how would I know which one to use or how would I decide well some might say it's a coin flip okay I would say that this is probably not the strategy pattern because you're really not changing at runtime you're going to know ahead of time that this type of pizza gets cooked this way okay there's other type of pizza get cooked this other way now if you wanted to take a Chicago style pizza and not cook it all the way then maybe that's a strategy pattern right or maybe you should just make pizza the right way well or you're stuck in a hotel that doesn't have an oven and you bought a Dijon pizza and you're trying to cook it in a pan so which by the way doesn't work I can tell you from experience so but that's changing the implementation at runtime as opposed to at design time right so at design time I'm changing it because I'm pulling in a different class right I'm instantiating a different object of that interface got it right and runtime it's still for the strategy pattern it's still the same instance I'm changing its behavior at runtime not picking a different implementation detail okay make sense yep so we talked about some of the drawbacks that you could have code creep right and just explosion of classes but this is the kind of the first time we mentioned patterns aren't in isolation normally some kind of are like the the simple factory pattern you don't normally combine with a lot of others but even when we look at this what what kind of screams out at you where I've got take order and make pizza and deliver pizza you already said it that's like the command pattern right yeah go do something I don't care how it gets done right just go do it right so now we've got the command pattern tying into the template method yeah we're also going to see that in the factory patterns in lots of different places so while the command pattern and memento were pretty simple to talk about the reason I felt they needed their own show is because they're foundational to so many others okay and we're going to keep seeing in this recurring theme of how these all work together so let's say process payment and delivery pizza also changed based on the type of pizza so all five of these methods were in a different class okay is it still the temp the template method pattern so by definition what if all all of the functionality then we'd actually be looking at the factory method okay pattern okay which they're very similar and I thought about doing them together like we did the command and memento but they're different styles of patterns this is a creational sorry this is a behavioral pattern and the factory is creational okay so and again it's an arbitrary it's an arbitrary some wicked smart people when they put their book together came up with these definitions but I right I never sit there in code and say well I had a behavioral here and go through my list I'm looking at this code saying how how has this been solved before and I remember patterns I don't always remember which category they're in right right so you're going to see some that are similar and they're cousins sometimes second cousins sometimes they're not related at all but but that's pretty common in software design right because there's really nothing new that we're doing in software I mean there's new tooling and there's new processes like agile and test development things like that but at the end of the day what we're writing gets translated into ones and zeros and goes through a processor and does something right right so I think that's it okay cool the nails it template method pattern yes sweet all right hope you enjoyed that see you next time when we'll look at another pattern thank you very much