Coding Blocks - Design Patterns Part 2 – Oh behave!

Episode Date: September 5, 2014

This week we’re following up on our episode about talking about Creational Design Patterns a few of our favorite behavioral patterns: Template. Strategy, and Null Object. Also, pumpkin spice lattes, Mario’s pants, and a billion dollar mistake. Points of Interest Pumpkin Spice Latte is back! Great feedback from NDepend, great things coming in V6! LG […]

so what kind of pants did mario wear i heard this joke do you know no denim denim denim you're listening to coding box episode 16 Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And visit us at codingblocks.net where you can find show notes, examples, discussion, and much more. Send your feedback, questions, and rants to comments at codingblocks.net

and follow us on Twitter at Coding Blocks or head to www.codingblocks.net and find our other social links at the top of the page. And with that, welcome to CodingBlocks. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. And today we're going to be talking about some more design patterns. So we got a lot of good feedback on the last show and we're finally coming back to it.

And today we're going to be focusing on just a couple of the behavioral patterns because there's like you know like teens of them maybe even 20 yeah there's a lot so we each got one to talk about and we're excited about it yep so first though let's get started with some podcasting news what we got over here i think this is your favorite one jay-z yeah i i want this one i want to say it pumpkin spice latte is back where's this uh oh what it's starbucks we've got some international listeners so you know i you know i feel for you if this isn't available to you but for them it's at le starbucks yeah man it's like 525 for a little drink of heaven i don't know the pumpkin anything like that doesn't sound good it's not really pumpkin this man's not really pumpkin.

This man's addicted to pumpkin and everything, though. He used to have pumpkin creamer. Oh, yeah. Yeah. It's so good. All right. We also got some feedback from Patrick on Independent, and we have a whole list of things here. So it was Patrick Smokia responded to our gripes,

which, I mean, he actually took the times he he took the time to respond to each one of them so one of them was like attaching to the solution had benefits uh what was i forget exactly how he put that yeah he let him do um different things to different projects and different kind of views and you could detach it too well yeah okay so not only did he mention the detaching which i don't know in all fairness if we had mentioned but like one of the things specifically that he said was a benefit to to doing it the way he was was that you could specifically say these are the assemblies that i want and depend to uh you know to to track to monitor oh okay yeah all right so there were a lot of great things that he had in there. Like my favorite was he sent us an early screenshot of the dark theme being honored in Visual Studio.

That's awesome. I think that was Michael's biggie. Oh, my God. I'm going to be so happy to see that one. Yeah, and he actually wrote us and sent some screenshots and was like, is this what you guys are talking about with the column headers that Alan had been talking about? So he really took the advice and suggestions to heart, which is really cool. And he just seems like a really nice and honest guy.

I think that was one of the most interesting things about the whole thing was like, you know, the few like they weren't like you called them gripes just a moment ago. I mean, they were nitpicks. They were nitpicks. They weren't horrible things. None of them. But yeah, like you said, Joe, he actually took the time to respond back to all of them and had answers back to all of them. So that was really impressive.

Yeah, and I don't know that I would take even nitpicks so kindly. So kudos to him. Yeah, I mean, he handled it like a champ. And I will say, he said that he had no answer for me with the, you need multiple monitors but i thought about this there's an answer the new lg um uh 30 no the 34 um 95 wides no not the not the 20 not the 20 i said ultra wides yes yes the 34 inch ultra wide oh my god i want that thing we'll leave a link in the show notes it's literally heaven in a monitor it sounds like the trailer park version of a monitor that's the ultra wide that's so wrong

the tornadoes gonna hit it my buddy john uh he just got a um a macbook air and 11 inch and he's got uh one of these ultra wide monitors and he took a picture next year i'll write him and see if i can post this picture because it's ridiculous it makes the the laptop look like a phone man uh i actually want two of them i know that's a little obscene but that's fantastic oh my god could you imagine jeez anyways but i don't know about your first world problems yeah seriously completely uh what else we got so we attended the Internet of Things SignalR meetup. That was interesting. I don't know if you're familiar with SignalR, but it's an API that allows you to do real-time communication back and forth between the client and the server.

Right, and so it uses, like, WebSockets if that's available. If not, it kind of falls back to the next best thing and so forth. Yeah, it has huge backwards compatibility support built into it as well across multiple different operating systems. And it was interesting to see the presentation and their use for it where they were using it to talk to multiple devices. Each device was a different type of, you know, like one of them was a raspberry pi one of them was uh um that the was it the galileo board i think is the name of it the

uh the adreno was another one i can't remember all of them but and then all the sensor i mean yeah the sensors were a big part of it too but it's a lot of kind of what we talked about in episode 12 um what do you want to be when you grow up? And, you know, that for me is kind of the dream of like getting back to like the real world. Yeah, I mean, it was all doing like real-time communication using SignalR in it. And they showed examples of, you know, the same code being used in, oh my God, what was it?

There was a Windows phone app. There was a Windows store app. There was a Windows store app. There was a Xamarin app for Android. iPhone, too? Yeah, there was a web app for it. It was fantastic. Yeah, he's using Teller controls, too, which I haven't really seen a lot of, but they looked really nice. You know, the interesting thing is when I've heard SignalR before, I always just associate it with real-time chat.

And it was nice because I didn't get to go to the thing with you guys, but it was nice to come back and hear that you were talking about, oh, no, no, they're doing things in, like, elevators and, you know, they're monitoring parts and what's going on. And so, like, literally you have this one data hub now that's talking to all these devices and you have dashboards and all that. So that was really cool. I wish I had gone. Speaking of really cool, the last time we went to this event we mentioned Build Guild Atlanta. I think most of the time we spent talking about

was about the french fries that we had at this venue, which I am looking very much forward to. That's coming up on the September 11th if you're in the Atlanta region. I'm sorry, September 8th. It's awesome. It's a displaced joystick. It's a bar and arcade and people talking about code all night uh count me in old school arcade yeah i'm absolutely going to try and make it to that one i may or may not be able to but um the next thing that we got are like reviews reviews oh my god you guys are awesome

this has been fantastic like we actually kind of i don't want to say flooded but we got hit with several reviews over the past month and unfortunately we hadn't gotten another episode out because we've all been insanely busy but here we are we got oh my god back to school and so we're not going to read them all this time because i mean people took the time to write some really nice reviews but like some of the headings we got from hyperspatial who can be found at twitter at hyperspatial uh s-p-a-c-i-a-l awesome podcast for developers another one icons awesome podcast michael r mind-blowing you think there's any relation to signal r possibly uhibly. Then we also, those were reviews on Stitcher, which we really appreciate those.

Those don't usually seem to grow as fast. iTunes we got from CashCHW, solid information. Another one, Jason Young from YTechie, one of a kind. So, guys, we really appreciate it. Please do leave your feedback. Any comments or anything that you have. Leave it in iTunes. Leave it in Stitcher, wherever you listen to this, just so that you can help spread the word.

It really does help keep us motivated to keep moving with these things. Really, really appreciate it. I know it takes time to do these things, and it's time that you're usually not listening to this podcast while you're sitting at your computer most times. We really do appreciate you taking the time out of your day to do that and just know that it's going to a good place too because not only are you are you helping us feel like this is worthwhile and and that we're doing something that you enjoy but it's also helping others find us as well which helps to grow the audience too oh i thought the good place was straight to my head oh yeah well you guys can't see the side of joe's head anymore but

it's pretty big yeah it it's vast yeah it's catching up to my belly now that's one of the things we all struggle as sitting in front of computers all day right uh another piece of news and this kind of hurt me a little bit it upset me a little was yahoo user interface is is basically saying they're done they're not going to support this anymore they're done doing any new development and pretty much it'll just sit out there and nothing else is going to happen it hurt you it hurt me so like you know back in the days when you didn't really have a lot of options for having nice javascript libraries yui was like one of the most advanced at the time it was kind of up there with

gwt and those and actually extjs which you may or may not know which was purchased by sentia which is probably one of the most popular api libraries for having widgets and whatnot it started from yui and there were probably several others that did as well but they basically called it quits they said things things are moving in a different way. This guy and his JavaScript. They're moving in a different direction, so that one's done. And I remember why I always had the best documentation, so there's always a place in my heart for them. Oh, they did.

They had tons of documentation. It was fantastic. Now you can use Dojo and have like 10,000 files added to your project. Yeah. Outlaw was a little upset when he found out that there were, what was it, 10 over 10,000 files good lord and just the standard dojo download so anyways yeah it's a little monstrous and then the last thing so if you guys listen to episodes 14 and 15 is that correct yeah 14 and 15 where we talked about sequel pretty much ad nauseum. After that, I went ahead and created a couple of YouTube videos that we now have a channel for.

So if you go to www.youtube.com slash coding blocks, you'll find the two videos. So if you want to learn about all the different types of sequel joins, the first two videos are up there. And we're going to start putting more of this stuff up there too. So if we're talking about like design patterns, I wouldn't be surprised if a couple of these show up there as well. Yeah, feel free to comment on those too. Yeah, go up there, subscribe if we're talking about like design patterns i wouldn't be surprised if a couple of these show up there as well so yeah feel free to comment on those too yeah go up there subscribe to the youtube channel propane hey he's up on me yeah if you guys get that then kudos

and if you don't go check out the videos and then you will no it wasn't that it was on my other site i have it on my headphone review site so yeah it's not fun anyways uh so yeah definitely go check that out and we're also going to be adding a link to the top of our codingblocks.net page so you can quickly get to our youtube channel so check that out yeah and uh alan actually said that was the last thing but uh there are two more i kind of snuck on there oh my bad i wanted to mention uh atlanta code camps coming up. I know we keep talking about regional stuff, which is very cool, but Code Camp's actually happening all over

the world. I don't really know if it's a Microsoft thing or if they're just a big sponsor of it, but it's a really cool event. I think it costs $10. It's like a full-day conference. It's Saturday. They provide lunch. It's freaking awesome. Some big-name speakers, some really awesome topics, and it's just a whole bunch of nerds hanging out.

So definitely, if you're not in the Atlanta region, then I would look for CodeCamp near you and definitely check it out. And that's the last thing for the – oh, wait. No, no, one more, and this one's a good one. So Lee Englestone, I think we referred to him last time as Linglestone, but he had a great tweet I just wanted to mention in the air because i thought it was awesome uh he basically said if no one has already coined the term terms string stringtager strule straight time and stressable then let me be the first so when i saw

this i knew exactly what he's talking about if you do any sort of like um you know jason parsing or basically just string parsing and it's like one of those things where you know this is a string but i know it's really an integer i know it's really a boolean you know you're just kind of messing around that's that sort of parsing and that's what we're talking about this is a straight a straight time column or a strule column and you got some stroll so i thought that was really funny and uh hope you guys enjoyed me saying silly words yes that was good all right so now i guess it's time to get into the meat of this thing right which is going to be our behavioral patterns so the first one we're going to talk about is the template pattern which i think outlaw was mad at

me that i took this one i was so upset yeah but we're talking about three patterns right we each kind of picked one yeah we each picked one this time so that it didn't drag on and so it didn't overload you so you can kind of soak this stuff in there's so many yeah there's a lot i mean yeah yeah so we'll be back with more episodes on these type things but so let's get into the template pattern it's also referred to as the hollywood principle and we'll talk about that in just a minute so essentially when you have a template pattern you basically have an abstract class that has some implementation doesn't have to have a ton pattern, you basically have an abstract class that has some implementation. It doesn't have to have a ton, but it basically has a main method that has the flow of things that are to be called.

And in that main method, you're going to have method calls. So the example that they have on Wikipedia, and I'll stick with that so that if you're over there looking at this, you can follow it. You have a game abstract class. And essentially they've got a method in there and inside that method that you're called to run they have initialize game call a make move call and is end of game and then print winner and so essentially what you've got now is you can subclass this abstract class and you can override any one of those methods initialize game make move is end of game print winner and then when you do that essentially what you're doing is the flow will always be exactly the same so if you have a monopoly game

then it's going to have its own initialized game that is going to set up your pieces your money and all that kind of stuff, then make move. You're going to move across a board. You might be able to buy things, right? Is end of game. Is everybody else out of money besides you? No, keep going. And then print winner if it's actually the end of the game. Now, then you might have another game, like maybe Sorry, where the initialized game is just set up pieces. But essentially, what you're doing here is, again, the flow is always exactly the same. It's just that each step can be customized by the subclass. So that's all the template pattern is.

It says, hey, just allow people when they write these other classes, we know that they're going to have to adhere to these guidelines, but then let them do whatever they want within those called methods. I love this pattern. I can give you a real world example that I've recently used for this. So an example where I've used it is for sitemaps. So if you look at the sitemap spec, there's multiple types of sitemaps that you might have in the spec itself.

But then for your own site, you might want to have sitemaps for different purposes. So maybe you have some sitemaps that are for products, some sitemaps that are for categories. You might have some sitemaps that are for, you know, just other frivolous pages for the site, but then you might have a sitemap index file, yada, yada. And in those files, there's going to be some basic structure to each of them for like header and footer type information related to the XML. But then the real meat of it, right, might be different for each one. base abstract class where it defined a pattern of okay it's now time to write the header and now it's time to write start writing the body now it's time to write the close part and there was logic built into that base as well so say like because according to the sitemap spec you can't have

there's a certain there's a cap on the number of of URLs and there's a cap on the size of the file. So it would also do checks to say like, you know, all right, it's time to, to split this off to another file, things like that. Right. But each one of these methods, um, that, that was called in this base, this, this one method that had all these calls to the virtual methods, all of those methods could be either, either you accept the default of the, of the base methods, all of those methods could be either you accept the default of the base class or you could provide your own implementation if your details were a little different, right? And so for the meet part of the sitemap, that virtual method had no implementation to it because that was one that you had to override that one.

But like the header and footer stuff, for the majority of the types are going to be the same, right? Unless you're writing, you know, the, the sitemap index versus the sitemap might be different, but, but the, you know, that one was going to be the one difference where the header might be different. You know, it might have some different, I forget exactly what it was, but yeah. So that was a great example where like you know the the specific class for writing the product specific site maps uh you only had to implement its one part for the writing the meat of the site map and the category one has is one little implementation but they were all using um as far as like the the class there are the call that actually

you know went through all of them to write it it only cared to know uh the one base type and it didn't need to know anything about any of the other ones right or that they even existed it just implement what you need yeah yeah it's it's pretty sweet i mean what it really forces you to do is to be consistent right like i mean that's really the goal of that thing is hey you know you need a header you know you need a body you know you need a footer this is going to be consistent every class that subclasses that thing is going to follow the same theme because when you call that main method build build sitemap then all those things have to exist there well i, I mean, the way I would define the beauty of it is that you can have like a defined

implementation for it. And if the caller needs to implement their single pieces of it, they can change the behavior for their specific need, but the overall structure end to end will still remain consistent. The flow is always there. I love this pattern. Yeah, that was a really cool one. I love and I hate this pattern. Really? Yeah. So I love it and i end up using it all the time and that's the problem i i end up abusing it like this this pattern is responsible for killing every little

game i tried to ever write because i'm like wait a second what if i wanted to make a different game i abstract out the make move create an interface here and then i could have two games and next you know it's like four days later and like i don't even work on this one it doesn't do anything it's just about interfaces and abstract classes and i don't care anymore so this pattern is you know it's it's like video game death for me yeah i can't say that i hate it but i will say that like i have often because we just called this the template pattern but i think more often than not though i've actually heard this one referred to as the template method pattern uh you know because because it's more

specific to well i mean you guys are not in your heads but are shaking your heads but you know i make that distinction because it's it's not um like a lot of patterns that you that you hear about are specific to a class, right? Like a singleton, for example, right? Or a factory, right? Those are talking about particular classes, whereas this one is more about a method. You're overriding methods within a method pretty much.

Well, but the pattern, though, itself is that there's a method, pretty much. Well, but the pattern, though, itself is that there's a method, and that method already has a bunch of calls to other methods, and the expectation is you will implement those other methods. Override those other methods. Yes, I'm sorry. Override those other methods. Override them if you need to. Otherwise, you'll accept whatever the default behavior is.

Okay, yeah. So template method pattern. You know, actually, when we talked about the builder pattern in the last Design Patterns episode, we mentioned this kind of maze thing where we said, you know, build door, build wall, build whatever. Really, if you're dealing with different classes and building an ice maze or a fire maze

or a magic maze or whatever it was, then you're following the same kind of template where you're filling in these methods and you can swap out these builders and things should just kind of work. Oh, yeah, and getting back to the hollywood principle on top of that the hollywood principle is don't call us we'll call you so basically all that saying is if you overrode the thing when you call that abstract classes you know run game for instance then it's going to know based off whatever the overrides were.

It's just going to call that subclasses overrided or overridden method, and that's the whole don't call us, we'll call you. So instead of basically you're saying like the method that you implement, you never actually call yourself. The call to it happens in the base class. Correct. So that abstract class, when you ran that main program, it's reaching out and calling if it

if it was overridden it automatically calls your class you're never doing it within your own stuff and that's so that's why they call it don't call us we'll call you yeah yep and uh the reason that you know i don't know if i explained it very well when i call this video game death is like how many times i've started and i'm like i'm gonna make a roguelike so i start doing that and i'm like i'm gonna make a roguelike engine and i start doing that i'm like you know really this is just a turn-based engine i could make connect four as well as a roguelike and at that point you know i'm off the d band it's over i think you like stepped into refactor hell yeah he did i that's a problem for me i want to do it i love it so much i will i could refactor all day long happily refactoring

and writing unit tests. So, independent really sucked away part of your life. So, test-driven development. It's wonderful. It's perfect. Test-driven development just like is an infinite amount of work for you because you keep refactoring. Yeah, I'll starve to death if I do TDD. Test, refactor, test, refactor, refactor, refactor, test.

Exactly. So, okay. So, I mentioned an example where I've uh used this in the in the real world but like where in the wild you know can you think of like an example where this is used in say dot net aspectacular oh i mean okay well that i'll take that sure yeah i was just thinking you know we um we talked about the methods that vlad had set up and it was like step one was like set up and i forget the actual names now step two was something that were like seven oh right yeah he had seven steps i even i even specifically called out the template method pattern during that episode yeah yeah

that's right and so we'll have a link to that episode if you guys want to check it out but yeah that's one okay so i meant something like baked into.net oh why don't you tell us? Oh, I thought, okay. Okay, you're serving it up. Yeah, the page lifecycle in web forms pretty much. ASP page. MVC has it too, yeah. So, yeah, the page lifecycle on.NET. So maybe you implement a page load. Maybe you don't.

Yep, and you can override it, and then those methods are set up there, and so you can do your page load, your on pre-error. There's a ton of them, aren't there? Yeah, data bind. There's so many of them. Yeah, so that's an example built into.NET where the template pattern is provided for you so that you can implement the pieces and have fun.

Yeah, another one is even like if you were going to create like PowerShell command list and you kind of inherit from this class and fill in. and have fun. Yeah, another one is even like, if you were going to create PowerShell command lists, then you kind of inherit from this class and fill in. Nobody does that. Oh, wait. It's awesome. I know some awesome people that wrote some awesome command lists, but it's a secret.

The world secretly runs on PowerShell. I still have never fallen in love with it. I think because it's like learning a whole new language in yet another command shell. Yeah, it's powerful. That's why it's called PowerShell. Exactly. Joe is obviously a big fan of it.

I don't know. Maybe we should just devote an entire show to let Joe talk about his love affair. We let you talk about JavaScript after all. I only get to talk about my love for JavaScript. We've never actually gone in deep on it, right? Maybe we need to. But PowerShell is pretty cool.

So is JavaScript. Ask the Node people out there. All right. Well, I feel like we've taken a tangent here. We always do. I actually do have a lot of love for JavaScript. The template pattern for our show has gone astray. It did, yes.

We actually have a template pattern and it is failing right now uh we often devolve into bashing on jobs anyway next up i want to talk about uh the strategy pattern which is actually pretty similar to the template pattern i mean these are behavioral patterns so i guess that makes sense uh wikipedia said this is also known as the policy pattern but i've never heard anyone call it the policy pattern. I call it the policy pattern all the time. Yeah, and you're not talking about security? Oh, wait. Well, maybe there's a connection there.

I don't know. But basically the deal with a strategy pattern is you encapsulate an algorithm, or really a family of algorithms that are similar, do a similar type thing into a class so that each of these classes contains just the algorithm. And then you can pass that class, and you can change those classes around and maybe call class A one time, class B another,

and it's going to run this similar algorithm. So it's just encapsulating a method. It's very single responsibility principally, but just encapsulate it into a class, and then that's about it really. There's nothing too fancy about it. Um, the, the main deal is that these classes do have to meet a common interface. So maybe they have like an execute method or something like that. And, um, I know I always bring up color mine because it's my baby, but, um, like there's a bunch of comparisons that you can do that are all very similar. So it's basically you take two colors and maybe some

additional parameters and you call compare and you're going to get some sort of number out. And it's very important that you always call the same method with the same arguments compare and you always get the same output back. Decimal in this case. And there are additional parameters that you can set when you create the class. But that method call always have to have the same signature no matter what. So that's pretty cool. And also I wanted to mention a couple examples in.NET. Now, the first one I've got written down here is not actually one that I was able to find kind of, you know, like a de facto, like, here's an example of the strategy pattern.

But it just kind of makes sense conceptually. So I wanted to mention it. But encryption, right? just kind of makes sense conceptually so i wanted to mention it but encryption right if you're doing some sort of encryption you don't really think about doing that sort of stuff like in line in a function or at least you shouldn't you would be doing something like you know creating a class here's my encryption method whether it's aes or rsa or you know pd bkf whatever it is and then you would specify your keys and whatever additional information and then at the end you're going to call something like encrypt or decrypt so you're

setting these objects up differently but at the end of the day you're just calling encrypt or decrypt and you know doing that sort of stuff does that make sense to you guys yeah i was thinking like uh you know at first for a moment there i I was thinking like, you know what, I don't know that common interface and, you know, you're letting each one define its algorithm for that. So then that made me think of an example for like payment processors, right? So you might have, you know, different, you know, depending on the third party processor where there's credit card versus like a Google Wallet or a PayPal or whatever that might be, the actual implementation to process the payments would be different for each one. But the commonality is that interface that they're using. So that's the strategy is that they're just using the – they're going to implement that interface. And so the caller only has to know about that interface.

Yeah, absolutely. And really the alternative there, if you didn't describe that too well, no, no, I know exactly what you're talking about. You know, it's something where at the end of the day, you're going to be calling payment dot, you know, capture or payment dot refund or something like that. There's a lot of setup that goes into those different things. But at the end of the day, you're following the same pattern. And one way to set this up would be to have a function called capture that's got a big switch statement that says if it's credit card and then do this if it's another credit card process to do that but you know hopefully yeah it's definitely painful so another way to do that sort of thing would be to abstract those payment

methods and so that you can just add a different class that handles you know pay with amazon or pay with whatever i guess the real point that i was trying to make here though is that like initially when when we were looking at this and like even before when we were putting the show notes together and like or even back up even before that when we had picked like what patterns are we each going to discuss for uh tonight's show and when you picked strategy pattern initially i was like you know i don't know that i've ever used that in in you know on my own but it turns out like if i really start to think about it i think this is one of those patterns where you probably do use it and you've never thought about it oh absolutely here i can blow your mind right now oh my god order by mind blown yep uh all these link expressions that take a lambda the lambda it's literally

you're passing a function that does something you're kind of encapsulating some sort of logic exactly what that is yeah yeah so you're saying order by you know x arrow x dot something you're defining this this functionality that meets an interface you know it's either that funk or the action and that almost makes like just anonymous functions almost by it it's very similar yeah yeah it's a little bit loosey-goosey because they're not actually extracted to a class but that's one of the things where this strategy pattern was kind of written about before lambdas and you know i think the payment processor window definitely seems straightforward like you know you need a you need a method to be able to capture payment You need a method to be able to capture payment.

You need a method to be able to authorize payment, things like that that would be defined in your interface. And then each class for a specific, like a Google Wallet, for example, or PayPal, they're implementing that interface. And by doing that, whether you realize it or not, they're following the strategy pattern. It's weird, though, because it sounds like just fundamental O fundamental oh like polymorphism type stuff right like yep it looks like the real so i'm looking at something on do factory.com where they have a dot net version of the strategy strategy design pattern and it seems like just basic oh type development and it seems like on top of this, if you use something like a factory with it,

it would make it extremely powerful. Yep. And really, if you're following the single responsibility principle, then you're doing this all the time because you've got this thing that it does one thing and one thing only. And if you're talking about it at that point,

you're talking about an algorithm. You're talking about strategies. The key is you're making the algorithm interchangeable. You're abstracting that away from – there's no one implementation for it, and the client doesn't have to care about that implementation. Right. So that kind of brings me to the third thing. I was kind of thinking of examples in the.NET world,

and this is getting – it's definitely straying from the definition in Wikipedia, but I thought it was interesting to bring up is dependency injection. Isn't that kind of what we're doing with dependency injection? I've got some classes that meet an interface. Well, you mean the actual tool that's doing the injection? Well, not so much the tool. And that's where the example kind of breaks down is it's not really the tool that does it, but it's the same kind of concept where I've got different

classes that meet an interface and they each, you know, have their own algorithm or algorithms. And then I configure them to use this one or that one at runtime or maybe even compile time. But it's the same kind of thing where I've got this algorithm or set of algorithms and i'm choosing to use this one over that one and so what it means is i've abstracted my algorithms out and i'm you know interchanging them so it's definitely a loose definition but i just thought it's kind of a an interesting take on this strategy pattern yeah i mean the one thing that's weird about the the like if you only looked at the definition of this one, though, you know, it says, like, it defines a family of algorithms, right? Right. And then, but then you think, like, well, are you calling defining the algorithm just the method name?

Because. Well, here's an example we talked about a little bit before the show is log for net. So I might have a file appender that appends to the end of the file. I might have a rolling file appender that knows how to roll the files, or I might have a database appender that appends to database. And each one of these is configured,

basically, you know, in your web or app config file. It's kind of doing a sort of dependency injection. But at the same time, you're really, these classes that are underlying are meeting this sort of interface. They make up a family of algorithms that all do something very similar, and at the end of the day, they just kind of call log.write, and the stuff happens underneath because they meet the same interface.

So I would say that's a pretty good example of the strategy pattern. Yeah. So let me say this if we haven't already said it. Please leave us for a view on itunes or stitcher or you know stitcher is awesome we're getting some really good traction there but you know i'll tell you what wherever you feel the most comfortable leaving us that review you can go to one of you to uh alan's videos on youtube and leave it there i you know whatever just i really appreciate it yeah and i know that you guys uh

a lot of you aren't writing reviews because we've gotten too many good ones so i know that we're getting some sort of we still want to keep the good ones rolling in i don't know where you're going with this joe but i don't like it you know the good ones are good but you can also email us at comments at coding blocks.net if you want to send us something a little bit more harsh. Yeah, so take this note down, okay? Put the good ones up on iTunes and Stitcher and any kind of rants, email those to us. And we'll fix it, maybe. We'll at least read it. Well, we'll probably blame Alan first.

Right, fair. But, I mean, some of the other ones that we got, too, that we didn't mention earlier, from Chris Tessin, I'm not certain. Hopefully other ones that we got, too, that we didn't mention earlier from Chris Tassin. I'm not certain. Hopefully, I didn't butcher that too bad. Great podcast and very entertaining. I would say Tassin. Tassin.

That's my guess. Yeah, that's what I thought initially. Speedy surfer, great way to learn and drive. That's what our goal was, right? And he's speedy. So, I mean, you got to take that. Yeah, absolutely. He's driving while he's doing this and he's speedy so i mean you gotta take that yeah absolutely he's driving while he's doing this and he's speedy uh decepted or decked is uh amazing work guys and 603 smart and enjoyable so

i mean that's what we're going for anyways is like we said we wanted you guys to be able to learn on the fly while you're driving cutting your grass whatever so yeah please do leave us a review and leave us some feedback we We'd really appreciate it. And also, share this with your friends or coworkers. I mean, if you've got people that you want to improve their code. And like we said, this does help other people to find us as well, so we greatly appreciate that. So thank you for everyone who has already sent us a review on iTunes and Stitcher. Just know that we really do appreciate it.

Thank you. Seriously. So the next pattern. I love this one. This is, this is, I don't know if you guys like this one as much as I do, but I do.

This is an elegant one. The null object pattern. Oh, that little guy. So here was this interesting quote that I found and And it said, I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe with checking performed automatically by the compiler.

But I couldn't resist the temptation to put in a null reference. Simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which has probably caused a billion dollars of pain and damage in the last 40 years wow it's a little hard on himself huh that's sir charles anthony richard horror yeah he's a principal researcher at microsoft uh inventor of quicksort numerous awards you can go check him out on wikipedia and we will have a link to him in the show notes as well but uh you know when we talk about the null object pattern i think it's only fair that we pay well but uh you know when we talk about the null object pattern

i think it's only fair that we pay homage to uh you know the null reference guy yeah and he also invented quicksort by the way so kind of a big deal yeah cut him some slack cut him some slack i mean you know he did invent null all right so so null object pattern. So what is this first, right? This is if you want to provide a safe implementation that does nothing, this is what you do, all right? So when to use this is when you want to abstract null away from the client. You don't want your callers to have to bother with checking for null. You just want to allow them the freedom and flexibility to know that they can call your method, whatever that might be, and they're going to get back something and it'll always be safe.

And they can just call methods on it and it'll work without a problem. All right. Something useful. So I get an object back and i just say object dot whatever and if it's a null object then it just kind of no ops it does nothing right nothing harmful happens my system doesn't crash because i didn't check for null right so so an example of it a very uh i might even call this say that this is kind of a loose, uh, um, example of it, but let's say that if you had a method and that method was supposed to return a list, okay. But based on some condition, maybe you don't return a list of anything, right. But at least you return back an empty list. And then that way the caller could just automatically throw that into

a for each loop, for example, and start trying to iterate on it. But because your method didn't return anything, nothing happened. Yeah, no harm, no foul. Exactly. You're not having to say, hey, if this is null, if this is not null, then do the for each. If it is null, skip it. None of that garbage. That's basically what you're avoiding.

Yeah. So some places where I've used this myself is in factory classes, right's met i need to i don't want to return back null but i want to return back a safe object that they can use right so i will return back a null object pattern version of it okay so trying to wrap my head around this i'm starting to think like you guys are just like never mind mind, forget it, go on. You're like lost in null while I'm talking about null. My love of null here has gone straight to dev null. You threw so many nulls in there. Dang.

We actually tried really hard to find an example of this in the.NET framework, and I can't think of any. We had a hard time searching for any but it's still uh you know i'm sure it's something that's out there in frameworks i know i've certainly done stuff like it but one thing that's kind of weird about it is that it almost like leads you to feel safe and maybe you shouldn't you know like if you're kind of trusting this method to return you an object that does nothing rather than null then you know do you think it kind of tricks you into not checking for null on other calls and that same method? You're getting ahead. Oh, sorry.

Okay. Well, uh, dang. So I didn't want to get into that yet. Okay, fine. So we will. So, so I was going to close on like a question of the day, right? So name the pattern that i really like that often goes hand in hand with the null object pattern the singleton oh no yeah my boy singleton you sprung that on me he's back live large raise a roof that's if you like pathological liars. What? No, this is a great use for the singleton pattern, right? All right, so the bonus question. Why?

Why would the singleton go hand in hand? Not all the time, but often. Well, I don't have to worry about it being initialized or ever not exist. I just kind of call it well i don't have to worry about being initialized or ever not exist i just kind of call it i don't have to think about it no you got you got any ideas there alan okay okay so so there's two reasons why often the null pattern is in conjunction with the singleton pattern. And that is because there's not really going to be any state. If you had two versions of the null object, they're going to be identical, right?

So if they're both identical, why waste memory to have the same nothingness repeated, right? So let me give you an example. We talked about payment processors a minute ago for, like, Google Wallet and PayPal, right? So you have a Google Wallet processor. You have a payment processor. They both implement capture methods and auth methods. But let's say, I don't know why, but you have a null payment processor and you know it it's reserved you're reserving some space to to uh have these empty methods that aren't doing anything but why

would you need to do that twice you wouldn't you wouldn't want to instantiate that right right so so because there's no state to the null object there's no need to repeat it now number two reason is for equality checks right if i return back null if i return back the null object version back to you and you want to check as you jumped ahead to to see hey is this the quote null right then you need to be able to have something to compare it to and it needs to be the same thing in order for it to pass the reference equality check. Because if you had two instances of the same object those wouldn't pass because they would technically be pointing to different memory blocks.

Presumably I might want to know if I got the null object or the null object. Right. Right. So so that's why I say like it doesn't you don't have to necessarily implement the singleton pattern when you do the null object, because maybe maybe the state or the equality checks aren't something that you need at that time but you know well for what you talked about yeah that makes sense if you're doing something like you're talking about where you call i don't know let's say that you have a method says you know get your customers out of the database like a null object pattern might be you pass it in bad garbage uh for doing the search and so it just returns you an empty list of customers right so then you wouldn't want to use something like a single time because you actually are getting new objects back but you could return a null or an empty list right so so the idea here

is that you're just doing it for safety now here's the benefits though this is why like the null object pattern is so awesome right because it cleans up your code man you're getting rid of all these null checks you don't care no no if else required right you don't you don't have to say like if this is null do this let's do that you don't you don't care you just know you got back something you can safely call something on it but like i said if you did want to check to see if this is the um uh specifically the null object. You still have that option, but you don't have to. So that's the beauty of it.

Okay. So I was trying to think of an example, kind of in my own mind, what this might look like. And I was thinking if you wanted to say you've got some sort of URL parameter that says delete user 14. So what I might do is maybe say get user 14 then user dot delete and in this case if there was no user 14 because maybe i refreshed the page i already deleted them i

would get a crash but if i use the null object pattern then i would kind of get this null object back when i said give me user 14 it gives me an empty object i say object dot delete and it just kind of does nothing but i didn't have to do this extra checking or worry about this stuff and it was just kind of handled by doing nothing in the null object. It almost, yeah, it's almost like, because we've talked about my hatred for this one method in link

which is like the first versus first or default. And I wonder like, I don't know, I've got to go back to remembering the first or default how that works, because maybe that would be the safe version. It returns the default value for... Because null would return back,

the first would return back null. Yeah, so all reference types would turn null, but like an integer would return zero. Right, but yeah, for the first or default, you're saying. So, yeah, maybe that is an example of the null object pattern within the.NET framework. That's what it seems like. Well, it would actually return null, though, so that is an example of the null object pattern within the.NET framework. That's what it seems like.

Well, it would actually return null, though. So I would think not. Yeah, yeah, you are right there. It's for reference types. Depending on what the type is supposed to be. All right. Well, so our search for the null object pattern inside of the.NET framework continues. But here's another beauty of why this pattern is so, its simplicity is its beauty.

Okay. Because you have, because your need for doing these if conditions is lowered, right? You lower the complexity of your code, right? Absolutely. Remember our conversation about independ? Yeah. All right. Your cyclomatic complexity score just drops yep right that's awesome right i love

this guy you don't care what was returned you just get to do stuff you get to live up to nike's motto and just do it so if you imagine a world without no references like if no references were allowed we'd be writing a whole lot more objects first of of all. But that's interesting what the code will look like. I guess you would probably end up doing a lot of checking to see if it equaled the null object and then throwing an error or something like that. The downside to this is you are creating objects for the sake of having objects. So basically things that really do nothing. So you're taking a peep space.

But it's probably, I mean, there's always tradeoffs, right? Well, it depends. Like in my Singleton example, though, you are limiting that. You're taking up heap space, but it's probably, I mean, there's always trade-offs, right? Well, it depends. Like in my Singleton example, though, you are limiting that. You're limiting it. But the beauty of it is, like I said in the beginning, you're abstracting null away from your caller. Your caller doesn't have to be aware of it. And that trade-off, I think, is a fair one. I mean, you always have the performance versus whatever, but there's a lot to be said for clean code, right?

Like being able to go in and read something and not get exceptions that you're worried about and all that i mean let's not even think about this in the scenario that you're actually writing a class to represent the null you know the quote null object that maybe a factory would return because that that's certainly an example of this pattern but let's just say in the example that i gave in the beginning where you know you have some method it needs to return back a list of some type right right instead of returning back null you return back and just an empty list which is still taking up some space on the heap but yeah but not much it's much safer right safer any time that you cannot return back a null yep you make it you make your methods much safer for your callers

right absolutely yeah it's i i actually like this pattern a lot and it's something that i think i did long before i even knew it was a pattern right i think probably a lot of us have because you're like man i'm so tired of checking them for null right so this is a very very useful pattern yeah i love that guy null pattern null object pattern in singleton they're like you know peanut butter and chocolate and they go together so well so it does seem like it uh it fits really nicely with the strategy pattern oh yeah even the template pattern you know if you're doing your ice maze and you know one of the things like you know maybe create fire or some sort of method on there, it just wouldn't happen in the ice maze. Well, you know, that's really at the method level.

So I guess I'm getting a little wrong there, but still kind of wrapping my head around this one. Yeah. I mean, it's also, you know, you use this too when you're implementing the command pattern, which is another behavioral pattern that we haven't gotten into yet, which we'll get to in the future, but that's when command objects did encapsulate an action and its parameters. And then

you could also you mentioned the strategy pattern, you could also consider this to be a special case of the strategy pattern or even the command pattern. I was just thinking an example of this might like if you've ever been programming something and like you didn't configure it correctly and rather than an exception being thrown just nothing kind of happened you know the whatever you expected to see on the screen didn't show up because

it you know it kind of got no opt and that's what it says situations where it can be you know kind of frustrating and you're like what the heck just happened? There's nothing logged because there's no error. But, you know, it's also good for something that you want to be highly available or whatever. It's almost like interesting for default behaviors. Yeah. It's also sometimes considered a special case for the state pattern, which is another in the long list of behavioral patterns. Oh, so it would be like my blank state?

Yeah, it's a clean way for an object to partially change its type at runtime. So we've already given some hints into some future behavioral patterns that we'll get into. But, yeah, if you haven't already tried the null object pattern, I suggest you try it and fall in love with it because it is awesome and then any hatred that you might have had for singleton you're gonna be like you know what michael was right singleton singleton ain't so bad after all it ain't so good either. What? Crazy. Let's see what Google thinks.

Singletons. Oh, God. Here we go again. It's going to be anti-pattern, right? Are bad, pathological liars, evil, closed, and open. Poor Singleton. Oh, Google. Poor, poor Singleton. It is.

All right. So let's get on to the resources we like. What do we got over there? Yeah. So, I mean, we've mentioned some of these before, but I felt that it was a good one to bring back up is the Design Patterns Library on Pluralsight. Oh, my God, there must be, like, what, 15, 20, 25, 30?

There's a lot. I think, like, everyone who ever wrote any code for Pluralsight is in that library. It is a massive set of videos that you can watch and learn and there's really a lot of great content in it. So I highly recommend it. We'll include a link to that in the show notes as well. Yep. And also of course the design patterns book, which actually doesn't have null object. That's kind of a newer one, but this book is awesome and i think we mentioned last time it's still in its first edition because that's just how right it was yeah that's that's still unbelievable outstanding as i mentioned

that it has two bookmarks built into the book yeah you really need like 80 000 bookmarks for it my cats have chewed these bookmarks a little bit. They're holding the book right now. Don't even bother with a highlighter for that book because the entire book will be yellow. Yeah, seriously. All right. And so then now on to our tips of the week. Joe, what's yours? All right.

Mine is the MS Dev Show. The Swedish coder, who I think is put her handle, it's Patrick Dolan. We've mentioned him before. Oh, yeah, several times. He's at Swedish Coder. He turned me on to the MS Dev Show, which is really fantastic. It's one guy who works at Microsoft and another MVP, and they just do these really great interviews, and they always have tons of tips.

I feel like I'm always scrambling for a pen or going to the website to look up something. It's really great content. It's really good, and the topics are really good. It's not the kind of standard podcasty interviews you hear like they just did one with um the guy who's kind of running the azure search team and they just talked about some it was like just a right mix of like details and kind of high level to just make it really interesting so the name almost sounds misleading though because like it's called the ms dev show so immediately you would

think like oh well you know i'm not a uh I do Java, so why would I even bother? But one of the last episodes that I listened to, it was just on how Agile was used inside of Microsoft. That was a really good one. That was fantastic. It was an excellent episode. It was not in any way specific to any Microsoft technology, but it was great. I mean, they talked about how Microsoft was using it to make microsoft technologies but and i gotta say on top of it another thing and we we are all avid podcast listeners the sound quality is fantastic so it

never distracts from the from the the content of the show so kudos to them on that and the content is really outstanding it doesn't hurt that you can hear. Yeah. If you listen to it, I know you do podcasts at two times speed, and I do 1.5. So the sound quality is bad. It just sounds like a modem. Ain't nobody got time for that. Dude, I don't even know how you do two.

That's insane. Man, you got to listen to everything at double speed. Ain't nobody got time for that. So, yeah. What was your tip, totally? Just MSDevShow show you can find them by going to itunes or stitcher or um on twitter they're just ms dev show wait i thought you had oh no yeah i got the mother of all oh that was you my bad my bad yeah bring it outlaws got like

five pages for his tip here all right so uh put me on double speed here it comes nah you'll want to listen to this on single speed who we kidding all right so this is an entity framework one and and maybe you've already ran into this but um if you haven't then you'll appreciate this so uh here's the scenario you want to return an iquirable for some table right But that table has four key relationships, right? So what you don't want to have to do is loop through the results of that I queryable, right? And perform, you know, in number of queries to, for each of those four key references, right? So, um, you know, the example that I wrote here was let's consider that you have a product table, and for each product you might have multiple SKUs for it. So let's picture the product is some shirt design, and you have SKUs that represent blue, red, white color versions of that shirt, as well as small, medium, large versions of that shirt, as well as small, medium, large, um, you know, versions of that shirt.

And you want to go through, you want to query that product table, but you need to be able to access those product SKUs as well. Right? So here's how you can do that in your I queryable. There is a dot include method that you can use. And in that method, you can specify what key you want to include in that. So now depending on that query, your payload might be rather large. So be aware, right? But, you know, if you can take the hit for that large result set, that might be way better trade off than doing in number of queries, you know, at least a minimum of in number of queries, or getting back in number of results for in number of queries. You know, so so that depends on on, you know, what your need is. But then, let's say you're like, well, I need multiple.

There's multiple foreign keys, and I want them to all come back. You can chain these dot includes together. So you could get dot include, and then in the product example, let's say that I was going to set up a lambda and just call it P. So P goes to P dot the first foreign key table, and then dot include P goes to p dot second foreign key table right and this is going to use eager loading so you are going to take the hit on on that but again you now have one result set that came back and your foreign keys are there as well so this is

similar if we're talking about link to sql which we are, this is similar to doing like a select all from table one, join table two, join table three. But you're not having to go back to your crazy join syntax. You're doing this in entity. But it's the equivalent. So if you're talking about... This is in entity. Yes, if you're talking about SQL. That's basically what it's generating behind the scenes.

When you use that dot include, it's basically a select all. I still can't get join syntax. Even in the SQL query syntax, I had to look it up every time. So this is something I can actually remember. Yeah, because like, okay, so I guess one thing that I didn't mention that if you weren't aware of is that if you did your select from the product table, right, and then you tried to do anything on that foreign key reference. So you got back your first product result and you did product dot and you called that second, um, you

called that, that foreign key table. So in an example of the SKU, so you did product dot SKU dot that's going to, in the background that would normally kick off a query if it hadn't already, uh, if it didn't already have that data, right? So it would kick off a query normally. So if you did a query that returned back 10 products, and for each of those 10 products you did product.skew, that's going to be the one query to get all the products and then 10 more queries to get all those SKUs. And maybe those SKUs only return back one record.

They might return back more than one record they might return back you know um more than one record but you know the point is is that you know in this scenario you had to um the point is is that this would return back everything at one time for you in one query call yeah so you're not just constantly going back and forth to your database or whatever your data provider is. And it looks nice in the Lambda syntax. Yeah, it is pretty. All right, so my tip of the week. So if you've ever had a need where you had a table,

and let's say you needed to populate a temporary table or something, and let's say that this table you've got has 50 columns in it and you're like god i really don't want to create this temporary table and define the columns with the var cars and the ints and all that a real quick way of just creating a shell of a table in sql server would be do a select star into and if it's attempt w say pound new table name from the source table name where one equals zero so the beauty behind this is a select into creates a new table when you say where one equals zero that's that doesn't say i don't want i don't want anything to happen it says i still want you to create this table but i don't want anything to happen. It says, I still want you to create this table, but I don't want any rows in it. So this is how you can literally go about creating a shell of a table. Select star into new table from old table where one equals zero.

And you get a shell of a table that you can populate with whatever you want. That's one shell of a table. Nice. That reminds me, Sequel Chris, who we've mentioned on the show before but um he does a lot of uh like kind of sequel tips and and uh questions and all sorts of cool stuff but he recently put out a survey we'll have a link um so if you have any sort of sequel questions or stuff you'd like to see out of him then he's got that link but uh what actually got me thinking about it is um and i took the survey and one of the things he asked is um you know what do you have a hard time with in sql i was like

importing and exporting data i know i shouldn't you know it seems like something that should be really easy for a database but every time it comes to like import data from you know an excel spreadsheet or you want to move some data or some tables from one database to the other and you got to make sure to check the schema only or data and schema, and oh my gosh, you forgot the foreign keys. It's such a pain. You can do the whole backup and restore thing, but even that gets kind of nasty.

Restore doesn't work half the time for some reason. You've got to stop the database and do weird stuff. I don't know. Moving data around is not my forte. I can query once it's there, but getting the data into the right database is kind of a pain. So that's a cool tip there, Alan. Cool.

Glad I helped somebody. All right. So just in the summer, we talked about the template method pattern, the strategy pattern, the null logic pattern. And the singleton pattern. Oh, my God. I love that guy. So be sure to subscribe to us on iTunes, Stitcher, uh, and more using your favorite podcast app and,

make sure to give us that review. Um, we love it and we appreciate what you guys have been doing and, we'll certainly take more. Yep. And visit us at coding blocks.net where you can find our show notes, examples, discussions,

and more and seed your feedback, questions, and rants to comments at coding blocks.net. Why are you pointing at me? I figured we all went out of order except for you, so I figured you were trying to save my line. Oh, you mean be sure to follow us on Twitter at Coding Blocks? Wait, no, wait.

Yeah, that one. Contact us with a question or a topic leave your name and preferred method shout out website twitter etc and we'll mention you in a podcast and review i feel like a robot reading this stuff that's really good i guess that means we're about done yep all right so we'll be back soon denim denim denim denim see it's stuck in your head now that's awesome