Coding Blocks - Command, Repository and Mediator Design Patterns

Episode Date: June 3, 2016

In this episode we go back to the design pattern well that we’ve been away from for so long.  We cover the Command, Repository and Mediator design patterns.  It was hard for us to believe, but it���s been almost a year since our last design patterns episode!!!  Come on in for fun, learning, and of […]

design before design design oh god let's try that again you're listening to coding blocks episode 42 subscribe to us and leave us a review on itunes to learn more using your favorite podcast app visit us at codingblocks.net where you can find show notes examples discussion and much more chat us up on codingblocks.slack.com and new slackers can join by heading to www.codingblocks.net slash slack. Follow us on Twitter at CodingBlocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood.

I'm Joe Zack. And I'm Michael Outlaw. This episode is sponsored by Infragistics, developer tools and productivity. Design before you build with indigo studio share and collaborate on designs with indigo design.com and build high performance enterprise ready desktop and web line of business apps and mobile apps in your platform of choice wpf windows forms asp.net html5 javascript and ios android oramarin, head over to www. Infragistics.com

to get your free trial, view sample apps, and to see the tools in action. Alright, so now up for our news section, but first we want to talk about our reviews, and this time we decided to let Alan do it, but he's agreed to do it as fast as he can

possibly say it. Interesting, that was not part of the deal, but I'm agreed to do it as fast as he can possibly say it. Interesting. That was not part of the deal, but I'm cool with that. No tape axes. Right, right. Interestingly enough here, though, we got 11 new reviews in both Stitcher and iTunes. Already too slow. Now, it has been like five months since we recorded an episode, so that's pretty awesome. So here we go. Stitcher review. By the way, there were some fantastic ones in here we're gonna get to some of these i mean just excellent so here we go specter 013 chris christopher genius hammer tag joe recursion joe that one's fantastic one of my favorites gearhead 2k

manrique 2k mike north andrew m mild-mannered Calvin, and Free Leagues. Now, in iTunes, that was Stitcher. In iTunes, we had Sid Savara, Jay Mayer, Tony Korb, NMKL999, Eshwarts20, MochaDWI, so drinking and driving with coffee. I don't know. Benjammin, WiscoCMO, NewZeroRiot, NateTheDBA dba and paulo is paulo yeah not to be confused yes paulo is most definitely paulo so thank you guys seriously like we read all these they were fantastic some of them made us laugh some of them made us well just the username alone of joe recursion joe is worth a laugh but you know but he do have a correction oh oh yeah it's actually it's not

mocha dwi it's mochad we really i don't know i just made that up but you i'm like what are you saying it's much had we he was so confident about it you're like yeah okay well i guess he's probably right yeah joe recursion joe wrote that we are the only non-boring coding podcast so i was like i i gotta like that yeah that's pretty awesome but listen to this one probably right yeah joe recursion joe wrote that we are the only non-boring coding podcast so i was like i i gotta like that yeah that's pretty awesome but listen to this one this one was awesome so we we joked one time i remember teasing alan about a comment that he wrote in the code where it was i have no idea how i got here and i guess someone else thought that that was humorous because they've done things like

that too. So genius, which you gotta love that name, wrote this awesome comment. Okay. And there's going to be a quiz for you at the end. The comment is you can try to refactor this function to your heart's content. I know you will try. So when you're done trying and failing increase this number by one yeah what do you think the current number is i believe it was 26 right oh you cheated no i remember reading that one yes it was 26

26 times and it already everyone had tried to refactor it. That was awesome. Actually, you know what? I'm stealing that. I'm putting that in our face. That is the most beautiful comment I've ever seen. I actually had somebody tell me the other day. They were like, hey, man, I've actually tried to go through and do this. And I was like, yeah, you're about the fifth person that's tried to do that. Because I've tried to do it and a couple others.

And we basically said, we don't have time right now because this is ridiculous. Well, you know, there was another comment in here, too wanted i wanted to comment on is that too many comments maybe um you never have too many comments yeah right wisco cmo he wrote that uh you know that he wished he loved the new call of duty game as much as i do and i kind of wanted to correct him because it's like well i don't really know that i love it as much as like the previous version like i'm just not feeling like that current version and so that's why it's like you know you end up moving on to other games like i feel like joe wants to insert one right now that starts with yes games oh uh overwatch man overwatch is released on may 24th which means it'll be out by the time we get this podcast out.

But yeah, I'm prepping my hands right now. I'm stretching. I'm very excited. I played the beta. It's awesome. I love it. There's a lot of excitement around that game. Have you checked it out?

I have not downloaded it, but it might be the one PC game that I purchased. Oh, I get on PC, man. You don't have to get it on PC. Oh, it's on console? Yes, it's on everything. But it's you don't have to get it on console yes it's on everything but it's gonna look so good on the pc i whatever yeah i don't know but it does look pretty fantastic now now since we since i did bring up call of duty because you know this

is a day that ends in y um have you seen the new trailer for call of duty uh infinite warfare no i saw its ratings on youtube yeah that was sad right were they bad it's crazy sad it was horrible yeah like it the the down votes were i don't remember i think at the time that i saw it it was like definitely more than twice the down votes than up votes oh wow no i have i have not looked i will say though i have started playing uncharted four man it is it is amazing well just one i know you're tired of call of duty but the one last bit of call of duty news though is that it'll include it's supposed to include modern warfare 4 or you know the original modern warfare call of duty 4 modern warfare so we'll see they i mean they definitely teased

some of that and so it's like what does that exactly mean i don't know yet but we'll see but speaking of other games though new in the gaming world yeah big news here um i made a chess game where you can play against yourself or an AI or random moves. I kind of cobbled together a chess engine and a chess AI and made a little game out of it. It's part of my effort to learn new technologies, get to be more comfortable with some JavaScript concepts, and also make games. And so you guys should go play it and look at the source code and tell me what I did wrong. And also ping me about it, and I will give you an earful about Webpack.

So tell us what was the stack that you used here? Because you said the goal was to learn a bunch of technologies. So what was the stack? Yeah, really, this time my focus was on Webpack. I like Gulp and Grunt a lot. And I think those are really cool ways of doing things. But I also really like Node's require system, and I always want to use that on the front end.

And I heard that Webpack could be a nice replacement for that, as well as a whole bunch of other stuff. It's actually much, much bigger than that. It'll run your web server. It'll do everything. And so I really wanted to give a shot because I thought it might be a nice way of kind of short-circuiting all that work.

But I'm not a big fan of it. there's nothing against the webpack guys but uh I hate having to go to google for everything to figure out like what kind of weird squiggly lines I need to put in place in order to get my pre-processing pre-processing working um so that was the main thing but really I also I'm just trying to get really familiar with the node ecosystem because I do think it's really cool I think um the whole kind of JavaScripty workflow is neat. But even though I'm not a big fan of the language, it's is very convenient to use and it's easy to build it. You know,

since I want to link to a webpage and say, Hey, check out this thing I wrote. What was the front end that you used? Did you just HTML? Oh, okay. So it was just raw HTML.

Okay. And bootstrap. I use bootstrap for everything that's like step number one yeah yeah totally agree and that's probably how you want to hand write your css i couldn't figure out how to test it man like i really wanted to be able to test stuff outside of dom like i want to write unit tests real unit tests no ids no browsers but man i had a hard time getting it going uh and that may be because i don't know what i'm doing but i really do feel like it's just not set up for that most of the articles

i looked for really wanted you to have um some sort of phantom browser thing going on so if you know a better way then you should definitely look at my code and teach me how to do it because i'll i will love you awesome well by the way i did play it like i i played oh yeah and i played it on my phone and it worked rather well i mean did you win uh i did well so i i would have if i hadn't like just shut it down i i basically had oh he had one king and nothing else and and i just didn't feel like messing with you know cornering them that's not a deadlock what's it called um stalemate stalemate stalemate well i could have locked them down which means that you lost you didn't win i didn't lose i just i turned it in a stalemate

you both lose no i wasn't gonna i wasn't in a stalemate i didn't feel like chasing them down into a corner so i just i i basically stopped oh i see what you're saying. Yeah. So, but yeah, it was fun. Actually, there was a bug. It's not really a bug. There was a problem between the chess engine that I used and chess AI that I used because I did not write this from scratch. I basically just cobbled together some things, which is the JavaScript way now. So in that spirit, I just kind of cobbled these things together, and they weren't really speaking the same algebraic notation, which is a whole other earful I can give you on the worst possible format for data imaginable. Algebraic notation is just terrible.

It's even harder for humans. I don't understand why, how that evolved. It's the worst. But anyway, there was sort of a bug communicating that between the two different libraries. And so they would kind of get off, and i'd have to start making random moves so when you like the first couple weeks you play the game i think when i sent the link out to you guys uh if at any point it kind of got out of sync it would just start making random moves but now it's actually much better because i kind of worked out some of that wonkiness oh cool so did you do the adapter pattern uh no i really should have though because i totally

totally hacked it in there um i had a problem with that and you know how node when you require something it'll only require it once and kind of cache it yeah well the chess ai uh it does that right so it comes in its cache but it's one of those um i don't i'm sure there's a word for it but it's basically an iffy right right? So it's a single function. It shares its state. So you can't have two of these chess AIs in different scopes. It's got its own internal state. So you can't kind of tag stuff onto it,

kind of keep track of its own state. You can't basically inherit from it and move on. Everything you do is shared. So I couldn't have two Chess AI objects. It was always one. I'm doing a terrible job of explaining it. No, that makes sense. I was thinking of the memento pattern, though,

because that was the one that we had talked about for gaming purposes, right? For being able to get back to a state. Yeah, that was the revert. I was thinking the adapter, because he said he had two different libraries, and so he was having to communicate changes between the two. Or the facade pattern.

Yeah, I could have done this in a lot of good ways. Well, facade pattern was specifically the one that we talked about for, you know, if you wanted to wrap some API and make its functionality a little bit easier for your usage. I think the only design pattern I really rigidly used was strategy. So the chess AI, the human player, and the random moves were all different strategies, and we'd select which strategies we'd use,

and they all implemented a common interface, although I was doing pure JavaScript, not TypeScript, so there is no real interface. So I just kind of named the functions the same well okay yeah i mean that's that's kind of the same though yeah so i know okay so last episode we did a deep dive into my mind which was crazy and i know that we aren't doing that this episode but i got a couple like like i told you last time you know i had a whole bunch more questions that we didn't even get to but i have a couple that are that could kind of tag along with what you

know with with joe's experience here that uh you know let's see where you guys fall in on this so well this one maybe the first was more of a statement but if you have to pound important your css yeah that's a code wrong that's a code smell right yep okay at least i'm not the only one that feels that way but joe is that what you did for all your stuff did you pound important no um i actually did a bang important sorry um bang nice um uh no i i pretty much did the css like somewhat correctly i think um i mean i use colons and stuff and i think i used the right arrow uh at one point the right arrow that's direct descendant right or something like that i can't um you know i i don't know at the time it seemed to make sense i like that he

was first he says i think and then he says no i did it right i used colons and stuff yeah which you could also use with the bang important right yeah no no importance uh no i actually like i think i did a decent job with css it's even like somewhat organized and there was a lot of custom css you know i had to do the board i had to do all the pieces all that stuff um oh i even got fancy with the borders i did a dash border you did yeah yeah yeah it turned out i know i know things you should put that on your resume that's right that's awesome i know things so what was your second question all right so i'm i'm watching this uh i've been making my way through this plural site course uh from kyle simpson we've talked about him before he has the series of books um on github that are

named in the scheme of um something like you don't know javascript and then fill in the scheme of something like you don't know JavaScript and then fill in the blank, right? You don't know JavaScript closures. You don't know JavaScript asynchronous, whatever, you know. But he's got this Pluralsight, mini Pluralsight course, but there was at least the one that I was going through. And, you know, he brought up this question of, do you name your iffies? Do you name your iffies? Do you name your iffies? Wouldn't it not be iffies if you named it?

That could still be named. I mean, I forgot what iffy stands for. So an immediately invoked function. So let's say, let's be clear, like an iffy or an immediately invoked function. So let's be clear. An iffy or an immediately invoked function execution in JavaScript is a function declaration that is inside of a parentheses and then immediately after it has two more parentheses to call it. Right? Yep. Okay. it right yeah okay so a lot of times for an iffy you know you might just be in the habit of saying

function open paren close paren curly brace and then start writing whatever you wanted to do and then by the time you're done you know wrap that with the the final two uh open and close parentheses to call to you know call it like said, it'll be a function declaration inside of parentheses that are then called, that's immediately executed because there's two more, an open and closing curly brace, not curly brace, open and closing parentheses behind it. Now the question is, do you do the function open parentheses close parentheses curly brace deck style for your iffies or do you name the iffy by saying function some method name

open parentheses close parentheses curly break open curly brace blah blah blah i usually do not name it because the whole point of the iffy usually is to not junk up your global namespace. And if you give it a function name or anything like that, that's exactly what you're doing. You're putting it in the window scope, right? So I typically, depending on whether it's node or something. Now, isn't that happening anyways, Alan? Not really, because you can't get back to that.

If you literally just run the function. Let's just say that it's happening anyways and move on. In one case, you're just saying you don't name it, though. So you can't get back to it. So by not naming it yourself, you're reducing the risk of clobbering some other name because you didn't bother to name it. Right, right. Okay. That's the real purpose of them in the first place. Well, that's not the purpose of the iffy. That's your argument for why you don't name it right okay that's the real purpose of them in the first place well that's

not the purpose of the iffy that that's your argument for why you don't name it now joe what's your take um my take is uh yeah i don't like clobbering the name and i also don't like singletons and that was what i should have said about the uh the requires problem i was having the chess ai is a singleton so i couldn't have two of them with their own state. So I had to hack around it. So, yeah. Yeah. Well, I mean, for one, iffies are a great way to hide your namespace. So to your point about clobbering the global namespace,

some packages actually use iffies as a way to hide that. Right. Now, Kyle made the great point, and now I'm totally convinced. uh, packages actually use if he's as a way to, to hide that. Right now, Kyle made the great point. And now I'm totally convinced. I was like, Oh, that's an amazing idea. I never thought of it like that.

And he made the point that if you don't name your if he's, you should, if for no other reason, then when you're looking at your JavaScript console and you see like some error happened, you don't have to see that dreaded anonymous method list in the Chrome developer console. Instead, you'll actually have a named reference that you can go back to and go, oh, that's where it died. Yeah, I could see that.

And I was like, that is such a simple, you know, bit of advice. And yet it's so valuable. I like it. I don't love it, but I do like it. Yeah. We should just, just make sure your prefix, the name was something nobody would ever use. Like iffy. Right.

Okay. Totally safe. Done. Hey, uh, also wanted to mention, uh, I, or I forgot to mention that, uh that i was on the hello tech pros podcast talking about productivity so after you get done laughing about that you should go listen to me talk about uh all the books that i've read and uh haven't put into practice actually that was a pretty good episode i'll listen to it um there's a lot of good information dropped in there another thing i wanted to do because we do only record you know every few weeks or whatever and probably the biggest complaint we get from

most of our our listeners is you know hey we want more there is a great podcast out there called software engineering radio and i listened to one recently that was about unit tests and how to effectively do unit testing which i feel like a lot of people sort of miss the boat on like we you hear a lot about oh you need 100 coverage well who really cares about testing you know just very generic getters and setters like to me that's a waste of time percent coverage that that seems like a complete waste of time to me so the episode it was episode two 56. We'll have a link in the show notes.

Uh, I really liked it. He was talking about, he, he even went into things such as, you know, you create your test to create your functionality, right.

And to make sure it works. If at some point that's really not a core piece of your, of your software. Like it's not, it's like the 80 20 rule, right? Like if 80% of what is your software like it's not it's like the 80 20 rule right like if 80 percent of what is your core business if it's not part of that and it starts you start just kind of getting longer and longer running unit tests then it might be time to go clean out some of those old ones so i thought it was kind of cool taking the perspective of instead of trying to test absolutely

everything even the things that get touched less than 1% of the time, test the things that are important because that's actually what you want to focus on. You want to encourage people to run those unit tests. So it was an interesting show. I really enjoyed it. So definitely go check that one out. Did they really say though,

like a hundred percent test coverage? So like there's, there's some people out there that say that, you know, their goal is to hit a hundred percent test coverage and you know i mean yeah all right i've never seen it happen first off i don't think you can like that's why i'm like kind of baffled because i always thought that the golden rule was that if you can get in the upper 80s or low 90s then you're you're in a really good state yeah right i mean i guess the point is like literally

to get 100 coverage you'd have to test your getters and setters which typically are doing nothing more than setting like a private variable in a lot of cases and that's that's kind of ridiculous i mean that's if you have getters and setters exposed yeah maybe well like in java you do right in java you don't have like auto property type stuff yeah stuff. Yeah, because they're methods. Yep. Sure. But I guess what I'm thinking, for the first time ever, I had a library that I worked on recently. And I got it to 99% test coverage. And I thought that was insanely unheard of. And I couldn't believe that I had managed to get that high test coverage.

But you know what's awesome about that? This goes back to, because we were working together on this library that you're talking about. There was a case that came up and you're like, man, I can't believe I didn't think of that edge case, right? Well, that's the thing. Is it like unit tests do not, they don't, you know, protect you. They just help you, right? You know, they're a tool that allow you so that when you do make a future change you can ensure that you didn't break something but they're not going to

make sure that every possible scenario works unless you know because you're not going to be able to include every possible scenario you try as best as you could and even with 99 test coverage that does not mean that there's not a use case or bug in the system it just means that you've ran through because really and this is the this is the reason why i take issue with 100 test coverage because all the coverage is doing is telling you that's the percentage of of every single path in the code right right what percentage of it has has um gone through and which percentage hasn't and depending on the tool that you're using to measure the coverage right sometimes if a method let's say you test a method that throws an exception right some coverage tools will not count the curly brace after the exception is

thrown and so therefore you can never count that line you can't ever reach it and, you can never count that line. You can't ever reach it. And so you can never count that line as being tested and covered. And so that's the difference between coverage and actual, like, what the test produced. Well, to be clear, they didn't say that they were trying to hit 100%. They said... Well, yeah, that's why I was asking for clarification. Yeah, yeah. No, they were basically saying, you know, some people will try and strive to reach that. That's impossible.

And what he was saying is, even if it wasn't impossible, that's not really, that's not valuable use of your time, right? Like, you should test things that matter a lot. And so that was kind of interesting. But that's the other thing I wanted to bring up, though, was the cool part was, like, that one edge case, and it was a super edge case that we found after that you know unit tests are a tool they're not a a silver bullet which a lot of people seem to think they are they're another tool in ensuring that you have good code so um i mean the most valuable thing about unit tests is when you go into a project and you make some change you can run all the existing unit tests and know that i didn't break anything right so at the very minimum we're we're you know it works the same way it did right right right yeah so yeah at any rate i'm surprised joe doesn't have something to say about

unit testing since like this is also one of his favorite topics i was just looking at my 98 at color mine really good right and i still i probably get one email a month of somebody telling me that it's horribly wrong but you know what the impressive thing like color mine's not a small project by any means it's all math though so it's like the easiest thing in the world to unit test okay fair enough yeah you just assert things that equal what you expect them to be yep and i try to keep the functions all really small so i could do that and in fact um if i remember correctly that two percent that i couldn't get tested it was all things where basically i the inputs would never be say below zero or whatever and so like there were literally things that couldn't happen but i still had a check in place

just because i'm you know i i'm like that like i'm definitely that you know you see that common code it's like this should never happen that that's totally me that you know, you see that common code. It's like, this should never happen. That, that is totally me. That, you know, we all have our things. So yeah, if I see an error that can be thrown or I just can't leave it, but that's okay.

Cause most of the time I don't see him. So yeah, no biggie. That's awesome. All right. Well, what say you, we get into the show. Let do it so um i think i already hinted at what

this show is about so we're going to be talking about design patterns again and this will be our fifth episode into the design patterns series and i think joe is wrong here because he wrote july 2015 as the last time we talked about design patterns. And that can't be. Episode 30. Yep. What? Isn't that crazy?

It doesn't seem like it's been that long. I blame the 12 Factor app. Yeah, that was four episodes. I blame that we only record once a month. That's part of it. Because this is 12 episodes later. Yeah. Now, do you guys have a favorite of the,

what is it? Singleton. We talked about? Singleton. That's my least favorite, yes. I actually think episode 11. The factories, the method, the factory methods,

the builder, the prototype. Those are some of my favorites. Yeah, I think the strategy and template methods are still the ones that I do the most. And observer is a really cool pattern, but it seems like a lot of the problems that I have in programming are around eventing and that sort of thing. So I can't really claim to like it too much. Well, then prepare yourself because tonight we're going to discuss the command repository and mediator patterns i'm kind of excited about this one yeah who's gonna win um well it's

obviously me i you know i'm not as happy about mine that i picked to talk about so it sounds like alan is super happy about the one he picked. So I feel like that means he's going to win. I don't know. Go ahead. I don't know. I feel pretty good about mine and I'll explain why when we get to it. Very cool.

All right. Well, let's start with the command pattern. Well, are we doing the survey first? No, no, no. We'll hold off on the survey. All right. All right. So Joe, kick us off.

All right. So yeah, the command pattern is the pattern that I picked. It's one that I like a lot and I do pretty often. And if you work with any sort of framework, you're probably doing some sort of variant of it. But the reason I wanted to really kind of look at it is that, at least I think, it's one of the hardest to read. Not necessarily the code, but just trying to read a description of what this command pattern does is just brutal.

I went to so many websites, I looked in a couple books that I had, and all of them were like, well, the command is a command that the invoker invokes when the requester requests the invoke. Oh. I'm like, what? Yeah, I mean, that sounds like instructions by Dr. Seuss. Yeah, it was really awful. And I almost got a bunch of sentences and kind of aggregated them together,

but then I realized how horrible and frustrating that would be to listen to. So I decided to spare you guys. But yeah, I did want to kind of read just the formal, by the book, Gang of Four definition first, and it's terrible. And I apologize, and we're going to try and give some examples that make you realize just how you've already been doing this but the official definition is that the command pattern encapsulates a request as an object thereby letting you parameterize clients with different requests queue or log requests and support undo.

Got it? Yeah, that didn't. Yeah, sure. Yeah. So in your code and a very like, you know, typey typey layer, it's the difference between saying, you know, method parentheses or new object. And somewhere later on the line, you say, my object dot invoke, or execute, or do your thing, or method parentheses. And this has some really nice

advantages. Like, as we mentioned in the definition, you can queue these requests, because what we've done is we've, as the definition says, we've encapsulated a request as an object. So we've got a code, like object-oriented object, an instance that represents a task that needs to be done. And so when we start saying words like... Wait a minute.

Go ahead. You're losing me here. Because when you talk about like... When you say... Especially when you just said like when you say especially when you just said task i couldn't help but think of like the task uh you know objects within dot net for example right boom command pattern oh really i was gonna say that's not what you meant but that is what you meant that is what i meant and also actions in dot net okay you know

actions and funks those are also pretty good examples of command patterns you know it's they're all little you know very here and there pros and cons uh tweaked a bit for their specific tasks but yeah that's basically it like you know the task in dot net you create an object that does a thing and then you don't you don't start executing you know it's not procedural right as soon as you create the task it doesn't run off and do it you create the task and then you say async programming then is a really good way to visualize what the command pattern does then right yep like a promise might be another example in javascript then yeah absolutely now that one's i'm starting to dip out a little bit because there's not there's not an object behind that right it's an anonymous function so the net you know we we

have to gray up our definition a little bit if we're going to accept that okay well i was just trying to think of ways to like visualize like if you're listening to this description right like how can you visualize because at first i was getting kind of lost with some of the things that you were saying and and then you know but now it's starting to come back together yeah and um also you know if you think of classic ASP pages or if you've done any Windows development, you'll have a button and then you'll have a method called button on click

and you can attach events to it and whatnot. And those are all examples of the command pattern. These are things where we've got an action that's separated from the thing that happens. Does that feel good? Yeah, I'm still taking all that in. Yeah, I thought so. So I think the easiest way to describe this is really through examples.

So I've got a list here of real-world applications when you've done this. And the first thing we've kind of mentioned a little bit with the ASP example, but GUIs, graphical user interfaces and menus, things like that. My favorite example is Photoshop. Photoshop has commands like copy, paste, invert colors, flip horizontally, right? Well, and going back to your ability to support undo,

specifically as it relates to the Photoshop example, you can see your history of commands and actually step back through them in Photoshop, right? And the way that undo works so well is because you've centralized that logic. And so you've got basically one kind of... I forget what they call it. I don't even want to say what they call it because it's horrible, but not that I have anything better to call it.

But you basically got one coordinator that is responsible for kind of kicking these things off. And each thing is its own separate class. So you're going to have a copy class. You're going to have a copy class, you're going to have a paste class. And that copy class knows how to get something from the view and copy it to the clipboard base knows how to get out of the clipboard and put it back when and then when you implement the and that would be in the we'll call it the execute method. So you say, copy command execute, it grabs the thing from the view throws it into the clipboard. The undo would be the opposite, right?

It takes it out of the clipboard and it puts it back in the view. I guess what's tripping me up though is like, well, for one, you know, some of your examples, you know, you were talking about have kind of like stepped on some things that I was going to say as examples in my own, but then, um, bless you. And, um, but then, bless you and um but then oh shoot well i just forgot what you said um oh it was about the state though and the ability undo i felt like there was another one like um the well actually the memento pattern because about dealing with state because the command

pattern is only allowing you um like all the information to to perform an action is included, is encapsulated in that command. Right. But nothing about state is. And that's what the memento pattern buys you is the state. If I remember correctly. Yeah, the memento actually keeps the whole state of the whatever's being changed in case it needs to say roll back or something. So it's a difference between a roll back

and like a true undo. Right, because this is different objects, right? So the whole point of this command thing though, so what you're talking about is you have something that keeps track of its state over time. This could be any number of different objects but the whole point is that whole object is is the parameter that's passed in and then that way you could add it on to a stack or some sort of queue or anything like that so you could always go back

and it's not necessarily i guess what i'm saying is the command though is just like here's the action i want you to do but it has nothing to do with the state. But yet one of the things that in the definition, I think it was part of the definition that Joe read or you mentioned was that part of its thing is to support undo. But I guess my point that I'm making is that the command pattern by itself doesn't support undo. You need something else with it like a memento pattern, right? In order to support that feature, because the command pattern itself isn't enforcing the state, the ability to like walk backwards in the state. It's just like, here's the actions to perform, right? Well, here's the deal.

The command pattern doesn't have a state. Right. So like an example with the Photoshop thing with the memento is you would say you know cut copy paste whatever it would actually keep a snapshot of the entire state meaning it would keep the view it would also keep a snapshot of what's in your clipboard maybe even what's on disk you know it's the snapshot of the entire environment i guess what i was taking issue there was more of the definition that that you gave where it was like you know supporting undo because that's where i feel like that feel that felt more like a memento thing than a command pattern thing yeah and i guess i should say that um when i say

it supports undo i literally mean it makes undoes easier it doesn't actually give you that for free it's nothing that um you know that you get inherently because of the pattern it's just probably the most common way of doing undoes okay Okay. Which is to literally say I have an object that has like an execute method and undo method. And the undo method knows how to do exactly the opposite of the execute. But that's up to me to program that correctly. And if you've ever undone too fast in Visual Studio, you know that it doesn't always work perfectly when you try to step it back forward. But then you also mentioned that it was like the observer pattern. And specifically, you gave the option of the buttons, though.

But that was another one. Well, no, you said that it was not like the observer pattern. You said that it was used buttons as an example of illustrating the observer pattern you said that it it was uh you know used buttons as an example of illustrating the command pattern but um one of the patterns i thought that was more like was the observer pattern they're very similar um they're both behavioral patterns and the observer pattern is really good at like say you know pub sub type stuff like let me attach this event to this button and you're you're right it's absolutely kind of a competitor to the command pattern. And it would probably use a little bit of both in whatever you're doing, but they're very much in the same neighborhood.

Right. Yeah. Interesting. Yep. And, um, because of the kind of levels of distraction, uh, in place here, it actually makes it really easy to remap things in such a way that you would also do with the observer. It's like if you're playing a video game and you've got a controller with four buttons on it and you hit the B button, for example, you don't want to say, you know, if B then jump, you want to be able to say, if B do the B thing, right, that you've configured and it's maybe different for scope. So if you're looking at a menu, maybe B selects. If you're playing the game,

maybe B jumps. If you're driving a car, maybe B accelerates. So it provides some layers of instruction that make that thing easy and it makes it just easy to kind of configure that stuff. And so we're getting that stuff out of code

and making it more declarative. So like what you were saying though is, I mean, just to kind of draw it out a little bit more clearly for a podcast. So like what you were saying though, is I mean, just to kind of draw it out a little bit more clearly for a podcast. So like what you were saying, if B you wouldn't say if B then jump, because that's very much tied to whatever it is. You're just saying, Hey, whatever came in, call B dot execute or B dot invoke. And then, and so if B happened to be something that was going to be a jump, when you call execute, it would do the jump because it would know about it itself.

If you hit C, you're not going to say C.accelerate. You're going to say C.execute or C.invoke, whatever that method is, and then it will know that it needs to accelerate. So the whole idea is whatever object is passed in will have the same execute command, and then it knows what to do with itself at that point yeah and that only works because we've got a common interface between those commands it's always got to be like invoke no parentheses or some sort of minimum parentheses and it's got

to be something that is um interchangeable you meant no parameters right right? Yes. Okay. Not no parentheses. Oh, yeah. Sorry. It's almost like I was trying to, as you were describing that, Alan, I was thinking of, I don't know, something about what you said made me just think like, hey, does that mean that every keystroke could be a command pattern? Totally. Right? It really could, depending on the application, right?

Well, depending on the context of what you're doing within an application maybe you're typing it or maybe it's a command yeah totally i mean it's a it's a pretty neat thing if you think about it i mean i don't know how ide's do it i've never actually tried to program anything for an ide but you could think if you had shortcuts right to where if you did a shortcut it would know what to do itself right it could just be an object that has this execute method and then knows to go off and do something i don't know if that's how it happens but not normally right i mean like i think so like regardless i mean normally you have like an event loop and you're listening for right you know the event but i but in a game it would totally make

sense like what joe's saying in a game it's real easy because you kind of boxed in right and you know that you'd still have like a some kind of a run loop though right listening for the events i mean not that i've done a lot of game development but you know maybe you could but maybe the instead of the event just taking in a key it takes in an object right like a command object and then that thing doesn't execute whenever that happens so i don't know but here's a good example right like you're in windows or probably anywhere you right click on something if you have uh two mouse buttons and you see a window a window pop down that lets you open it or do this do that right probably if you've been on that computer for any amount of time you've got some stuff installed that can do some special actions like back this file up or, you know, unzip or whatever. And all of those

things are examples of commands because your, you know, Windows Explorer doesn't know what Carbonite needs to do to back up a property. It doesn't know what WinZip needs to do. It just knows, hey, whatever you pop in here, I'm going to give you a file or a list of files and tell you to do it. And, you know, whatever happens afterwards, I'm out of it. You know, that's a good point. I wonder, like on Android, one of the things I love about Android personally is if you're in an app and there are shared features of other apps, like what you're talking about right there, like if you go to share something from, you know, maybe your photo, and it gives you a whole list of things that you can share to when you click that, that thing knows what it needs to do. So I wouldn't be surprised if that is some sort of

type of command pattern, right? Like if you click on hangouts, it knows that it's going to pop it up and, and drop it into hangouts. Whereas if you did Dropbox, it's going to know that it needs to run some other method. So it's probably calling like an execute type thing on each one of those. That makes sense. Yeah, and if you think about Slack bots, those are really popular right now

if you wanted to make one. Basically, they give you some sort of interface that you need to pop in there. So if you're writing a Slack bot that pastes the picture when you type a command, then your input is going to be that command that's typed, maybe whatever arguments afterwards, but you, it's up to you to take that, um, that information in a, you know, a reliable format and do something with it. So

the, uh, the command line doesn't know the specifics of your class of your library, what you're doing. All it knows is, Hey, I give this guy this word and I'm out. Right. Yeah. I mean, that's pretty cool. Uh, with that, going back to your undo thing, it not being a feature. So this code samples I've seen that, that go along with what you're talking about is if you were to do like an execute on like a copy and paste or, or, or, you know, maybe some other feature, the whole undo thing is really because it is just an object coming in that has the interface that you're talking about, like execute, right? Like that's really the only thing. The cool part is really the reason why it enables

something like an undo or redo is because, because it is an, an object that it can see, all you do is just keep adding it to a list right and then that way if you want to undo you can just go back through your list and take care of it because they're all of a certain command type and that's why it makes it easier well that's where that's where i take issue with it though because because that's where the memento pattern will come in because let's say let's say i give you a command that's that's um add to whatever your current state is add to and then i give you that command three times right like it's not you know you okay fine you have that command add to but you're not going to know like oh well just flip it to a subtract you know let me just subtract two instead you're

going to roll through your your state and go okay well you want to roll back x number of commands then that's this is the state at that command right i think that's a good good way to exemplify the difference right the command pattern you would say add to add to add to undo it would subtract to subtract to subtract to with the memento pattern you would do add to add to add to undo it would say last result was four. And you do undo again and say last result was two. It would be totally ignorant of the operations that took to get there. And that would probably be actually a superior pattern for a calculator.

But it just accomplishes the same thing in a different way. Yeah, the memento pattern is the state of an object. With the command pattern, you have many objects that don't necessarily have a state. But they're not state, though. Right, that's why they're just command they're just things to do and that's what i'm saying like you're not necessarily going to know the the opposite of them just because of the command no what's it right right if i say if i say like open this file or open this link you don't know like okay well undo that well does that mean close the browser does that mean close the tab does that mean close the tab

like you know what's the opposite of open the link right you wouldn't really necessarily have that in a memento either not you wouldn't be able to reverse it right but you could go back to the previous state so that's what memento would be memento would be going back to the previous state right so the command would literally be popping them off the stack essentially is what it boils down to you wouldn't you probably like you said well where i could see like here here's here's an interesting use case for the the command pattern that i could see and tell me if you thought about this one joe but i know we've talked about this feature in visual studio where if you're debugging something in

visual studio right and you're you know just f10ing your way along it right stepping over lines and there's that little yellow arrow off on the left and you're like oh10ing your way along it, stepping over lines, and there's that little yellow arrow off on the left, and you're like, oh, crap, I wanted to go back up and see this method from the beginning. You can just drag that little arrow all the way back up and then start redoing it, right? Yeah, that's ridiculous. No, but I'm thinking about in terms of,

well, what does that mean in terms of mediator? If we're making the comparison back to a mediator, not mediator, memento and command pattern right i don't know how that i mean i'm not i'm not saying that's exactly how they implemented it but i'm just kind of like visualizing that right is like you know the the you have all these commands if each one of those lines of code is a command right that as you're stepping over your code in the debugger right and then you step back right that that those list of commands are allowing because you have each of those lists of commands you can go back right again this is a visual uh you know analogy not an actual implementation analogy yeah i think that probably would be the case um that they would use commands here

rather than memento or any other way of doing it and i would imagine it is kind of thing exactly where they kind of step it back and um you know the the operation knows what it needs to to step it back which is in most cases for the debugger i would think it would just be resetting variables because you know we can't undo network calls or file system stuff like that right so literally you're just kind of going back in time for the debugger, I would think it would just be resetting variables because, you know, we can't undo network calls or file system, stuff like that. So literally, you're just kind of going back in time for the state of those variables and any sort of network operations,

whatever, you're just going to get replayed. Well, I feel like we beat up the command pattern. Yeah. Well, I did want to talk about one more thing. Sure. I wanted to talk about how it was implemented. Are you going to Steve Jobs this thing

with like one more thing? Yeah, I mean, talk about um this and poorly for a long time okay but i did want to talk about the by the book um definition and i encourage everyone to go out there and actually try to program this one by the book because it's really confusing but i think it's informative also uh and so after i did it i was like you know what there there's got to be a better explanation of how to how how this is supposed to work there's basically four objects kind of five if you kind of interface depending on your language and they're terribly named right and i yeah it's just tough but you should look at it anyway but i did find one great example on

do factory.com which has an interesting looking book on design patterns I haven't read, but you should check it out anyway. And what it did is it compared these four different objects to roles in a restaurant scenario. And so I wanted to go over that really quickly and just to give you a glimpse of what of how the book describes them we've got a client a receiver a command an invoker and rather than trying to tell you what each one of those does in like the you know the codey sense i'd rather compare it to a restaurant okay so in this case the client is the customer you walk into a restaurant you want to get some food right okay a waiter comes up to your table that's the receiver asks you what you would like they're responsible for creating that ticket or that order adding all the items that you want

and then taking them back to the cook now the client the customer doesn't know where the chicken came from it doesn't know if it's you know fried or grilled or you know maybe they do microwaved right they don't know the order of operations that it takes to to make that food neither does the waiter the waiter just knows how to communicate with the cook via this order and that order is really the key here it's what represents the command it's a data representation of what needs to happen and so when the cook sees fried chicken he he knows to go to you know get the chicken batter it drop it in the fryer etc etc okay do you like that analogy okay so the order that as the waiter takes down the order if you hope he writes it down then that is the command object right

all right i like that analogy i can i can follow that yep well thank you jo. I'm now hungry. So if we can take a break for dinner time, we'll be back. No, I'm just kidding. Hey, wait a second. I'm curious, though, because I looked on DoFactory, and it's not that example you were talking about. So did you make up the… I definitely did not.

Let me see here do factory did you look on do factory.com or the actual link i had the link that you had it may have been elsewhere on the site yeah yeah all right so way to call him out though alan no i mean i was trying to follow along and i was like man i'm totally missing the boat that's why oh yeah i think that that was not do factory.comcom. Let me see here. Yeah. I was literally trying to follow along, and I was like, I do not see a waiter. Man, Joe, your show notes suck. I know.

I shouldn't have picked one that was so hard to describe. Because as I was reading it, I was like, this is the pattern that everyone does all the time, and no one can explain. No, I think we got around to it. I think it makes sense now. Yeah. No, I think it was a really good explanation. Yeah.

This episode is sponsored by Dev Bootcamp. Thinking about becoming a software developer? Check out Dev Bootcamp, the original short-term immersive software development program that transforms those new to coding into job-ready, full-stack web developers. Learn front- and back-end web development, teamwork, and leadership skills in a rigorous and inclusive environment. DevBootCamp has several locations around the country and is accepting applications now.

Visit devbootcamp.com slash codingblocks to learn more. All right, so now let's get into one of my favorite parts of the show which is the survey so now please tell me you guys didn't cheat because you guys especially oh it's 26 that's not cheating i read those reviews like weeks ago all right so i'm still going to say it's cheating all right so our poll last uh i would say week but really i mean episode was on uh bash on windows right do you remember this one bash on windows it's coming right and your choices were the next big awesome or much ado about nothing because there was a they were both written as questions yeah you could definitely tell i uh The next big awesome or much ado about nothing?

Because they were both written as questions. Yeah, you can definitely tell I came up with those labels. So I'll start with... Actually, I think I started with Alan last time. So I'm going to start with Joe this time. Joe, give me a number. Which one you think was the winner and what number percent you think it was? I think that programmers are inherently, let's go pessimistic. And I'm going to say the next big nothing with 37%.

You combined them. so wait a minute you're saying you're saying you think much ado about nothing was the the winner between the two options and it won by 37 yep but that means that the other one according to your math got 63 percent no i think you meant two yeah i think you meant 63% was the other one. Oh, there were only two options. I thought there were three. There was only two options. Oh, okay. So our math is not good.

So you think Much Ado About Nothing was the winner, but by how far of a margin? Not a huge one. So I'll say 55% in that case. Oh, okay, 55. All right, Alan. So I think because the way that our description is set up for our show, a lot of the people that joined initially or started listening were.NET developers. Okay, that sounds logical. So I'm going to say that most.NET developers hate command line.

All right. And so I'm going to go with the much ado about nothing, and I'm going to say that it was 60%. I'm sorry, did you say 6-0 or 1-6? 6-0. Okay, 60. Okay. Yep.

Well, you're both wrong. Really? Wow. Apparently.NET developers love their command line wow because the next big awesome was the big winner at 74 whoa wow that's shocking which yeah i i did not expect that to happen at all because i was more in the like i mean i'm like bored with it i like it if there was a meh like option that's totally the one that i would have gone with really well i did vote for next big awesome uh because i'm more

curious until it comes out i don't know if i want to be excited about it and this is one of the things that we talked about last time was okay what does bash on windows mean because everything that i love about bash is all of the other commands and that's not bash those are just commands on the unix file system like we mentioned tail as an example right right that's not it's not like that it's not like bash is a protocol like tcpip is right it's just a command shell so what does what does it mean to have bash on windows and until i see what that means then i can't be excited about it well i did listen to another podcast i have no idea which one it was and one of the guys was using it like quite heavily because he wanted to see what it was about and he said it was almost like being in a linux linux environment if you

wanted something it was like app get whatever and then and then you ran it so but it's all but it's still all the windows commands but in a bash shell yeah right probably so and that's what i was describing is that like what excites me about it is not the windows commands in a bash shell i want to be able to do things like ls and and tail because i hate that stupid content they were using ls well ls is already like a power shell one where it's like alias though it's an alias right it's not a it's not a a equal alias though so all the switches for ls on linux don't apply to LS on Windows. They will now under Bash.

So that's kind of my take, right? See, that's the thing I don't agree with. If anything, I would say the reason why it's exciting is anybody who deals with multiple different types of OSs, at least it will bring some commonality, right? Like you'll have the same commands. See, that's the part I'm taking an issue with. I issue with i don't agree with that well we'll see but i i'm actually i would be in the 75 camp but i'm shocked that it was that high honestly yep same yeah all right well fine i'm i'm the odd man out then in the meh class um but i heard that joe has another survey for us yep and uh i was really curious what kinds of development you guys prefer do you prefer doing mainly front end type stuff do you prefer

doing back end servery stuff or do you prefer doing the whole thing full stack well now you know you you classified back end as servery but you know according to some definitions back end would be database middle would be server um yeah but i mean i've never seen middle end jobs. Middleware. I think middleware is being a whole different sort of thing. I agree with you, but I just wanted to make that distinction because for some, it's definitely when you say back end, they're thinking SQL. Yeah. That one's kind of tough. Maybe we should augment a little bit because there's definitely front end.

People know what that is. Server side or back end right or full stack right so maybe those those four options yeah when i say front end i mean you're doing javascript html css uh wpf you're doing guis you're doing user facing your pound human facing you're gonna bang important everything to make it work it's like do you like working mainly um for with people with other computers or do you like a mix yeah i know what i am but we shouldn't give ours this one right we'll do that on the next oh okay i mean yeah we won't lead anybody all right all right so now it's my turn the repository pattern this is not in the gang of four book

and this is why i'm excited about it i think it's the first time we've we've dived into the depths of something outside that book nope um there was the hollywood pattern and the null object null objects not in there nope oh i'm wrong so i shouldn't be this excited about it but i am anyways all right take it down a notch so gotcha here we go so the repository pattern uh this one's kind of i like this one because it's the whole separation of concerns with databases and regular code and all that and that's where this gets into it so let's get into the whys or maybe first first yeah we'll get into the whys let's start with a definition so i don't think i got a definition isn't that awesome or not sorry is it, I guess, is more of the definition.

So it sits between the data source and the business layer. So the data source could be a database itself. It could be something like SharePoint that can give you a list of data, whatever, wherever you're getting your data from. And then it sits in between that and the business layer. So anytime you get the data and you need to do something with it before, you know, you spit it out to the user or consume it or whatever, this is where this thing sits. It maps data from the data source to an entity.

So one of the things that you'll typically see in.net anyways, is you'll see the repository pattern mentioned in line with like entity framework. And the reason being is because entity framework gives you these business entities, right? If you have a user object or something like that, it doesn't have to be entity framework. The key point is you're mapping from a class to the data. That's really what it boils down to. And the, this, uh, this repository pattern, it also persists changes from the entity back to the data source. So you get an entity out of a repository, you make some changes to it, then you pass it back

to the repository and it knows how to save that data or persist it on. There are a ton of other patterns that come into play here. One of the ones that is kind of interesting is you can use the unit of work pattern for complex multi-step is you can use the unit of work pattern for complex multi-step operations. And what the unit of work thing is, if you think about like in a simple e-commerce application, you, you basically have a bunch of, or items that people decided they wanted to order. They place their order on the site. Well, typically what you have is you're going to create a record.

If we're talking about a database, you're going to create an order record. After you create that order record, you now need to take that order ID that was generated and put all these order items on that same thing. And so that's a multi-step operation. You first create the order record, then you're going to create all the order item records. And so a unit of work allows you to do that. So if you had something that was like create order, it would know how to take that data and push it in. Another thing that it can use is what's called the data mapper pattern. This is basically what an entity framework or even like a dapper kind of does. So you take an ORM and it will auto map the data that came from whatever the data source was into these

entities these class objects that you have so that's what it is now what doesn't matter as much as why so there's a couple of things that are really cool about this so the first one is it's testable with an isolated data layer say what woo yeah I! Yeah, I mean, that's cool. And what that actually means is, why is this testable? Why is this any different than anything else you do? So in a lot of cases, or in a lot of applications, you've probably seen, like, you know, the web API might be talking directly to the database.

You can't test that. Like, that's very difficult to test, because you have no interfaces. You have nothing that you can substitute in and out of with this think of think of like you have a repository and it and it has an interface called iRepository and in most of these repositories when you see these generic repositories you'll have you'll have basic CRUD type operations like create, update, delete, or get. And then you might also have find by ID, find by name. Like these might be some of the ones that are all there.

Well, if you have an interface that has those things, you can swap in and out mocks of those if you want. And so those are easily testable. Another why is centrally managed access to rules and logic so if if you think about it in terms of if you've and we've all done it if you have some methods that go get an order and they do some things to an order that's the only place that knows about it right and then inevitably you'll see down the road somebody else goes and gets some things from the order and does the same type things to that order.

And you're like, but wait a second. I already wrote that code over here. But because people weren't aware of those multiple classes, that logic is not centralized. When you put this kind of thing in a repository, you now have one place to go, and that's all managed. Okay. So, sorry. I got to interject for a moment. Yes.

And not as a bad way. But for one, you mentioned something about Entity Framework, and I wanted to make sure that you weren't suggesting that the Entity Framework itself was a repository pattern. No, I actually specified that it is typically used in conjunction. If you hear repository. That's what I wanted to make sure that you said. Okay. So entity framework would be more of the thing that talks directly to your

data source. Okay. Right. And then the repository would leverage entity framework to get the data across. Right. That's typically how you would do something like that. Gotcha.

But yeah, the centrally managed thing, that's really nice because you know that if you go to your repository and you get some things, you know that it's treated the same for everybody that gets it. And anybody that's getting data would typically point to your repository. Okay. So let's describe a visual then. So you mentioned orders as an example so if you were going to do a order repository

right then um this is where the testability the promoting testability is going to come into play because you're going to first define a repository for that order so maybe something like i order repository yep and then you'll have methods that you're going to define that'll be like for that order. So maybe something like I order repository. Yep. And then you'll have methods that you're going to define. That'll be like, um, you know,

get by order ID, get by user, uh, things like that. Right. And, and all of those different methods in that interface are going to be part of that repository.

Then you're going to implement the actual, uh, an implementation of that interface. So, you know, going to implement the actual, uh, an implementation of that interface. So, you know, some class order repository that implements I order repository, and it'll implement each one of those methods. And so in your, um, you know, using your entity framework example, then in your, um, get by order ID method, that's where it will be the guy that actually uses DB context to get to it. So the data source, which is the DB context, is a layer of abstraction away from the caller. They aren't directly working with DB context.

They're going through the repository to get that and so any methods like get order or create order or save order or delete order anything like that are that order repository class is going to be the one that specifies what you know uh like db context that you're going to have to do right and if you needed to swap out your entity framework with something else then you're only having to touch the repository objects assuming that all your pocos stayed the same yep or pojos if you're in java then then um you know you're only changing those repository classes for the actual implementation of what the underlying data source implementation is, right? Absolutely correct. Yep.

And because it was all interface-driven, then that's where your promoting testability comes in because you can easily mock the interface in your unit tests. Absolutely. Which should really make Joe happy. Yep. I do like that and for anybody who's i think we've said this many times on the podcast if you've heard poco or pojo all that means is plain old java object or plain old c sharp object so just just for anybody that has no idea what we're talking about and for the historians out there i'm pretty certain that it started pojo first i would think so right so no poco man plain old c objects there's no such thing as a plain old

c object c plus plus object could have been then no um it started out as a it started out as a job term pojo first and then and then the dot net world borrowed it so no man small talk it was the posto what a poster it's kind of like a post it pretty soon. Pascal's going to come in and it's the popo, the popo, the popos here, you know? So, so going to that, like, that's one of the interesting points that I do want to, I do want to talk about this for a second. So one of the things that is sold about using like the repository pattern, which I think it was something that Microsoft introduced, like I think they coined the repository pattern. I know Martin Fowler talks about it, but here's the here's the thing about it.

Are you really ever going to swap out entity framework for something else? Maybe, probably not. Right. But the thing is, you could because you have that extra layer. So that's one thing. Now, to go in a little bit further, and what's her name? Julie Lehrman on Pluralsight. Fantastic courses on Entity Framework.

She even goes into, like, one of the things that we love about Entity Framework, and correct me if I'm wrong, is the link to SQL syntax, right? Like, you can basically say.where something and it'll write your SQL for you and go get you a bunch of Entity objects back, right? That's one of the things that we love about it. One of the things that they suggest if you're doing the repository pattern is you do not allow that pass-through of queries or iQueryables. No direct usage of link. Of entity, because at that point, you are now tightly coupling yourself to the technology that your repository is using behind the scenes, right?

So you're not actually passing through your iQueryable objects. So just something to be aware of. It's not saying that you can't. I mean, if it's something that you feel like you want to do because it adds a lot of value to what you're doing, fine, whatever, everybody can choose their own path. But strictly speaking, it kind of breaks that whole rule of having that layer of abstraction.

So one thing I'm trying to kind of think of now if you guys will agree with this definition if we think of a repository as representing a collection of entities and it lets my code deal with the repository as if it were a collection of objects rather than rows in a database i don't agree, because the repository doesn't have to be a collection at all, but it just has to provide methods to where you might get back a collection. Of entities. It's the ability to interact by getting or setting information on entities. It's like a layer of abstraction away from whatever your actual data source is.

The repository pattern is encapsulating that so that your caller doesn't have to know what the actual source is. It's translating that into my POCOs or POJOs. Yes, and usually it's not even just a POCO. It's probably a smarter business object in many cases. So it could be a Poco or a Pogo, which literally means that it's just a dumb object that gets mapped to, right? But it could be a smarter entity. It doesn't really matter.

It's just the fact that it can get and set those things for you. Okay. So how about if I'm working with JavaScriptcript could i have a repository that say represents the dom you're talking about going in the direction that's that's i can query it and i want to get back objects so the only difference would be so if you think about it and this kind of goes back a little bit and rewinding on what outlaw said a minute ago like he said you might have you know your order repository which would be which would have something like get order by id and get by user so a little correction on that

if you're truly following the the repository pattern you'll have something like i repository which would have some very generic things like get by ID, get by name, right? So then your order repository, instead of having get by order ID, it would actually just override get by ID, right? And some of those others. Okay. It might have its own specific things. So you might have like a more generic interface that defines things like, you know, get, create,

save, like all your CRUD operations. Yep. For those that aren't familiar with CRUD, that would be, you know, create, like all your crud operations yep for those that aren't familiar with crud that would be you know create read update delete yep so then going to your dom example the only way that i see that would potentially work is if you truly had some sort of like talking about react or something where you have a shadow dom right if you did something like that then really what you'd be saying is you have like you know a handful of methods that are used to interact with it basically getting out getting data back from the dom and pushing it back to it right so you could totally do it i don't know how

i do do it huh all the time i do i do do it too much i was just thinking with the chess game right i've got dependencies on jquery and like every file because i reached my nasty little fingers into the dom from all of my classes like well wondering like maybe if i had an object that represented jquery represented the dom and then i could query it by id or by you know element type stuff like that and i get these objects back that can do things like set value set html get value um these you know kind of poco-ish or data type things that i both read and set and it abstracts away the saving of that to the dom all i know is i say hey get me the table and fill it in and that kind of stuff happens on the dom then it's kind of if i abstract that out and to its

own layer that could kind of be an example of the repository pattern. I think if you are using entities that are actually what's interacting with the DOM. So let's say for instance, it was an order, right? If you had an order that you push the repository and then it wrote it to the DOM, or if you were trying to get things out of the DOM and convert them back into orders, then maybe that's something, right? Like the real, I think the real meat behind it is you were getting business entities out

of whatever data and pushing it back in. Okay, so if I'm setting the HTML, then I'm starting to speak the language of my, you know, repository, I'm breaking that rule there. So it's not a clean abstraction. Yeah, it's more about like model data to an entity and an entity back to model data i think is really what it boils down to okay interesting so now i'm trying to figure out if i could do with handlebars so rather than like setting the html or anything like that i just kind of pass the data and somehow it gets mapped to a template somewhere along the way.

I feel like you're trying to force MVVM into the repository pattern. Yeah, this is the next big thing, man. This is going to be the next big JavaScript pattern. Oh, God. This is going to be the next big framework, repo.js. It's not a big thing

until you come up with a good name for it, though. That's right. Repo like repo, man. Repo's pretty decent pretty decent oh someone's already got repo.js all right so let's uh so going back into this the whole um where did i leave off here so central oh i didn't even get to this one so another thing that's really nice is you can have a centralized caching strategy right if you have one place where all your data is being, you know, funneled through, you can now cash more effectively in one spot, as opposed to trying to cherry pick all over your

application where you feel it's necessary. Another thing, it does allow you to separate your business logic from your data access logic. And by data access logic, that could be things like, is this guy authorized to even get this data, right? Or, you know, what amount of this data can come back and that can get into domain driven design, which is way outside the scope of this, but it's another thing that is typically talked about with repository stuff. But what's that look there, Joe? Oh, man, I'm sorry. i didn't mean to distract i was trying to search for you know repository names for javascript and google auto corrected to suppository i didn't know what that was but i do now and you looked at the images that's oh my god

um the other thing that is which we've already hinted at, is you get strongly typed entities. So whether it's a Poco or a Pojo or whether it is a smarter business object, you have strongly typed data, right? Like it's not just some data that came back out of a stored product that you're trying to convert into strings and numbers and that kind of stuff, right? You actually have something that got mapped to a real entity that you'll be able to use. You also, and this is why entity framework is a lot of times used in conjunction with it, you have business entity associations. So if you have an order, you also know that order details belong to an order. So you can typically navigate that graph of objects with that. You can apply a domain model to simplify the business logic. I mentioned it a second ago with domain driven design.

That basically means you just, you kind of think about your app and, you know, who is using this portion? Is it a customer service department? Is it an accounting department? Is it whatever like accounting doesn't necessarily need to see all the order detail that is assigned to an order but customer service would so when you start thinking about apps in that in that realm you start breaking it down a little bit different is it just me joe or do you feel like i mean between the three of us right one of us is a data guy and do you feel like this pattern like someone picked this pattern on purpose because it really fits them like one of us is a back-end developer right one of us some of us are full stack but one of us is not like the others you know what's really ironic about that

so i love data but i spend 70 to 80 percent of my time on the ui you know i i don't know why but yeah i mean i totally love this because like i'm looking he's like a giddy like a little school girl over here as he's talking about this repository pattern yeah but go ahead oh i was thinking this is starting to sound a little graphy like maybe this is kind of leading into some other things you've been interested in lately this might be so the i haven't even told you it was like entity framework oh man i haven't gone all the way yet but but i'm dipping my toe in here but here's one of the i haven't gotten to the way yet, but I'm dipping my toe in here. But here's one of the – I haven't gotten to why this is really exciting to me. The last why, real quick, is it also decouples your business entity from data storage technology, which is awesome.

Because any time that you have your order object and it's talking to a stored proc directly, that thing is bound to it. And any time you screw anything up with a stored proc, you've jacked everything, right? And you can't test it. I can change that, though. What if you want to have your data to be able to be read from multiple sources? So you want to be able to read it from an XML file or from a database. So you might have multiple sources that's coming from

and using making it interface driven allows you to swap those out oh it's as needed i mean it's amazing like if you think if you were to expand upon what you're saying right there if you had get order and let's say that you had an oracle database sitting over here and you had you know some sort of web api call over here that you that you wanted an Oracle database sitting over here and you had, you know, some sort of web API call over here that you, that you wanted to basically union those two sets of data together. You could easily do that with a repository, right? Well,

I was thinking of an example where, you know, in based on your interface, you might have, uh, you know, something like, uh,

you know, I'm trying to think of like a good example for this. Have you ever seen those interfaces where it's like, you know, they, they, it might be like a tab UI and a browser interface, right? And it's like, Hey, you can, you can share, give a link to an image and we'll use that. Or you could, you know, type up your message here or, you know, on this tab or on another tab, you can use something else as the source, but But any one of those three options that you pick, and then you click the action button, and then it goes away with it. And it doesn't matter which one you picked, right? They're all going to interact the same.

It's going to treat them all the same. And that's where I'm kind of thinking about it. And you know that what you get back is going to be a business object that you can use. But here's why I got excited. Um, is we've taught, I think I use this as a tip a while back. There is the, what is it called? I think it's the generic unit of work repository pattern. It's, it's an extremely short name. Yeah. Generic unit of work and repositories dot complex.com. So the thing that's really cool about this is this guy took the time to bring it all together so entity framework with the unit of work with

a repository pattern you can literally have a super clean set of abstractions to where entity framework is providing your business entities The generic unit of work pattern is used so that you can string together operations that need to happen one after the other. And your repository pattern is there to basically just give you the easy get this, set this, update this, delete this. And it is a super clean way to have APIs on top of your data. Huh. I found a really good one because you mentioned it on oh wait you said codeplex though so the yeah it's weird um i i thought that they would have updated because i thought codeplex went away but it's generic unit of work and repositories.codeplex.com unless they Well, I'll give you another one that's really good, too, a really good source to see some code examples in action,

and that's from Code Project. And they have an article called Repository Pattern Done Right. And it's simple enough to where you see it and you're like, oh, okay, I get it now. Right. And that's the thing. If you ever actually sit down and look through this, it's not complicated, but what it gives you for the amount of effort involved is amazing.

Like it really is good stuff. So that's, that's it, man. I beat it up. All right. Well done. I mean, just add that link in there for us. Very nice. This is a very link heavy episode, by the way, too.

We have a lot down here in the resources so i got the short end of the straw here wait wait you chose it before i chose i did i totally did and i thought that i was going to be all excited about this one and i think this was like there was one episode one of the other design pattern episodes that we did that i remember like joe got all excited about uh the pattern that he was going to be doing until he got to it. And he was upset when he had to describe it. Do you remember that, Joe? Yeah.

Yeah, that's exactly how I feel. So I have the mediator pattern. And the best I can tell is it's crap. So what did you say? Oh, did I not speak loud enough? Hey, wait, wait. Before we get into this, we haven't begged yet. Oh, okay.

We need to beg. We didn't put it in here. Guys, we listed the people who had taken the time to write us reviews in iTunes and Stitcher. And seriously, if you would, if you haven't already, even if you haven't joined our Slack, you know, come join us in Slack and feel the peer pressure that you need to go leave us a review on iTunes or Stitcher. Like we're okay with that. We don't mind peer pressure. So seriously though, I mean, it makes us feel good.

We love seeing them and it really does help us out, get in front of, you know, even more people. And, you know, one day it will force us to record more frequently if we get if we reach some sort of critical mass it's going to happen so um yeah that's it all right i'm done begging all right so um well do you want do you want do you have time for a joke because i said that this was like crap but and that was really i was just kidding the mediator is not crap but it did remind me of a joke if you have time let's do a joke okay so so i can't take credit for this joke this one my uh my 11 year old came up with this one on his

own so first of all before hearing this joke you need to put yourself in the mindset of an 11 year old boy so that you can find this humorous are you ready ready? Let's do it. Can you do it, Joe? Can you do that? Already there. Yeah, I live there. All right. So why did the drug dealer not wipe his butt? Why did the drug dealer? I don't know. Because the toilet paper stuck to his crack last time. That's good.

He came up with that? He came up with that. came up with that all on his own that's not right i don't believe it i'm telling you what he told me man don't don't shoot the messenger here that's awesome so very nice we might have to mark this episode explicit now all right it's borderline so okay so here's the mediator pattern right right? First, let's start with the Wikipedia definition, which is the mediator pattern defines an object that encapsulates how a set of objects interact, right? So the reason why I'm saying this one's not as fun, this one just wasn't as exciting. Like, Alan was definitely into the repository pattern. And after doing some research on this one, it wasn't as there for me. But the idea behind the mediator pattern is to promote loose coupling from the objects

by not allowing other objects to refer to each other explicitly. So I'm going to give you a couple better visualizations later. But for now, let's just say that, you know, think of it, that you have these 10 objects, but all of their communication is handled by an 11th object, right? So that 11th object knows how to talk to each of them, right? And those other 10 objects, they just do their own thing. And whenever they want to talk to one of the other ones, they, they go through the mediator right so it it promotes it

promotes promotes loose coupling that way is that the way they would pronounce it in canada it promotes what's that a boot okay so his name is michael outlaw right i mean with a name like outlaw you knew i was going to be politically correct right so but canadian people aren't going to get offended so it's cool they're all they're all chill they know what we're talking about that's right so um which also means that it promotes the single responsibility principle going back to our episode on solid which man what was that like episode five or something been a little three while. Three. Seven. S7. So it promotes the S in SOLID, the single responsibility principle,

by allowing all of that communication to be offloaded to the mediator, right? And those other 10 classes that I mentioned, they just do their thing, right? Now, here's where it gets confusing because the mediator pattern is in the list of behavioral patterns, much like the observer pattern that we discussed earlier, much like the facade pattern that we discussed earlier. Oh, wait, what did Joe talk about? The command pattern. So that's where this one really started to get confusing because like okay what are the where are the lines here like you know based off of some of the reading that i was doing you know there was gray areas especially between the observer and the facade which are competing patterns which interesting you would say like okay well then that must mean since um uh oh man what's the the

principle there i can't think of it the since the command pattern is competing with the observer pattern then the mediator pattern must be competing competing with the command pattern right but at least i didn't read anything that suggested that i I'm not, you know, it doesn't seem that way to me. And I didn't read anything to suggest that. But it was interesting that they were both competing with the observer pattern. Right? Yeah, it's interesting. But yeah, so they both compete with observer, but you don't hear much about mediator versus command.

Right. So then it was like, okay, well, what's the difference then? Like, what's the difference between the observer pattern and the mediator pattern? So for one, like the mediator pattern could be implemented using the observer pattern, but the, the observer pattern is used to distribute communication between, uh, objects like an observer object in a, in a subject object. Right. uh objects like an observer object in a in a subject object right whereas the man i started to even say the community the meteor and i got lost in my own words like yeah it's so hard to

talk about design patterns the mediator pattern like trying to describe its difference is is challenging so here's here's what i found and because I was getting a little confused too. So the observer pattern, it's basically all type of event type stuff, right? So when one object changes, all the dependents are notified, right, and updated. The difference between, so that's the observer. The mediator is when something happens, the mediator knows how to go do things to the other. So it's not notifying the other objects. It can go do things to those objects. So that seems to be the difference is the observer notifies everything that is a dependent.

The mediator knows how to do things to the other ones. Well, you're thinking of, you're kind of making the analogy of the observer then in like a PubSub type scenario. Very similar. Right? Yep. And the mediator object would encapsulate all the communication, right? Yep. But from everything that I found, there's nothing to say that you couldn't say, hey, tell the other guy, right?

Because – and here's the problem with the mediator, though, is that, like, if you go looking around for, like, good concrete code examples, they're crap, right? Because, like, one of the most prevalent examples to describe the mediator pattern, which, like, to visualize it in your head, this works as an example, but I didn't like it.

It wasn't my favorite way to visualize it. And that, this works as an example, but I didn't like it. It wasn't my favorite way to visualize it. And that was a chat room. Because if you thought of, you know, I'm in, I'm chatting with Alan, right? So there's me, some server and Alan, but I'm not peer to peer talking to Alan. We're going through some server, right? So in that case, the server is kind of like the mediator between he and I. I'm saying like, hey, I want to send this message, right? So I type the message up, and then that server then sends that message off to Alan. Now, that's the old school way of chat rooms. Nowadays, you know, there are more peer-to-peer type solutions out there but the reason why i say that example is crap though

again going back to the drug dealer is that um you know you wouldn't really implement a chat room like that because of all the network you know the sockets and and the networking uh requirements there right that your mediator wouldn't actually come into play in that actual implementation. But to visualize it in your head, you can kind of think of it like, okay, I get it. Alan is one object, Michael is the other object, and the server is the Mediator. I can tell you where I've used the Mediator pattern.

So I do a lot of EXTJS development, and the mediator pattern so it i do a lot of extjs development and one of the things that and it's not even just extjs any kind of thing if you think in web components that maybe this this would help right in web components you almost have like a puppet master sitting up top that's your mediator right if something happens down here somewhere you need your mediator to know about it right that mediator isn't necessarily going to go update the 10 other things that that have something to do there it's not going to do a pub sub type thing but that one change down here the mediator saw that change and now it's going to go to one of the other objects that it knows cares about that kind of thing. Right. And it's going to update that one other component.

So I've definitely done that in the web world. When you think of child components that you're trying to, you know, they shouldn't know about each other because there could be, they could be spun up at any given time and so you're not gonna they shouldn't know that there's five other things sitting down there but when they do something that mediator knows about it and it knows oh i've got one of these other things i need to go update this is where it kind of gets back into this is where this is where the mediator is so confusing because i understand where you're going with this and this is where it's kind of like going back to your observer pub sub type scenario right where it's like oh this thing changed tell

everyone that wants to know about it that this thing changed but you're not doing that right going directly to and that's not what this is do this is not what this is for right right this is like hey i need i need to tell him something so you're going to do it for me because I don't want to know how to get to him. Right. Right? Right. So the best – I found this one example from a site called Sourcemaking, and I loved this example of how to visualize the mediator pattern. And that is air traffic control. Yes, love it.

All of the planes don't know, they don't talk to each other and they don't even know how to talk to each other, but they go through their traffic control and they communicate with that group and air traffic control will then coordinate messages to other planes in the area, where they need to go and what they need to do right now i did find this one example though that was a quite interesting way to think about the mediator pattern and

but it was really weird because it's like well well, okay, the mediator pattern isn't, I don't feel like this was really where the mediator pattern comes into play, but it was using, there was a, a great answer on stack overflow about, uh, you know, comparing the mediator pattern to the observer pattern. And it had, um um one of the examples or analogies that they gave was using it to um you know for button events so you have some button you click on some action and then you know that button doesn't know what to tell the panel to do or you know anything about the panel but it just says like hey you know what i'm just going to tell the mediator to let anyone who wants to know that this just happened right it was an interesting example but that's more the pub sub type thing right usually with the button click

that was the problem that i had with so many mediator documents though i think you hit it with their traffic controller like that is the perfect one right like you're not going to tell every airplane that something just happened you're going to tell the one that's i probably should have saved that one for last in all fairness but yeah because that was totally my favorite one but in complete inside i did want to mention that that other example but um yeah uh two quick things um sourcemaking.com is the site i meant to reference earlier i gave credit to do factory it was source making and they've got a book called design patterns explained simply and yeah that's where i got my favorite example of actually over the the kitchen

so that's interesting uh apparently this is a book worth buying that's that's two votes yeah no doubt i mean they're using real life examples that people can relate to. Yeah, that's nice. And also, yeah, I wanted to mention, I was thinking of a game of poker. And one way to program that is you could have a player that knows who its next player is. And it knows, you know, if I'm the last person betting, flip the next card. But that doesn't make any sense. That would be a terrible way to lay out a poker game. A better way would be to have some sort of game object that said hey player better fold next player better fold and it would keep track of who's out who's in and it would also know when the round of betting is up and it would decide to flip the cards well

you wouldn't want that logic but i mean to the players it yeah but i mean again if you're trying to visualize it though right in a game in a game setting like that though all the players can see each other so there's visual communications that are happening not to mention any you know thing that they might hear or see happen right and yeah so like that visualization doesn't help like you know to describe but what the mediator pattern does yeah all i did was muddy the waters the uh the air traffic control i, is the way to go. Because you don't want to say, hey, everybody, field, our landing strip 11 is on fire.

Don't land there. And have 20 planes all trying to coordinate amongst themselves to figure out who's going to land where. Or even better, you don't want one plane to say, hey, let me tell these other 100 planes in the area, I'm really low on fuel. I need to land now no instead they just tell air traffic control and air traffic control will take care of the queuing yep right plane one to move over here plane two to move over here it's not a pub sub it's literally the mediator knows exactly what needs to happen with each one of the other elements but but and this is where that that button example came up from, though, because I was trying to find some real-world uses of the mediator pattern, right? Like, what's a daily example that we already use in insert language here, and I was coming up short.

Yeah, like I said, I definitely do it on the ui all the time i don't know if you do i definitely do the way you described it it's no literally you have a puppet master you have something down here that did something the puppet master sees that that happened and then it knows it needs to go do something to something else it's not publishing that event anywhere it says okay somebody just saved something over here i need to feel like you're describing observer no not at all i really feel like you're describing observer is a pub sub it publishes out to everything that it has dependencies on that's not what i'm talking about you have a form let's just make it real simple you have a form on the left well you're still on the right no no here okay

okay i know how to describe where i take issue with what you're saying is in your you're saying um in your words the puppet master right so the puppet master has the logic and everything of knowing like it's making decisions and what i'm saying is the mediator doesn't have that logic the mediator is just a communication device there's no logic about it the mediator is just saying hey this object wanted to communicate something to there and that's where like the chat room example is also a nice way to visualize it even though you wouldn't use this pattern but you know the server doesn't care you know it's just saying hey michael wanted to tell alan something alan wanted to tell michael something and so it's

just it's just letting that communication go back back and forth it's not making decisions on hey michael just sent out a message let me see what was the content of that message okay well based off of that let me make a decision that i need to tell blah blah blah but the definition from do factory even says mediator promotes loose coupling by keeping objects from referring to each other explicitly we've covered that and it lets you vary their interaction independently that's not sending a message that's telling it what it wants it to do that's the puppet master that's i'm pulling your string this way because that's what i need it to do i mean that's what it sounds like to me right i mean and it lets you vary their interaction independently it knows how

it needs to interact with the different objects so the the other child objects don't don't know about each other and don't know how to interact with each other so i mean that and the air traffic controller is a perfect example it's not a pub sub you're not saying hey one airplane called into me hey hey this you're not just going to go call out airplane c not saying hey one airplane called into me hey hey this you're not just going to go call out airplane c and say hey this dude called into me you're going to say hey airplane a called in said it's low on gas i need to tell airplane c that it needs to get out of the way so the airplane a can land you see what i'm saying like it knows what to do with those items but it's still that that's the perfect example yeah but i still take issue

with your puppet master uh scenario though like i don't i just it's the same thing it doesn't feel no because the in your puppet master scenario that you were describing you were that that puppet master as you just as you called it was making decisions it had logic right that's what the air traffic controller is airplane a is low on gas calls into the mediator mediator says airplane c get out of the way because i need airplane a to land that that's making decisions that's not hey i got a message let me let me blast out just that i got a message right it's hey i need airplane c for you to move because i need airplane a to go land right like so it's making decisions it's it's not just a if it's observer it's literally a pub sub right this button was clicked let everybody know that this button was

clicked i mean yeah i i i know, I hear you. I do. So I don't know how it would be any different than Observer if that wasn't the case. Well, I've yet to see a real pattern perfectly match the description. So every single pattern I looked at, every single example of command, each one was a little, you know, iffy on the implementation compared to the textbook definition so i would say the master puppet thing is it's pretty close it's not 100 there but i i think uh i'm gonna have to go go with alan on this one sorry outlaw yeah all right i just don't know how it would differentiate itself otherwise because it truly would just

be a pub sub except it'd be a pub sub saying that I'm only going to publish to this object. Because, okay, so the client classes use the mediator, right? In the scenario that you described, you were saying that the puppet master saw that something changed and then was making decisions on what to say, right? So he observed that something changed, he noticed that something changed, and then he was making a decision to do something. That's not a mediator. A mediator, the client classes use the mediator to send a message to the other client.

So the puppets would have to send messages back up the string, right? Okay, I mean... Where was that defined, though? That's in the definition. Where? On Wikipedia. I can read you the the definition. Where? On Wikipedia. I can read you the Wikipedia definition.

That thing is unreadable. The sentence is nonsensical. But the definition from Wikipedia is that client classes, and this is actually taken from the Gang of Four, if I recall, the client classes can use the mediator to send messages to other clients. Now, here's the part where it gets confusing because they can receive messages to other clients. Now, here's the part where it gets confusing because they can receive messages from other clients via an event on the mediator, right?

But that event could just be something as simple as, hey, I want you to tell Alan something for me. Yeah, I know, man. That's the problem is if you go look for things on the mediator, like it's too similar to facade and observer and the waters get really muddy quick right and that's where that's where like you're i hear you on your puppet master example right and i'm not saying that it's not a bad example of something i'm just not entirely on board with it being an example of mediator it's

actually a different definition than i found in other places and i guess that's what really kind of screws things up so right uh yeah yeah so now you see why i'm not as excited about mediator now that i got into it and started you know digging into it i was like ah i picked bad one. So would you say that it's a less flexible but smarter observer? Well, okay. So one of the things that I did read – oh, where was this quote? Because there was a great quote that I read, and I think it was from Source Making, where they had said that it was easier to make – I can't find the exact quote, but it was something along the lines of it was easier to make, I can't find the exact quote, but it was something along the lines of it was easier to make reusable observers than it was mediators.

Okay, here it was. We found it easier to make reusable observers and subjects than to make reusable mediators. And I think what they're getting at there is because the mediators have, know you've taken all of that logic about how to talk to from one object to another right you've taken all that away and put it into the mediator now the mediators kind of got this tight coupling between these objects and that's what makes it difficult to reuse and that's where by the way where it's similarity to the facade pattern kind of comes in right because if you remember what the facade pattern did is you know you took one um like object or api and and you hid it behind some other um you know interface so like when we talked about the facade pattern before we talked about like you

know what it might take to play an mp3 for example right and you know in your facade pattern you know or interface you might just have something like a play uh method right but really in the implementation of your play method you're doing things like opening the file stream and you know opening the you know the audio device and all those things and and you're using the api uh for that that you're abstracting right and and you're simplifying it with your facade right and that's where the mediator acts as a facade because my communication to alan might be you know the api to him it might be different different and difficult and so instead of having to like know specifically all of the uh all of that API, it's just like, hey, one method to tell Alan this, right? But then that takes out the whole thing of notifying another client or child, right?

Not child. Not child because these aren't children objects. These are objects that could be peers, right? They're equal level some sort of dependency yeah but but um you know how to talk to the alan object might be different than the michael object might be different than the joe object right if i can turn this all into objects yeah and interesting too i'm thinking like one one difference too is our one way to kind of exemplify the difference is that you can have an observer

library right you can have a generic observer that allows for publishing and um subscription desubscribing and i'm sure there's already like observer.js but you would never have a mediator.js because it needs to know specific things it needs those rules and that logic to be useful. Right. Yeah. And that's why it's less reusable. Same with the facade. You would never see a generic facade, you know, because it just doesn't make sense. Right. The interesting thing is after this gets published, we're going to get like 10 comments saying,

I know exactly where this is used. I am fully prepared to be told why i'm wrong and i would love to hear some uses of the mediator pattern that are like real world out there in the wild examples that we use every day and didn't even realize we were using i i want to know that because you know why that would only help to solidify my understanding of the mediator pattern but you say that but uh i got schooled pretty hard on the memento thing and uh and now look at how well you know it's pretty cool see yeah i definitely uh i have more fondness now for the mediator than when i hated on it before yeah sorry not mediator so so talk to me in 12 episodes memento yes and and then maybe i'll like the pimento cheese pattern

right on very nice and oh by the way uh i did buy that book while we were sitting here talking and then maybe I'll like the pimento cheese pattern. Right on. Very nice. And oh, by the way, I did buy that book while we were sitting here talking. Nice. And it actually has the logic pattern and also the template method factor, which were the two patterns that we had kind of deviated on from the Gang of Four book.

Nice. Very interesting. So we'll have to include a link to that. It is only $19 only 1995 on their special order their special offer for ebook and uh what my favorite part is it is 119 pages including the appendix that's not bad the design patterns book is pushing 400 yeah man So it's bite size. Not saying shorter is better, but shorter is better. Right. Cool. All right.

Well, now it is time for our tips of the week. Our definition of week varies greatly for most. All right. And this is why we need a mediator pattern, Alan, so that you and I can communicate. That's right. All right. And this is why we need a mediator pattern, Alan, so that you and I can communicate. That's right. All right. So I've actually got two only because I somewhat cheated. Oh, man, you're the one that told me not to put two in this week. Yeah.

And then you went and cheated? You can put two in, but mine are kind of like fluff. So because I couldn't think of a tip of the day cause I haven't coded in like four days. Uh, my tip of the day is a site called jstips.co. So they give you a tip of the day for JavaScript every single day. So that's giving back right there. Um, and it looked like you had some pretty cool stuff. Is one of them to name your iffy?

I don't believe it was there, but maybe they should add that one. Boom. It should be. All right, and then for the bonus. So one of my friends told me about this app called Geek on Android and iOS. And there's a lot of people who have joined our Slack, and they come into the Gear channel, which is a fantastic channel. If you ever just want to throw away your money, come into the Gear channel. We will find ways for you to spend money there are thousands of ways to spend thousands of dollars in that channel but if you want to be a little bit more budget friendly you

can get this geek app and buy just tons of things for dirt cheap now have you gotten anything from it yet not yet i just downloaded it last night i was overwhelmed by the amount of stuff that i could get for cheap okay now disclaimer here because when he says that things are cheap i mean we're talking about like everything's a dollar or two dollars i'm kind of curious like when you do order or something yeah i want to see the quality of it so let's you know full disclaimer here you haven't received anything yet, so it could just be junk. But let's be honest. If you spend $2 on something and it breaks, you're like, ah. You might not be incredibly upset about it, but.

Dude, like there's this, I can't even think of what these are called right now, but oh, a digital multimeter. How much is this thing? Let me look at it. It is. Look now. It is. A multimeter for $2? Hold on. I'm looking to see how much it is. Let me look at it. It is... Look now. It is... A multimeter for $2?

Hold on. I'm looking to see how much it is. I can't find it. This can't be a good multimeter. How do I buy it? Oh, here. Oh, it's $12. And you would trust this multimeter?

Pretty good. It's a pretty decent looking multimeter, I got to say. Well, actually, yeah, that looks about the same as a multimeter you might find at one of your box stores. For $30, right? No, I don't think that that one's that expensive. It wouldn't store. Yeah, right?

Stores? Who goes to those things? Yeah. So, yeah, I mean, like it's got all kinds of stuff, man. Okay, so I've definitely seen this laptop stand on Amazon for $35. It's $18 here. I'll tell you, that multimeter you just showed me it is eight dollars on amazon right now oh boo okay so so you're getting ripped off and uh yeah nine dollars at

one of your box stores maybe all right 625 i don't know i don't know apparently multimeters are really cheap well that's yeah that's what i'm saying like that one that one in particular yeah so at any rate there might be some good stuff in here for dirt cheap there might not i don't know i haven't bought anything yet and quality is to be determined so yes i have no idea do not shoot the messenger if you got something and it was horrible that is correct there is a batman light for your ps4 controller come on now that's pretty cool let me see that picture hold on i got that that's pretty awesome that's sick right so yeah i mean there might even be some fun stuff in there that is nice whatever you know download you know speaking of batman

that was you've seen batman v superman i have not I feel like it's safe to talk about It's been a little while we might save it It hasn't been long enough I don't know if we can Well it's a movie so you know neither one's gonna die Neither one's gonna really lose Wait is it out in stores yet That's the question

If it's not out in stores we can't really talk about it Like Deadpool I feel like it's safe at this point hey i haven't seen it so i don't want it spoiled all right you haven't seen batman v superman no i heard it was terrible right there you go yeah there you go so i figured i would just wait like 10 years and netflix it oh that's. That was the sad thing. I so badly wanted to like that more than I did. Yeah. That's hilarious. And you showed me that Batman thing.

That was the whole thing that brought this up because then that made me think of The Suicide Squad. Oh, yeah. It's coming out. Oh, yeah. Oh, yeah, man. That's going to be awesome.

Maybe. What? All right. Tough crowd. My tip of the week. Oh, yeah. Mine mine was really late i couldn't think of one but then i bought this design patterns book and started reading it like 10 minutes ago so i kind of want to do that design patterns explained simply so we will have a link for that we'll have at least one link for that in the show notes wait man that's your tip of the week the the book that you just bought on air?

That's fantastic. Yeah. I mean, I read the first two pages while you guys were talking about Batman versus Superman. That's just in time right there. That's up-to-the-minute accuracy. Wow. That's right. All right.

But no, the tip that I had written down, which is also a bit of a cop-out, was to learn a new programming language. Start your brain, learn new concepts. And my favorite part is you get to see old concepts in a new light sometimes. And as I like to say, everyone should know a scripting, compiled, functional language. So if you are stronger in one of those areas, you should pick one of the other ones. And one way that I like to learn new languages aside from things like Code Wars or Project Boiler is programming Conway's Game of Life, which is also a tip in its own right. If you've never programmed it before, it's a really neat one to do because it just looks cool. And there's a few gotchas in there.

All right. looks cool and there's a few gotchas in there all right so i guess i'm going to get into the the nitty-gritty of the um tips of the week here um joe you might like this one so have you ever found yourself um okay first off let's talk about in-unit and parameterized test, right? Now, if you're not familiar with parameterized unit tests, what I mean is that you create one method and the method signature takes in some variables. And your code just runs through all of those, you know, uses those variables to make some assertions. And you might have, you know, the method decorated with some test case attributes. And those test cases will then pass in all the different parameters. So let's say you have, for example, a ad method, you know, ad test that you're doing and it takes in two numbers, right? And you just want to be

able to like do some ad operation on those two numbers and, you know, assert some result, right? And so in your test case, you might have like one and two and two and three and three and four etc etc right um now joe have you ever found yourself wanting to include in your test case attribute an object attribute an object right what does that mean so so when you do a test case in in unit and you know in the example that i gave with one and two uh those those numbers are constants so they're not going to change right with a test case attribute on your your unit test declaration, you can only have constant values, right? So, constant string values or numeric values, but it has to be a constant, right? In the case of an object, though, that's never going to be constant because something has to new it up,

right, in order for it to have some value, right? right so it's never going to be constant so you can't say something like test case and then let's see it would be a good example of a object that you might want to run a test on well nothing's coming to mind here. Not an array. Let's say if you wanted to, I can't think of an example, but if there's some object that you wanted to be able to pass into your test as one of the parameters, right?

And you wanted that object to vary based on a test parameters, right? And you wanted that object to vary based on the test case, right? Like maybe it's another object in your framework. So maybe you want, you know, whatever your method is that you're testing, maybe you want to be able to supply another one of the objects in your library to it as part of the test.

But for each test case, you want to have a different version of that object to represent a different state, right? Well, with the test case source attribute in NUnit, you can do that, right? So what you can do is you can have your test method, right? And then specify test case source. So you'll have test and then as the attribute and then comma test case source. And then in parentheses, you'll have a string that represents the name of the source, right? And that source could be either a parameter or I'm sorry, not a parameter, a property or a method or some instance or static member or field.

Right. But what it returns back is an I enumerable or a type that implements IEnumerable, right? And then you could have that, let's say you had a method that returned back some array of objects, right? You know, inside of that method, you could have your logic to create all the different versions of the object that you want to test or, you know, that you want to be passed into your test method, right? Okay. So it allows you to have parameterized tests, but with... With objects.

With objects. And I feel like I'm doing a horrible job of trying to explain this thing. I think I know what you're saying. I've done parameterized tests before, and I end up passing multiple arguments here. I'm like 12, 3, 4 that all get passed into my function. Wouldn't it be great if I could

actually just create my object right there and pass it in that way? It's so much more easy to read, and then I don't have to do a bunch of weird tweaking to figure out what's going on. Yeah, if you like to unit test, this one's going to be a fun one for you. And since everyone else got to give out two, I feel like I should, too. But it's not going to be a fluff one. But maybe a little bit lighter one. Have you ever, maybe it's just me, and I know Alan's going to look at me like I'm crazy when I say this.

Have you ever wanted to delete or forget about some wireless network that you've connected to? I do it. You do? Yeah. This one's specific to a Windows 8.1 environment or 8-ish environment. I don't know if I'm good on that, but I definitely do it on my mobile devices and that kind of stuff. So, okay. So, I'm not alone in this in this then is where we're going because

i'm pretty particular like you know once i connect to some uh you know wireless network once i no longer need it i don't like it to exist in my you know always connect to or connect to automatically kind of network list because you know who knows i might go somewhere else where someone else has the same name you know and and even though the passwords may change, let's say if it was a free Wi-Fi, I don't want to connect to it unless I mean to connect to it because I like to be aware of that kind of thing when I'm traveling out and about and make connections to networks and whatnot. I don't know. My own security, uh, mindset, I

guess. So here's what you can do on the command line, type in net S H space, W LAN space show space profiles. This will, this will show you an iteration of all of the Wi-Fi networks that you know about at the time. If you already know the one that you wanted to get rid of, you can type in netsh wlan delete profile name equal and then in, the name of the Wi-Fi. So, for example, if you fly Delta and you connect to the go-go-in-flight thing, then you would type in netssh wlan delete space profile space name equal, in parentheses, go-go-in- flight, and it'll delete it. So if you, like me, want to keep your remembered Wi-Fi networks in check, then that's how you can do it. All right, how about a whitelist?

And then you could write a little script that will list all your Wi-Fi and then remove them all except for the ones that you've specified. I like that. If I wasn't so lazy, I would write it. Hey, with Xamarin, you could do it now for everything. I don't know how easy that would be. Yeah. I would just bash it, man.

Oh, my gosh. Bash runs everywhere. You need an app for that, man. People want apps. That would be an interesting app.'m gonna write that out it wouldn't be horribly difficult i don't think i'm gonna write an electron app to do that why not xamarin um because i love javascript so much you're gonna force yourself to learn it i really want to do something with Xamarin. I just, I don't,

I don't have a burning idea in my mind that I just want to take off and try and do, you know? So I don't know. I feel you. All right. Well, that wraps up episode 42, right?

That did we hit the bottom of our tips of the week we did yep all right so uh with that we didn't put all our jargon at the bottoms oh yeah sure no we did yeah yeah so so the deal here is uh we're trying out a new show notes format that will help us uh exped us expedite things a little bit. So things look a little different for us. And that's why there may have been some clumsy transitions like this one that I have super underscored and highlighted. I mean, definitely not on my part, though. So, I mean, if we're being honest.

See, in all fairness, it kind of skipped a page, and that's why I didn't see it. Ah. Ah, Ah. Yes. So definitely go leave us a review at www.codingblocks.net slash review. Yep. And be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And be sure to give us, well, you already said to give us reviews on iTunes or Stitcher, but as Alan said, you can find the links easily to that at codingblocks.net slash review.

Yep, and bring any questions or topics on over to Slack. I think we're going to go ahead and create us a topics channel in there. And you can sign up, if you haven't already, by going to codingblocks.net slash Slack and visit www.codingblocks.net where you can find all our very extremely detailed show notes, examples, discussions, and more.

And follow us on Twitter where we are almost up to 1000 followers. Oh, that's amazing. Makes me feel real good. So that's at coding blocks. Yes. And with that, thank you.

Nice. Yep. And, uh, you'll be hearing from us not so soon i guess maybe soon it depends on when we record the next episode you know it's we got it's the tip of the week so it'll be the episode of the week it'll be the episode of the week that you hear it that it releases yes you know it yeah what else can i say yeah this probably has been the episode that we've heard the most about being late on like it actually came up it's like again today it's it's been at

least once a day where someone's like hey uh you guys still doing this late well the problem was we were walking around san francisco getting our sunburn on and i think dude on my fit application i think we walked like 17 miles in two days I don't doubt it it was amazing yep are we still recording yeah yep okay well uh one of our co-workers just walked 45,000 steps in one day so I was yeah griping about like you know we broke 20 one day in San Francisco like ah my feet and ah, my feet. And then just a few days later, he goes and breaks 45. 45,000? Yep.

Dude, we did close to 30 one day, and my feet were complaining. I know. Wow, that's impressive. All right. All right, so that's it. Bye.