Coding Blocks - Design Patterns – Iterators, Observers, and Chains, Oh My

Episode Date: November 9, 2014

We’re back to the gang of four, continuing with another segment of design patterns. This time we’re talking about some of our favorite Behavioral Design Patterns: Observer, Chain of Responsibilities, Iterator patterns. Also, why the visitor pattern is weird and what it’s like to be raked over hot coals. News Atlanta Code Camp was amazing […]

Yo, yo, yo, we here for the coding stuff. Yeah, I don't even, I can't, I can't do that. You're listening to Coding Blocks, episode 19. 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. And send your feedback, questions, and rants to comments at codingblocks.net and follow us on Twitter at Coding Blocks or head over to www.codingblocks.net and find our other social links at the top of the page. And with that, welcome to Coding Blocks. I'm Alan Underwood.

I'm Joe Zach. Yes, you are. And I'm Michael Outlaw. And today we're going to be talking about design patterns again. So I think this is what, the third or fourth maybe episode that we've done? Third. Third, okay. Getting a little tied up there.

It's the third of like a hundred. Right, and there's a lot. I think we mentioned the number. I think it's like at least 20-something in the actual book and then a bunch more after the fact. I feel like there's 20-something just behavioral patterns. Yeah, there's a lot, which is what we're getting into today. Yep. So this is our third installment.

But first, we wanted to bring you a little bit of news first. Number one, Alan and I made it out to Atlanta Code Camp, which was phenomenal. And it was $10, which was fantastic for an all-day conference. God, that's a lot for the conference. Well, I mean, that just paid for my lunch. So I got a shirt. I got some other stuff. I didn't win a conference. God, it's a lot for the conferences. Well, I mean, that just paid for my lunch. So I got a shirt. I got some other stuff. I didn't win a prize.

Yeah, I didn't either. And I tried. And there were a lot of prizes. Like one in ten people walked away with a prize. What were the prizes? Were there some really awesome stuff? There was. Netduinos, Xboxes, monitors.

An Xbox. They gave away a ton of Leap Motions. An all-in-one printer. I wanted the printer, man. I actually did want the printer. That was the joke. People were like, what's that do? Wait, was there a Surface given away?

I know there were a couple of tablets. Well, based on our last discussion about gaming, I'm surprised that the discussion wasn't like, what does that Xbox do? Right. Oh, dude. It was ridiculous. But also, I mean, the day was killer, right?

Like, I mean, it was from but also i mean the day was killer right like i mean it was from eight to five the problem was dude i was worn out by the end of the day yep just completely mentally a full day of learning and you're like i'm done well you know like like we talked about this for a second but in college you know you had those buffer classes like history and stuff that didn't really matter and so so you had those breaks. I'm not saying I take bowling. You know, but man, this was like all day hardcore stuff. I mean, we did some Angular courses. We did, we did, God, what were some of the other React?

There's a lot of Angular. There's a lot of cloud type stuff. React to Ascension was awesome, Jeff Woolley. There's that VNext presentation that we happened to see at a user group, but it was done again at the conference, which was probably awesome. I had already seen it. Man, there was really

just a ton of good information. I was really surprised at how popular the Angular sessions were. I actually volunteered, so I would kind of walk around a little bit sometimes, and I would see the people lining up at the doors for the next Angular talk. You were surprised that angular was a big deal no but i mean it's kind of a thing i don't know you maybe heard about it look man i was actually surprised because the angular stuff

was held in one of the bigger rooms like it was a huge auditorium they were standing room only it held at least what a couple hundred people yep like i would venture to say i think they said that at the peak that day there were like 600 people there something along those lines i wouldn't be surprised if 250 people were in that one room at that one point in time like it was a hugely popular topic as a matter of fact one of the other talks was on ionic which is really cool uh but that's basically Angular for mobile cross-platform development. That wasn't as popular because I don't think anybody had heard about it. But it was basically Angular for that.

So a lot of great topics. A lot of great topics. Met some cool people. So tell me, since I wasn't able to be there and many of our listeners might not have been there too, give me a good takeaway from it. Some little gem of knowledge. You're like, oh my God. I think it's a good time to be a developer is my big thing.

There's a lot of stuff happening on UI and the web right now. There's a lot of stuff with SignalR and Cloud and VNexo. It's just a lot of cool stuff coming down the pipe. I didn't see anything on Roslyn. It does tend to be kind of a heavy on the Microsoft side conference, which is probably why I was surprised to see so much Angular. but there was a lot kind of coming down in my ecosystem. So it was exciting about to see that. I think my takeaway was how hot web technologies really are. I mean, a lot of this revolved around, you know, Angular, Ionic, like I said, there were other frameworks.

But a lot of it was basically, you know, where do you see the industry shifting type to type? There was a lot of that. See, I'm really surprised by your answer because I was thinking that this might be a great segue because, you know, if any of our listeners are, you know, follow any of the blog posts that we have on the site which if you're not already you know give it a look uh and and maybe furthermore you see some of the posts that we would throw out on reddit and if you did happen to catch it there was a period of time just recently where alan unfortunately got destroyed on reddit or at least it felt that way man that was all right all right so are you are the bruises a little strong it destroys a little strong so i might have gotten

some strong comments on reddit like i mean if anybody's ever posted anything on reddit as a programmer you'll find out real quick that there there are some useful things that are posted and some not so useful and you have to just try and keep an even head about it. But, yeah, I definitely wrote an article that was talking about JavaScript where you use the double exclamation mark. Bang, bang. Man, yeah, and I called it Bang Bang JavaScript. We'll leave a link in the show notes.

But I totally screwed up and did a double equal in one of my performance tests instead of a triple equal, so it was actually doing a cast on it and dude i got run through the coals on that one which which is fine and actually i do appreciate i want to point out a guy named travis watson who came over and and commented on the post and actually commented over on reddit as well but extremely helpful uh feedback and i actually did go back in and tweak the the article and fix some of the things um so so here's the thing where i felt bad though about this whole thing you know because you know honestly i felt bad just reading some of the not all of them right but it there were

one in particular they just went like over the top on reddit where it was like well that was a bit unnecessary um but you know just seeing like the the general thread of of how some of the conversation was going on the reddit thread and it made me think like man this only happened because of one small typo yeah and it like really like let's take it out of the context of this article right like how many times does that happen like one one typo led you down this wrong path in your coding career right this was the that exact same thing only now it was taken out taken out of the context of the pro of a programming but now it's in an article yeah it's it's kind of interesting It's also humbling as a programmer because it makes you realize that everything you put out there, like if too many people insight from it, right? Throw away the temper. You got a lot of insight.

Well, see, that's the thing. A lot of it was actually people saying, well, you know, they would give reasons why they didn't think that worked or whatever. And that's actually good, right? Then there's the 10% to 15% of them that are just basically – it's the reddit trolls right uh i mean we said we were going to include a a link to this in the channels but do you want to give like a quick overview of what you were trying to get at with the bang bang okay so yeah bang bang was brought up actually during the angular speak when we had gone to atlanta code camp and the guy was basically saying hey this is a quick way to do uh a truthy type evaluation of a variable in javascript well as I got sitting down and thinking about it,

I was like, well, why would you ever use this, right? And so I started going through, like I basically created a map of different types of variables in JavaScript and did two types of comparisons. Did the if and then that variable just on its own to evaluate it as truthy, and then I did an if not not it uh if bang bang and then the

variable to do the basically all it does is cast it to a of an inverse boolean and then and then inverts it back to the truthy version of itself right so a true boolean representation of it well what i found is right like really i when i did my performance test what i screwed up is when i did the comparison i did a double equal instead of a triple equal right he had one one compare one performance test that did the triple equal and then a second performance test that did a double equal and that threw off the stats which then it led to the wrong conclusion which was right hey the bang bang might be faster well bang-bang, the only time that you would ever really want to use it is if you were trying to get back a true Boolean from something.

So, like, if you had a method that said, you know, is string, or is string true, something like that, whatever, then you might do a bang-bang on a variable. But otherwise, you can just... I thought it was if you wanted to get that object represented as a variable... As a Boolean. I'm sorry, as a Boolean into another variable. You didn't want to use it for an if condition. You want the value to be stored in a variable.

If you want to use it as a boolean later you might but like what i'm saying is so i want to have some variable called it is truthy and then i would say is truthy equal bang bang some bar you could do something and that that was that was the reason where you might want to to use the bang bang is the first bang would convert it into the boolean the negated Boolean. Yeah, that would then knot it. Right. And so then the second knot would undo that.

The only time it really matters is if you need that Boolean to do something later on. Otherwise, just do if and then the variable, and you get the truthy representation, and it'll fall through. But it's just one of those things where as programmers i mean heck there was what the uh i don't even remember what the uh uh what the problem was but there was something was that the ssl where they had an if without uh without the brackets or whatever oh no you're talking about the apple fell yeah yeah and so so it's one of those type situations we don't know if that was on purpose or not but but i'm pretty sure that was the nsa so as programmers though like you just have to be super aware of type things that you do because if you draw the wrong conclusion based off a mistake that you had in your code

how many people are going to read that right so so what do you think the lessons learned were well i think the lesson is that it's good to kind of put yourself out there and throw things out because 90 of the comments that was the bad because 90% of the comments were actually very positive. There was a lot of really good feedback about it. And also, if Alan hadn't posted this and people kind of hopped on it, he may not have known that there was a mistake and gone on the rest of his life thinking that this is something good to do. So it's nice to kind of collaborate and come away with that. And it's unfortunate that I found with

at least the bigger communities on Reddit, it's like the more people there are, the greater chance of something nasty happening. So that's why you should stick to C Sharp. Right, right. Well, I was actually curious if you thought that maybe if any unit testing would have caught that.

I don't think unit testing would have helped here i do um what i really got away from this though is that in javascript you have to do weird made up operators just to get a freaking boolean oh yeah i'll have to find that in the resources at any rate but yeah it was it was definitely a good slash bad experience nobody likes to put out code that wasn't perfect the first time but again as part of part of doing this, like, you know, a lot of people don't put themselves out there. And I will say it's a nice, it's a nice way. Now, granted, you have to keep a level head because you will get attacked, period. There's no question about it. You will eventually get

attacked. But if you can take away something from it, like, oh, crap, I should have paid attention to that or whatever, then it can actually be a positive experience overall. So it was interesting, a little bit frustrating, but, you know, hey, life goes on. Yeah, but your comment about, like, the JavaScript having to have this weird, which this isn't specifically an operator. This is just, you know, the same operator you use twice. Like, if you wanted to do this same,

similar type of operation in C Sharp, right? I would cast a bull. And it's very... You can tell by looking at the line exactly what I intended to do. Bull.parse. Yeah, and then it throws an exception because it can't be casted as that type.

Because there's none of this truthy stuff. This whole truthy word is just made up for javascript weirdness well that's the whole weird is like the fact that you you know every every other language you would use the double equal except in javascript yeah it's whatever you want to use the triple equal and don't even get me started on iffies and all the other weird ways of creating private variable scope in javascript we'll talk about that later yeah uh so on other news uh i also so i went to code academy i don't know why i think just because i'd heard about it and thought

it was cool ended up finishing the ruby training on it which was kind of cool if you haven't missed a ruby it's an interesting language got you some gems i did get me some gems i got a lot of gems as a matter of fact so uh definitely a cool experience and we get asked a lot of times about hey you know what are good learning resources for people trying to get started we just talked about uh uh plural site versus lynda.com yeah and in code academy look guys go check it out like i was more doing it just because i was somewhat interested in how they had implemented this and they did a nice job I won't say it's 100% perfect, but if you're somebody trying to learn something from scratch

and you don't have a lot of real-world experience with any of this, they do a nice job of walking you through step-by-step and giving you good examples. So I would definitely go check out Codecademy. We'll have that up on the show notes as well. Would you alter your stance from the last episode then? What was my stance from the last episode? Pluralsight versus lynda.com?

I believe you'd said that lynda.com was more for software how-tos and Pluralsight was more developer heavy. If I remember right. It was. I got to do with Codecademy. I'm curious now if you would say like, here's another code-heavy one,

and I would recommend this one over that. Oh, well, this is a free one. This is more like learn-as-you-go. So they literally give you examples, you type it in. I would say for anybody just trying to learn something, and not deep dives, right? So this isn't deep dives. This is kind of getting intro-type stuff

into different languages. Like, they had some for JavaScript. They had some for creating websites. They had things for Ruby, PHP. So if you're trying to get involved without actually having to go through courses or classes or anything, Codecademy was actually an excellent resource.

I would put it up there with the other two as must-have for your tool belt for what they have available. So I want to say some thank yous here. We got a new review on iTunes. Now, again, some people, their parents give them the most strange, most bizarre names. So maybe this one is like one of those nicknames where this guy is like really tiny.

So his name is Giant607. And he is very verbose in his write-up here. So he says, well done, sirs. Thank you very much. Yes, very much. That was awesome. We greatly appreciate it. I'm giving you a fist bump over the air right now.

And honestly, we were as excited about that short one as we are all of them. So, yeah. We also got another one on Stitcher, which came from N.J. Graham. Yeah, this guy, he wrote a little bit extra, and it was awesome. So, this is what he wrote. I just started listening to this podcast a few days ago, having started with the design pattern series. These guys are great. Lots of topics and discussions that can help boost the knowledge base of newbies and probably some old time programmers as well. These fellows are very endearing and that they each sound like an

average dude who just has a lot of good information on coding. Definitely more reliable than some other podcasts I've listened to keep it up guys so seriously very much appreciate that i mean that's that's kind of what we try to do right like we try to be i don't know endearing but you know somewhat funny and somewhat informative but but the point is is that we want you guys to know how much we appreciate that you guys took the time to a uh click on the five stars and and leave us that rating and then b took the time to write it up write up a statement or two about you know how you feel about so we greatly appreciate it and uh you know hope hope that more come along yeah and additionally also uh those that have gone

up to our contact form or just email us at comments at coding blocks definitely send in any questions or ideas or anything like i mean we really enjoy getting those because it you know it helps us move on with it so yeah we're gonna have to have like a jira ticket just to keep track of all the backlog of of ideas that are popping in here and uh we can filter these to the top of the queue works for me for me. All right, so let's get into the meat of this thing. So today, again, we're talking about behavioral design patterns. And initially, I was going to do the visitor pattern. Yeah, that got scratched. I don't even know how to describe that thing.

And there were other sites that I think Outlaw found that they're like, yeah, this is one of the most complicated design patterns that exist. I've never seen it used anywhere. Well, I do want to do the Visitor Pattern justice, but it didn't feel like – it felt like it would be better served if we held off on that one. So that's why – Maybe we could do a video. Maybe that would help with some of the diagrams and stuff. We were having a hard time just talking about it ourselves all having read the same information.

Yeah, because there's so many – there's a lot of moving parts required to the visitor pattern so yeah it's not one that you could just easily talk about you know verbally without having something to visually reference so yeah we'll have to come up with some way to to do that one but so instead of visitor pattern we opted for the observer pattern yep so basically this is actually a fairly simple one so it maintains its dependence and notifies them of events by calling a method on a dependent so in a nutshell really what you do is you have these these events that can happen and you add these add other objects as subscribers to that event. So once you do that, basically any time an event fires off,

then it knows how to go and notify those listening objects. And so it's really a simple model. There's a ton of examples out there which we'll go into soon. But one of the downsides to this that was kind of interesting when we were looking at it was when you do this, it can actually cause memory leaks. Because the class that is adding these response handlers to this event, it's got a strong hold on those objects. So if it never releases those and never garbage collects them or disposes of them properly, then basically you have all these objects kind of staying alive and they never get they never get thrown away well i think the way we should wear that though is that like not that it can cause them but it's just like one of the risks that you have to be aware of during the implementation is it's really easy

to hang on to a reference when you don't need to and the object's not doing anything useful anymore. Exactly. So that was kind of interesting. But again, it's just really a publisher subscriber model. I mean, it's pretty simple at its core. And one of the things in.NET is just event handlers. Like you have a button click and you see this a lot in or in the old school where you had user controls, ASCXs. You know, you'd add an event handler or something, and any time something happened, it would fire it off. It just knew that something happened, and it would go execute its code. So, you know, it's kind of that way of broadcasting those events back to those controls, right? Yep.

So if you're, like, working with a grid view or something, you might have events like on row changed or on new row, something like that. And then what happens is, you know, you can hook any number of events up to it. They're all observing this event. And so when this event happens, it's going to trigger those off one after the other. So there are a bunch of interesting sources I found within MSDN. Microsoft has a lot of great documentation um sometimes not not necessarily every pattern but they did have specific documentation on the observer pattern and they actually have this in use in the reactive extensions and so there's

two interfaces that are available i observable and i observer um that that both help to use this pattern, right? Yep. And I don't think we actually mentioned the kind of most common use case for something like this. The most common example, which is I think at least, is like a chat server where you can kind of log into this chat room. And when you log in, you're registering to receive these events so that when Alan types a message, then someone knows that I need to see it and Outlaw needs to see it. So we're observing these changes to the room. And so whenever someone adds something, anyone who's observing this room is going to see those changes and they're you know their computers are responsible for displaying those messages and doing whatever else right hmm yeah i mean that would be it if if you have

something that's basically listening at the event as you enter something specifically one direction though and so that's why i was kind of like no but that's your example with the the chat though is kind of two-way no not really not if they're all published so the event is something gets entered right and then that as soon as something gets entered then it notifies all the listeners so they could do it now if you're talking about true two-way communication but that's not what this is you're updating like a central object that object then notifies everything out so i tell the chat server hey i send this message and it's responsible for knowing you know there's no peer-to-peer going it knows who all subscribed to this room and it knows to send it out to the only those people now there's multiple ways that chat could be handled but

in what we're talking about right there that actually would be a way that you're doing it you update the central system and then it notifies out all the subscribers to that. I guess like another, another example though that I was thinking, but I don't really, or the observers, I should say anything that's observing them when that event fires off,

then it would actually notify all those observers. Cause I guess like one thing I was thinking about was like notifications. Um, like, so, so if you like think about like ios devices or or like any kind of mobile device right like so you so you your application subscribes to an event right and then the server side uh would want to notify all of those subscribers i was kind of thinking

like in pub sub model but that's well that's a really bad example for this pattern, though. Yeah. That's more distributed type of... Yeah. Yeah, I mean, again, the event handlers, like the grid thing was probably the perfect example. I mean, you see that all the time in.NET. Yeah, the only thing that's kind of weird about that is that those events do happen in sequence. So it calls the first and then the second and the third.

And strictly speaking, in the observer pattern, I don't think it really talks about the order in which things happen so it could be possible that it you know all gets kind of shot out at you know essentially the same time or in not any particular order yeah well that's why i was definitely going from the server to the device. So you have the one way. And as far as the server is concerned, it doesn't care if which device responded to the event when or what order. Each device responding to the event is completely independent of each other.

But that's not within the same system. I know, so that's why I'm saying... It demonstrates what you're talking about, but it's not the same. I'm only using that as a conceptual way to... How can you visualize this? Yeah, yeah, okay. And I'm not... And that's why it's kind of a weird way to use that, though.

There is no real textbook kind of example of these patterns aside from the textbooks. When you get out into the real world. Good call. There's no real textbook example except for the textbooks. Yeah, but you're never going to run across a case where you can say, hey, this is the observer pattern. Let me go copy the code from Wikipedia and I can go home for the day. Copy, paste, save, commit. It never works like that.

You always end up kind of tweaking or something. So every example you come up with is always kind of a slight variation of the actual pattern. Well, I'm sure if you copied all your code from Wikipedia, it would all be about, like, animals and cars. Yeah, pretty much. That's right. But, yeah. Person.walk. Yeah.

But, I mean, overall, it's a fairly simple pattern. And, you know, it's one that you've probably seen a lot. Yep. simple pattern and you know it's one that you've probably seen a lot yep but the reason i specifically wanted to mention the the grid thing is because i don't know what happens if one of those handlers throws an exception but i assume that you know if handler number one or you know the event i fire off my event and the first handler throws an exception then the second one doesn't happen right because the first thing kind of blew up and that kind of defeats the purpose of this um hub sub model well that's why I was trying to visualize

this as the notification thing, right? Because then, like, I don't care what your phone does. Yeah, if your phone blows up, it doesn't affect all the other people. Yeah, so a notification is sent from the server to my phone, because I subscribe to that for, you know, whatever that event is. You know, notify me of weather events in my area,

right? Yep. So I don't care what happens on your phone when you receive the notification, but, you know, when I get it, I might respond to it in some way. And so I was kind of like trying to visualize that as like, you know, a pub sub environment where, you know, each responder to the event can happen independently of the others and it doesn't matter, you know, how they react to it. Right. Oh, another good example is our mailing list.

If you join our mailing list, if you subscribe to it, then whenever we actually send out a message, then you'll receive it and you can theoretically unsubscribe. Otherwise, we'll just kind of keep sending them forever. Wait, there's no such thing as unsubscribe. No, the observer pattern does not cover unsubscribe. It's strictly pub-sub. I don't know.

Now you're trying to make it pub sub unsub yeah so now it's the gang of five book right so we have now beat that one to death uh what's what's the uh oh wait wait hold on joe actually had uh some really good things on here some consequences of it yeah i was just looking at the gang of four books for like the downsides of this pattern and they were kind of weak but i thought they were kind of interesting anyway so one is abstraction layer hopping so that's when um you you know theoretically your sender and your receivers don't know anything about themselves or you know they don't have to know anything about themselves if you're talking about disparate systems or whatever so if you've got something that's um

you know system b is attached to system a or it's watching system A, then these guys have this relationship. And it may be kind of hopping layers. When I say layers, I mean things like security or network models or whatever else. Theoretically, I can attach some sort of application. I keep saying it. I said different words. I should be saying my application observes, say, an event on my network card.

And so every time I send a packet, it does something. But when I do that, I'm kind of ignoring all these layers in between that do things like, useful things like making sure packets get received in the same order or UDP, TCP, all sorts of stuff.

Who cares? But the idea is that you're kind of shortcutting this system, and that isn't necessarily a good thing. Yeah, that's definitely an interesting consequence to this. Yeah, and kind of similar to that too, there's also this notion of the basic pattern doesn't really account for any sort of queuing or ignoring. So, you know, you can imagine a big system where there's a whole lot of subscribers and not necessarily something you accounted for, you know, when you just programmed your initial,

you know, node, the thing that's being observed. And so now there's a whole lot of traffic going on and, and maybe you are, um, either your observer is sending out too much data or your actual, um, the things that are doing the observing are actually getting flooded because there's just too many events being thrown. And because these things aren't attached, you don't have a good way of really negotiating that relationship. And so any sort of queuing or ignoring or smoothing or whatever is really up to you as an implementer on both sides. Cool. All right.

And now it's your turn again. Oh, my gosh. Let me catch my breath. You said so much there. I was still trying to just soak all that in to figure out exactly how to respond back to it. Well, if you think of the example of watching network card events, sending packets or something like that, that's a lot of traffic. I don't know if you've ever done Wireshark in your computer network and just watched the flood come in.

It's a lot of information. So if you attach something to that, some sort of... But now, because at first when you said that the specific Gang of Four design pattern book had some, what you felt were weak consequences, at first I was kind of like, weak? Come on, man. That book's pretty strong. And now I'm like,

oh, yeah, I might agree with that assessment. Yeah, like, you know, I have let's say, you know, a real loose example here. I've got some sort of program that can attach to a stream and it will write it to the screen, right, to console. So, okay, that's cool. And that's, you know, a nice little solid functional piece that I can take and compose into other things. Well, now I take that and hook that up to my network card.

And so now it's, you know, printing everything that's going through my network card. And clearly the network card has got a lot more information going on than can be quickly written to screen and like ascii and so you're gonna it's going to be an overload of information you're quickly going to eat up your memory and it's just not going to be able to print out as quickly as the information going back and forth yeah i mean i see where you're going with that i'm just still like i guess as far in turn in regards to consequences though really trying to come up with like a real more a more practical uh example of those consequences yeah it's just kind of weird because you've got these two building block things that you should

just be able to kind of stick together but this is an example where you know you do kind of have to know a little bit about what you're sticking together which is kind of you know coupling in a way yeah that's just kind of understanding the two things that you are trying to put together. Yep. Alright. Well, I think we've beat that one up. Alright. So, moving

on to Chain of Responsibilities, which I picked because it was always a little bit confusing to me, and so I wanted to read up on it a bit. And after reading up on it a bit and after reading up on it a bit um it is kind of confusing and i think it's confusing because there's not a real strong use case for it so i can give you a real world example this is the one that you find in the gang of four book or basically if you've ever been a part of a company that you know a large

company that had some sort of procurement or purchasing program where it's like, if your request is under $50, then it's approved. Who cares? And if it's greater than 50 and less than 250, your manager has to sign off on it. And if it's, you know, greater than 250, but less than 500 accounting, and if it's less than 5,000 greater than 500, then your CEO has to be the one to say, yes, this is good. And so this is an example where, and this is the bad example of inheritance actually, where you inherit from a manager, the manager inherits from accounting and accounting inherits from the CEO. And you say, in this example, if it's greater than $50, pass it to my parent. And the parent, which in this case is the manager, says, well, if it's greater than 50 pass it to my parent and the parent which in this case is

the manager says well if it's greater than 250 pass it up a level and so you can see there's this kind of this inheritance chain of responsibility where if i'm not equipped to deal with this then pass it up a chain another example here is like the military where it's like you know maybe this is i don't really know my ranks but if the lieutenant isn't qualified to make this decision or certified hold on before we get crazy about this because there's a really great real world real world example that we all use every day that is chain of responsibility oh yeah and that's the exception handling okay Okay. Right? So this same, you know, because I was trying to find, like, what's a great example that actually exists within.NET or any other language, right? And I stumbled across this gem of an answer on Stack Overflow, and we'll include this in the show notes too. But, you know, it said that this is why exception handling is an example of the chain of responsibility.

Okay. One, the sender will not know which object in the chain will serve its request. Right. Number two, each node in the chain may decide to serve their request, i.e. catching an exception and wrapping it with an application specific exception. Right. i.e. catching an exception and wrapping it with an application-specific exception, right? Or three, each node can forward the request, i.e. throw in the exception to the immediate caller. Or four, none of the nodes can serve the request, i.e. it leaves it up to the caller, right? Which, I mean, if you think about it, like when you do a catch statement, right,

you're going to say like, okay, a catch null reference exception, right? And so you're trying to catch a specific type of exception. So if the exception that comes up, that bubbles up is of that type, right, then you're going to deal with it. Otherwise you're going to let it go on up the call stack, right? So this is like a near example of if it's less than $50, then do this.

Otherwise, I don't want to hear about it. Let that bubble up to somebody else. I don't want to deal with it, right? Yep. It's not me. Yeah, absolutely. And this is an example where it's not 100% the pattern as described in the book because there's no inheritance. There's no notion of this element

in the chain passing it to its parent, but it's conceptually the same thing where you shoot this thing off and you don't really know who's going to end up dealing with it. All that you really care about is just sending your message in the first place. Right. And I found this other great quote too regarding

this pattern and the observer pattern, also the this pattern and the observer pattern also the command pattern the mediator pattern but uh that we can include too but all of the these four patterns chain of responsibility command mediator and observer they each address how you decouple the senders and the receivers right but each has different trade-offs right so so if you think about like that you know go back to our discussion just a moment ago about the observer pattern, right? It was like a PubSub kind of model

where almost kind of like a fire and forget, right? And in that case, everyone who wanted to listen to your events, they would subscribe to them. But in this case, it's a fire and forget. And it's, oh, well, I don't want to listen. I might not want to listen to all of your messages, but I want to listen to these specific ones. And if it's these specific ones, then I will react to it like null reference exception.

Otherwise, I don't want to hear about it. Right. And I think that's actually a really important distinction to make between chain of responsibility and the observer pattern. The observer pattern, I want everyone who's observing me to know about this. And in chain of responsibility, the big difference here and kind of the commonality that you'll find when you look at all these examples online is that there's always one object that handles request and then done. So it kind of jumps out of the chain at that point and it doesn't continue.

Whereas observer, you know know everyone deals with the event everyone's subscribing chain it's you know you're going down the chain as soon as it hits then there's a match then done does it automatically get popped off at that point or can it keep going down the chain and so in chain responsibility um it the chain kind of always lives in this one chain i guess you can add to it dynamically or remove items but really it's like you know once you hit the manager or the counting or you know in the the exception example once you get caught once unless it rethrows you're done oh so but that was my question so like with the exception handling you can rethrow and keep going back up right but that's but you've made the

decision though right so you decided to catch it you might have done some action. Maybe you logged a message or whatever. And then you either decided, let me re-throw the exception as it is to let it continue on. Or maybe I want to take this null reference exception to continue on with that example. And maybe I want to throw a new exception that might be more meaningful to my specific application, right, to help me later on diagnose any problems, right? So then I'm taking what was there, and I'm reacting to that, creating a new exception to throw up to it. See, this one's interesting because I was thinking it kind of fit along the, like in your browser, the DOM event bubbling type thing.

Right. Because it can be caught, except the difference is the, and that's why i asked the specific question about whether or not it throws it out after it uses it because in the dom you know the the event happens at the element and then it bubbles up to the to the parent node then the parent node all the way on up to the document but here's the deal in the dom hierarchy of event bubbling it only stops if you tell it to stop. If you tell it to stop propagation, then that's what happens.

So that's why I was curious about how this was going to be worded there, because instead of saying, yeah, go ahead and keep going up to the parent, it just does it implicitly unless you tell it to stop propagating up. Right, so that's the point. The difference here is that in the observer pattern, once the event is fired, every subscriber to that is going to have a chance to react to it. In the chain of responsibility example, it's going to follow a path.

But the DOM is that, and that's what I'm saying. This has nothing to do with the observer. Right, but what I'm saying is that in the chain of responsibility path, it follows that path, and if at any point during that path it decides hey let's just react to this situation and don't continue sending that up then it stops but that's i guess that's my question so what we were saying earlier is you were saying that the chain of responsibility basically cuts it off when it gets to it unless you tell it to continue going so would the dom event bubbling be a chain of responsibility because it doesn't stop if you if you actually intercept it at that level it keeps going unless you specifically tell it not

to keep going yep and so there's this example um and you know this is one of the things where this is vague there's you know the there's the strict definition of chain of responsibilities and then there's the real world. There's this notion of intercepting filters and sometimes you'll see chain of responsibilities being an also known as for intercepting filters and sometimes you'll see people define it a little bit different. But the notion there is that you've got this chain of filters

and each one can do something to the message that it receives. And sometimes it can say, i'm done and sometimes it can just slightly change the message and pass it on and that's the kind of notion of filters so if you think about a photograph you know you might add a this filter which brings out the yellows and then another filter that makes it black and white and another one that you know does something else to it and so you can kind of chain these things together and you know i'm using the word chains but it's not strictly speaking the chain of responsibility so in this dom event it's something where it's it's very similar to chain of responsibility and i think anyone who's familiar with chain of responsibility you know is going to kind of see

that and know what that means and know that's a slight alteration gotcha but i think it's it's close enough to okay get a nod at least it's a similar type pattern all right right and i actually um you know i wanted to mention earlier we talked about when michael brought the exceptions and kind of you know and alan said you know rethrowing so at that point you're kind of starting a new chain you're kind of continuing on dynamically it's a little weird but i saw this referred to as chain of chains otherwise known as a tree of responsibility which i thought was kind of funny so yeah it's kind of neat so i wanted to throw that out there and also i wanted to mention a little bit on filtering there's an example um sorry not on

filtering uh just the chain of responsibility an example of this might be and this is another rough example but http handlers like if i've got a handler that knows how to deal with the ASCX file extension, you know, then it's going to kind of say, okay, I got this one guys and buck out. And you might have another HTTP handler that knows how to deal with an image exception or whatever else, you know, a list of MIME types. And so these are all examples where it's kind of like, once it's recognized, it can buck out and do its thing. Because the ISAPI filter would intercept it. Right.

Okay. But another kind of example, something more along the lines of filters, is when you think about processing, like post-processing an HTTP request. So my server is sending out the HTML to the client, and I might have a bunch of filters in place that do things like strip all the white space, gzip it, do whatever else, maybe even SSL, whatever. All that stuff is kind of decoupled from the sender. So that's an example of more standard filtering where it doesn't do any sort of bucking out, but it's still related to the chain of responsibilities.

So just another reminder, please do, if you get a chance and you remember this, somewhere towards the end of your drive, go into iTunes or Stitcher and just, you know, even if you just click the rating, that would be awesome. But if you would take the time to leave us a few words, that would be incredible. You should pull the car over right now. Get on your iPhone. Let's be safe. Pull over to the side of the curb in this shoulder area and go ahead and write a review.

Hold up. Can you tell Siri to do that? I'm sure you could dictate it if you wanted to, depending on if it's Android or iPhone. There's dictation methods for Windows Phone. Maybe we'd write an app that would do that for you. Hey, I'm all on board with that. But the holidays are coming up, though. So this is the time that you share.

You give. Yeah. So share the show with a friend or friends and, you know, spread the word. Yep. So end of shameless begging. Oh, no. That'll never be done. Fair enough. Yeah.

So our next pattern here that we were going to talk about this evening was the iterator pattern. All right. Our next pattern here that we were going to talk about this evening was the iterator pattern. So just a brief definition of that one. So the iterator pattern is a pattern in which the iterator is used to traverse a container and access the container's elements. But the pattern decouples the algorithms from the containers, right? So in some cases, the algorithms are necessarily container-specific and thus cannot be decoupled. Wait, what's a container? Right. So let's say that if we had to make a more generic version of that statement,

say that we abstract the iteration away from the collection. So you have some kind of object type, and it has some collection of data in it, but the act of moving through, of iterating through that collection of data is separate okay so i've got a list right okay yeah so an example of an iterator and with my list here it would actually be responsible for going through my list node to node and it's responsible for knowing how to get to the next item in the list yep okay so if it's a singly linked list, a doubly linked list, if it's an array, it doesn't matter.

That's the iterator's responsibility? Yeah. Okay, so here's specifically if we want to go with the Gang of Four definition, right? It provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. So let's not get too focused on how to move through the data. It's just that you're not exposing what that data is. Okay, so I could say like for each var x and blah, and it doesn't matter if it's a collection or a list or an innumerable or anything

because that's hidden from me. All I care about is my x. I guess what I'm really trying to get at with a better example though is instead of like, so okay, you're bringing up like list examples, right, that are in the language already. But what I was thinking of is like, let's say if you had to create something on your own, right? And whatever that data is that you have more than one of that you might want to allow someone to iterate over. You don't want to expose that part of it, right? But you want to allow them the ability to traverse it and go from one to the next to the next. Okay, so it could be like the Fibonacci sequence where I say, give me the next one.

And it's like, all right. Okay, I like that example better because now we're not too tied in onto the conversation of lists. Of lists or collections. That's what I wanted to try to avoid. I don't want to get stuck into a conversation of lists or arrays or anything like that. Okay, so the iterate literally just knows how to kind of go to the next one. Move next. Right. Fibonacci, primes, whatever.

That would be a great example. So specifically when you would want to use this pattern is when you want to sequentially traverse whatever that collection might be, right? And you want to decouple that traversal logic or algorithm away from the container, right? So you don't want the user to have to know how you're containing that data, right? Like behind the scenes, you might have it listed as a dictionary

or you might have it contained in a hash table or a map depending on your language of choice here. You could have a whole bunch of different ways that you represent that data. An array, an array list, a list item, whatever it might be. But you don't want to expose that but yet you still want to allow your user

the ability to traverse through it and just say get next or for dot next or whatever. Okay. Right. So, so next time someone asked me to implement fizz buzz and I don't feel like doing the standard solution, I don't want to do the recursive solution,

which we talked about. I think if you're going for bonus points, then right. I implement a sequence and an iterator and yeah, I'm going to get, I'm going to get hired, right? Probably, probably. Or like, not one of these guys. So we kind of already hit on this a little bit, but there were some examples of where you might use this that are already baked into.NET, for example.

And you mentioned foreach as an example uh anything that's going to use the iEnumerable or iEnumerator you know interface types you know that those are implementing this enter this pattern right so there's plenty of examples that already live in the uh within the uh you know within.NET itself without even trying to look hard for one. Okay, I was thinking like a file reader too. You kind of like fetch the next line and you keep fetching until there's nothing left to fetch. Yeah, and that's another great example

because you don't want to care how the document is stored. Are you doing this line by line? Are you doing this based on some kind of size constraint? Maybe you're streaming this in, but you just want to say, get the next chunk. Get the next chunk. And that chunk might be a line. That chunk might be the next 16 bytes, whatever it might be. Okay.

All right, cool. Yeah, so that was all I had to say. Oh, I did want to mention the consequences. Oh, God, not the consequences. Yeah, so that was all I had to say. Oh, I did want to mention the consequences. Oh, God, not the consequences. Yeah, I know. What is it with you and consequences tonight? I love to be a naysayer. Are you on Reddit?

It was you. Some people just want to watch the world burn. So the deal, as we mentioned, the iterator is responsible for sequentially, and that's the key word there, sequentially keeping track of its location in this list. So, what happens if I say, you know, for each element in Fibonacci sequence, and then inside that loop I say, for each element in Fibonacci sequence. Now, I've got two loops accessing the same iterator and what's going to happen is you know the first loop's going to hit the first element we're going to hit that second loop and the second element isn't going to start back over right because there's only you know we're this is happening in sequence there's only one copy right

you'd basically like skip over yeah yeah yeah there's that as a as a example consequence there's another one where that i'm sure at one point or another we've all hit this example and be like oh crap not that crap again where uh you have some collection that that you're going through that um implements one of the the interfaces innumerable or iEnumerator And what you want to do is you want to be able to modify that list as you're looping through it. But then as soon as you do, it throws up an exception because now the list, the container has changed. And so it's like, well, I don't know what to do.

Where am I supposed to go next? Next just got deleted. Right? Yeah, totally. Yeah, so that's an example of a consequence. But it's worth it. The ease that it provides in 99% of cases. Yeah. I mean, link was another example that I had where, like, you know,

within the.NET framework where you could do some simple... where you could move through an enumeration and either take some kind of action and select it or for each of these. Right. And it actually utilizes yield. Yeah, I should do more yielding. It's cool. Not even when I drive.

Wow. Georgia has so many yield signs. We do have lots of yield signs. Why do you need a yield sign to turn right? But there are so many people in Georgia that don't know how to drive. So, I mean, fair enough. Off topic, sorry. Wow.

Talk about derailing yeah i just got so mad yeah there was some definite pent-up anger there so anyone that wants to observe his anger you can just uh subscribe uh to coding blocks so on to uh some resources we like this go around. I already mentioned Codecademy earlier, or Codecademy, I should say. Codecademy.com. And that's where I did the Rails thing. And, again, for anybody that's trying to learn something, great interface. And it actually kind of makes it a little bit fun because they give you, like, little challenges to do along the way. And, I mean, it's practical learning.

I mean, it may not be the deepest ever, but you can literally pick up some nice stuff along the way. Like, I feel like I could actually look at a Rails application now and at least understand what's going on. Yep. And also, got to mention the Gang of Four book, Design Patterns. We'll have a link to that in the show notes. Have we ever talked about that one before?

I don't think so. We've mentioned it quite a few times, but just in case this is your first episode. Maybe we should include a link in the show notes for that one. Definitely head to the website. You can get a link to the book. And this is the book, and it's still on version number one. Yes. Yeah, and when was it printed?

Like 94 or something like that? I think it might be 80 or something. It might be public domain soon. You can publish your own version. It's up on Google Books now. No, it was copyright 1994. Wow. Yeah, so, what, 20 years later, they still got it right?

We haven't even found a need to, like, hey, there's this typo over here. Can you guys fix that? I think it's just Tremont's Visitor. Do you think that it's because they actually got everything right? There is nothing grammatical or no spelling mistakes, no typos. They got it all right. Or do you think they're just like, I'm not doing that. I don't care.

Honestly, I think there are so many different interpretations. There are so many different variations of each one of these patterns that there's nothing that really quite matches the book that they're like, you know what? You really can't write up just one example that's going to apply to so many different patterns. This is close enough.

I bet I know what it is. It's revisions for the book are dealt with by the chain of responsibility, and every one of the authors is like, not it. They short-circuited it. Not it. I think Visitor scared them off. I don't want to go through that chapter again.

Well, Reddit exists now, and they don't want to go through that chapter again yeah well reddit exists now and they don't want to be exposed to that nastiness right oh man trolls so uh the next one oh yeah were you going to talk about your next uh resource there uh oh yeah plural site we mentioned uh there's a great video i need to find the link and we'll have that in the show notes but plural site is awesome it's got some great videos on design patterns oh yeah i remember which one you're talking about like there's uh it's got like every author from plural site ever that's ever made a video or ever thought about making a video it's all contributed to one i think there's 25 total that they have like and it grows like they keep adding to adding to it it's like a mass i think

i know the one you're talking about is called like the design patterns library i think yep and it's uh it's like 16 hours of of video content from plural site but if you speed it up it can be double double speed reduce that down to eight all right there's a ton of just design patterns if you search for it in plural so i was gonna look on linda too to see yeah how many there were but yeah so you know let's get into the tips of the week here so i found this great little thing so uh when we were having our database episode one of the database episodes we had mentioned this great little tool that i forget which one of you guys have found where essentially what you could do is you, it was a website that you could go to.

You could select what database manager you wanted to target. Then you could create a schema for it in one pane of the window. And then in a separate one, you could write queries against that. And then you could generate a unique URL that you could then share with a friend to say, this is an example of what I'm talking about. Given this schema, you could do this query and it returns this result. Right? Well, I found the exact same thing, but for code.

And it is fantastic. And we'll have the link in the show notes. But if you go to rextester.com, what you can do is you can select from your language. So they have assembly, C sharp, C plus plus, C, the list goes on. Objective C is in there, Java, JavaScript, Ruby, Python, whatever, right? You can pick the language that you want, what kind of editor you want to use. You can write the code, right? You can then run it, see any compiler warnings that are going to happen. You can see the output of you running it, and you can create a unique URL

that you can then share with a friend. So you can say, this is the code that I'm talking about. If you did this, you can see the result for it. Just such a great little uh you know ability to share code without someone else needing to install something like a visual studio for example or any kind of compiler but yet they could still see the effect of something

i love the interwebs yeah it's very nice for sharing uh sharing a little code snippets it's it's very similar to uh what uh js uh ben or what was js fiddle js fiddles one um it's just like that except for compiled languages beautiful yeah and they have some scripting ones but yeah it's cool cool as heck so the thing i wanted to mention was actually a Chrome plug-in called Postman. And what this lets you do is issue REST requests. So if you're working with a REST API over Git, then it's not such a big deal. You just kind of tweak the stuff in your URL and then see what you get back. But if you're using all the verbs you're supposed to use, like link, unlink,

really the one you're using is going to be post or delete or update, then, oh, there is no update, is there? Yeah, anyway, what you're doing is post, then you can actually use it to pass your parameters easily. You don't have to do any sort of weird fiddler stuff. You don't have to mess around. It's just right there in your browser. You can hook up your URL.

Here's my parameters and set it to post or update or whatever and hit it and get your response back so it's nice for testing those rest apis oh dude that's sweet i've always used uh fiddler for that i think it's much easier yeah i was gonna say like you can use fiddler but you basically have to create it from an existing request yeah this is sweet and it saves your history and everything. It's actually really nice. But you can do the same thing with Fiddler there, right? No, no. You can save that.

Fiddler, you can, but it's a whole lot easier if you start from a base request that you've already made. This allows you to build it up from scratch. Yeah, and it's just really easy. It's very specific to this one task, so it's nowhere near as powerful as Fiddler, but it's just really easy it's very specific to this one task so it's nowhere near as powerful as fiddler but it's just really easy and lightweight and for those that haven't ever experienced fiddler it's a tool from toric yep and if you're not an admin on your machine you can probably still install this extension yeah and that's another thing too just i in in support of this as opposed to fiddlers fiddlers only on windows oh good point and you could do this on basically anything

so that's very sweet uh all right so my tip of the week so from my reddit uh fun that i had uh jsperf came out of this and i'm sure that i've been to this site before and i don't know why it never stuck out but jspurf.com if there's anything that you ever want to test and I know I've seen this site before because when I was looking at different types of data grids like JS data grids I found a comparison of some of the most popular ones out there and it's excellent anything that you do you can put in multiple different chunks of code and have it run performance tests against all of them. And it will actually do charts and graphs and data plots for you. And so you can actually see, hey, is jQuery faster than, you know, EXT for doing a DOM element get or something like, I mean, there, you can literally, whatever you can think

of or dream up, you can put in these different chunks of JavaScript code and have it compare it. And, and just like JS fiddle or some of these other ones, you can then save off that URL and reference it later so that other people can come look at your JS performance test. so a fantastic resource definitely we will have a link for that in these show notes sweet and we hope you learn a little bit about the behavioral patterns we discussed tonight observer channel responsibilities and iterators and you know yeah so subscribe to us on itunes stitcher more using your favorite podcast app. Be sure to leave us reviews. We greatly appreciate it. We've mentioned before, but

we'll give shout-outs if you want to write us in with any kind of preferred method of contact or your method of recognition there. Definitely contact us with a question or topic. Oh, God, you just did that.

But you didn't say the contact. No, no, go on. Yeah, whatever. Okay, I'll do it. So,

you know, if you have any questions, contact us with a question or a topic idea, leave us your name, preferred method to shout out, and we'll be sure to mention you. And, uh,

you know, you can reach us at, uh, comments at coding blocks.net. Yep. And, uh, visit us at codingblocks.net

where you can find our show notes, which are extremely detailed and painstakingly formed for you. And, you know. We'll have some examples and stuff, too. And make sure to follow us on Twitter at Coding Blocks. And if you guys can think of any examples in.NET Framework or any open source projects or anything, the patterns we've talked about so far,

we would love to see them. So it doesn't have to be a question that you necessarily have to send us anything. I'd be curious to hear some interesting visitor pattern uses. If you have any visitor examples, please, we would love to see them. I've never seen them. Real world.

I don't want to see an article. I want to see a link to source code. Like the first pattern that comes to mind when you've seen encode what is it factory factory right well it's the first one in the book so it's about as far as most people get in the book i've never seen the visitor pattern anywhere except on wikipedia now i've gotten confused with the um iterator pattern before just because it sounds like it's visiting each node, but that's really not how it works.

Yeah, it's not even close. It hurts my head. Alright. That's a wrap. So, when I see a door with a push sign, I pull first to avoid conflicts. Nice. You want another? All right.

Don't you mean update and commit? Okay, okay. Who wants to be the receiver of this one? One of you guys is going to have to pick. Joe does. Okay, Joe is. Apropos. Are you ready this one? One of you guys is going to have to pick. Joe does. Okay, Joe is. Apropos. Are you ready, Joe?

Here we go. Here we go. Knock, knock. Race condition. Who's there? Okay, tough crowd. Oh, I'm smiling.