Coding Blocks - Clean Architecture – Programming Paradigms

Episode Date: October 30, 2017

Michael forgets what his favorite part of the show is, Joe makes us wait to learn what his favorite part is, and Allen pronounces it "pair-a-dig-'ems" as we continue our deep dive into Uncle Bob's latest book: Clean Architecture.

You're listening to Coding Blocks, episode 69. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And visit us at CodingBlocks.net where you can find show notes, example discussion, and more. Send your feedbacks, questions, and rants to comments at CodingBlocks.net. 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 Zach. And I'm Michael Outlaw. This episode is sponsored by Linode. Get your next server up and running in under a minute with hourly billing that you can

cap on all plans and add-on services, including backups and node balancers. VMs with full control running Docker containers, encrypted disks, VPNs. Linode has support for all your favorite distributions of Linux with CLI tools that you can use to manage all your Linode needs from your terminal. Run your own private Git server with native SSD storage, a 200 gigabit network with the latest Intel processors, friendly 24 by 7 support even on the holidays with a 7-day money-back guarantee. Start your next amazing project with Linode with a $20 promotional credit by using code CODINGBLOCKS17 by heading to www.codingblocks.net slash Linode. That's L-I-N-O-D-E. All right.

So here we go with probably one of our favorite parts of the show. Hey, we got some review feedback, by the way, that said that they love our favorite parts of the show. So like, you know. Oh, right. All that. Joe. Yeah, man. You don't have a favorite part of the show.

You need to pick one. You're going to have to figure it out. This was some feedback we got off one of the reviews. Sort that out, Joe. You don't have a favorite part of the show. You need to pick one. You're going to have to figure it out. This was some feedback we got off one of the reviews. Sort that out, Chad. Yes. So figure it out. I'm going to think about it. I'm going to let you know at the end of the show.

All right. Sounds good. Stay tuned. I like that. I like that. Yes. You're going to have to wait to the very last minute and a half somewhere. All right.

We'll see a pull request coming soon. We will. So iTunes, we had a ton of reviews this time. Thank you so much. I'm going to try and read these and hopefully I don't mess anything up too much. So we have Antis, DLNL, Pazabon, Drop Table Star, probably one of my favorites in here. Andrino, Austin Weber, Digital Analog 9, Cynthia Scott. Is this easy enough to read?

No. Squiffy Blarg. That one's pretty good. Captain Barbosa, Burgerman835, and Kaspers. So thank you to all of you who took the time to review us on iTunes. And on Stitcher, we have Fabio Schmidberger, Ken Dickinson, Crazy Coder, The Recursive Base Case, Worst Milk, Cheesy Programmer, Fudge4231, there's a lot of food in there, TDS Rock, Bio Programmer, Game Kid, Proof by Induction, and I'm going to try this one. Casper's Rinkivics.

Rinkivics? Something like that. It's pretty close. I'm sure I just insulted him. Or her. Getting pretty good. Hey, nice sticker on that laptop there, Daniel Puzban. Very nice to see you. It's so great recognizing names in here, too.

Also, big thanks to Critner, Arlene Andrews, Medaris, and JZak2000, who is probably me, I guess. I might have done this. It's kind of embarrassing. Why 2000, just out of curiosity?

I don't know. Sounded futuristic like 20 years ago right i'm all i'm totally in the future uh that's awesome it reminds me of like the the grill master 3000 did anyone else have that kind of reference come to mind not that would my feet all right okay so moving here, I was having a conversation. I believe it was in the gear channel, as a matter of fact. And super good Dave had a comment about he's using an old, like he had a picture of an old Dell mouse that he still uses today and is over 11 years old.

I can't think of much gear that lasts that long. So I was sort of poking fun at him about it, but he was like, yeah, dude, this thing's solid. I was like, okay, that makes sense. So he was like, hey man, maybe this is something where you find out who's still using what kind of ancient gear out there, right? And we're going over the clean architecture book.

So, hey, for this episode, if you want to be entered for a chance to, you know, win another copy of clean architecture, leave a comment on this particular post, which is going to be codingblocks.net slash episode 69, and tell us like the oldest piece of gear you still have in use. And if you don't have anything old, that's fine. Just say, hey, look, i buy new stuff every five months whatever but but yeah leave a comment on this post i'm gonna win unless uh miko's listening you are yep yeah i i'm gonna say that uh alan's oldest piece of hardware is probably his headphone from last week so jo, Joe, what have you got? I've got a 2003 Saturn View.

No, no, no. It's a computer year. Hey, you said hardware. It was so old, it came with a cassette player. What's that? You might have won. Yep. It came with a what?

Cassette player, FM, AM radio. radio was big news at the time oh man this thing was what i was really going for that's awesome i i kind of agree with him though like on the on the melt i don't like his particular mouse that he's using it was like an old dell mouse is that what it was yeah yeah but like you remember the old school microsoft explorer mouse i do the wired one it was a very good one i i still have that thing but i don't use it daily it's not like a daily driver but it is like the portable driver like the one that i don't care if it's going to get if it got destroyed in transit i'm not going to be upset but i keep it in my bag so that if i do need a physical mouse i have one it's a workhorse and it did we it won't get destroyed so maybe i'm just too gentle on my laptop bag but it's still there that's awesome yeah you remember when mice had

like those little spheres and the balls in them i've met i had one of those i threw it away like i saw i found it in a pile of old stuff You remember those things would get gunked up and they'd stop working? Oh, the wheels? Yeah. You'd have to like turn it out, take the ball out, clean the. Dude. Whatever that nasty gunk was that would build up on the wheels in there. And you were like, I don't want to know what this disgustingness is.

When did I have glue on my desk? Right. Why is there carpet inside? There's not carpet on my desk right why is there carpet inside there's not carpet on my desk but there's carpet inside my mouse how does that happen and for all you young whippersnappers out there no idea like yeah wait how did yeah how did carpet get in your trackpad see we used to walk we used to walk to school barefoot in the snow uphill both ways. All right. And we had mouse pads. Yes.

Oh, man. It's good times. Hi. I'm still here. Oh, that's pathetic. Well, the friend of the show, Zach Braddy, recently got a course published for Manning. He's part of their meat program, which is like their kind of early access. The course is called React Motion.

That's really huge news. We're really excited for him. It's awesome. I'm glad to say that, proud to say that I'm one of the first customers. And we'll have a link in the show notes. And actually, he's given us a couple of copies to give away. So since we're already doing the book thing in the comments, why don't you make sure you're on the mailing list where we give away a bunch of stuff, and

we're going to give those courses out over there. So join the mailing list, get free stuff. We'll be doing JetBrains here in a couple days, too. So you should definitely sign up on the list. And speaking of Zach, I actually did. How do you sign up on the list? If you go to the website, it's in the top right

corner. Unless you're on mobile, scroll down the page. But yeah. Yep. Yep. You're going to notice a theme with Alan. He's going to be very specific on us saying URLs and such tonight. I can't help myself. Sorry.

Programmers are a pedantic bunch. If we get it wrong, someone will let us know. Oh, there's no doubt. But speaking of Zach Brady and React, we actually did a collaborative pair programming kind of thing where he kind of walked me through, and I pretended to be super dumb, and he showed me how to create a React app. But we're going to be dropping those videos on YouTube here

by the time this episode's out, so I'll have a link to that in the show notes as well. So really excited to see that going live. And we're dealing with the Marvel API, so comic books, stuff like that, React react awesomeness very cool hey congratulations zach that's that's awesome stuff man yeah it's huge man it's huge yeah um speaking of courses i also recently got a review copy of c smith's um also known as our dallas on twitter at rdallas course on deviq.com and i got a review copy watched it it's really awesome it's about five hours although he's still kind of adding and

tweaking some stuff as.NET Core 2 just came out and anyway i wrote a pretty big in-depth review on it so you should go check it out love the course it was a it was great for an old-timer like me who's used to kind of doing ASP the way, but it's also great for someone who's kind of new to it. So, um, we'll have a link to that in the show notes as well, uh, as well as my,

uh, review of it. So all thumbs up. Did he just call himself an old timer? He did. As far as ASP goes. Yeah. I was doing it back in,

back before.net. ASP 3.0. Oh yeah. Good times. Those were good times right there. That was like PHP 0.1.net. ASP 3.0. Oh, yeah. Good times. Those were good times right there. That was like PHP 0.1. Yep. All right.

So this was an email that came in to us, and I don't know that any of us responded to it, but it was a great question. It came from a project manager's point of view. And he said, I have a question that maybe you can answer. If there is a room full of programmers working on a project, and if there is another room with just a couple of programmers, which room gets more work done and why? And this is from Gordian. And this is an awesome question. And I think we should all answer it. Why don't you go first, Joe? Less is more. I think that there's a lot of invisible work and communication that adds up when you get more people involved so you know i think it's a fine balance and there's obviously things that you can't do with like three people

that you could do with 300 and so there's there's a line there somewhere but i i mean i think i would much prefer working on a smaller team if possible. Yeah. My answer was going to be, it's going to vary by situation, right? Kind of similar to what Joe said. And he stole my thunder, but yeah,

there's going to be some situations where you're just going to want to work in isolation. You're, you're not going to want to have anyone else disturbing you. And then there's going to be those times where, you know, that group is going to be helpful. I don't know about 300 I think he's watched too many movies. So if you're not a Spartan then you might want to have

a smaller team of five or so. But yeah I can see where that might be helpful for particular situations especially for things that are still being actively maybe designed where that collaboration is a key and you want it sooner rather than later. Yeah. I'm, so I'm sort of with that. The, the only difference is in I really liked this question because it really does drive to the heart of what our topics are, which is it sort of depends on how well you have architected what is to be done, right? Like if things have been given clear

boundaries, then it'll be easier to have larger teams or a larger team of people that might be subdivided into sub teams to work on things than if you have just kind of this big ball of spaghetti code, right. That everybody has to work on. So I think, I think the point where, where things get a little bit crazy is when you have too many people working on something that's not well-designed,

you start slowing down because you really start stepping on each other's toes. Right. On the flip side, when you have a small group of people that all intimately know a product, they kind of know the pitfalls to watch out for. So it really comes down to good design, I think, in terms of, can you scale up a big team to get more work done? Yeah, but you really have to plan it out better, I think is what it boils down to.

So that was kind of my take on it. I would add good design or an understanding of the problem domain. That's a good point. Yeah. Which would help hopefully drive better design, right? Well, because the reason why I throw that caveat in there, though, is you might be talking about something that's independent of, you know, it could be its own little thing already. Right. Right. you know it could be its own little thing already right right but i think i think we're all in

agreement that it's not some magic lever that you can pull and say i have 10 developers now if i add 10 more i'm going to get twice the productivity and it's not a one size fits all answer right right what we pretty much all said but just always keep in mind doubling the size of the team does not double efficiency right you might get a third more efficiency which seems like not enough according to this book you don't even get that you don't even get that like it was diminishing returns on bad design so yeah i mean don't get me wrong if you have a thousand programmers of course you're gonna be able to write more code are they gonna be that more effective at it hard to say um and so i i actually wanted to bring this up because we we

we've made several jokes over time about php right like and i just wanted to say i actually had to write some you wrote some some sql injection code i did i did and it's it's pretty like i i even modularized the sql injection code it was it was So, you know, for all the times that we've made cracks at PHP, and I know that we have several, several people in our Slack channel that do PHP, like, it was kind of fun to take a step outside and mess with something that I haven't played with in a while. So, you know. Now, why? I mean, you're kind of hinting around it like you did some php but

what made you so our site's wordpress right and and oh so you were doing stuff you didn't tell us uh-oh joe wait did you not know this all right so sneaky stinky so here's the thing this is what's frustrating so our newsletter was getting bombarded with with spam just trash and we had man i'm going to try and make a really long story fairly short but basically what had happened was some stuff had gotten through and basically amazon kind of shut down our emailer and we were like what in the world's going on this doesn't make sense and so i went back and looked at it and it was because there were bots out there just cramming data in there and so we'd send out things and people would be like what is this right so for some stupid reason somebody would put in like your friends or your neighbor's email address and it and people were

like this is spam this is garbage right so i put recaptcha on the site but in order to do that i had to write some server side code because recaptcha basically does some authentication right like you do a request and then for those who don't know what reCAPTCHA is, it's like Google's anti-spam kind of thing that they've built, right? It's their new CAPTCHA technology. It is their new CAPTCHA, and it's built on machine learning. Like it's pretty cool stuff. I should probably get a link and put it in the show notes here

because it's pretty neat how it works. But anyways, so in order to authenticate the person that did this, actually it hit the server properly and got the right token back. I had to write some PHP code to verify all that. So, you know, I took a blob of code out there that I found somewhere that I copied and pasted that had some recapture stuff. And I was like, well, this isn't very clean. And so I so i like you know modularized it and did all that kind of stuff so anyways i wanted to say you know i i apologize for all the you know smackdowns we've done on php over time it was kind of fun like it wasn't too bad you know yeah but in fairness though we we give every language equal smackdown treatment

we do but php gets picked on more often than not than others, I think. Maybe even more than JavaScript on this show. I would have certainly guessed the Java or JavaScript would have been at the top of our SmackDown list. But okay, fine, PHP. I will say, the closing thought on this was, regardless of the programming language, you can write pretty code. You can truly clean up your code, right? So take that, PHP. You actually can write some pretty code.

Oh, that's awesome. Lemony, if you're out there, we're sorry for doing this to you again. Yeah, yeah. You're awesome. Hope you're staying warm. And you can send all your comments to alan on the slack channel no but i mean i don't even know the programming language but i was able to break it up in a nice module so anyway just i wow that's not what i meant thanks guys

it's okay so you dogged on php and it mentioned that we have wordpress site uh so how long until we're down oh dude come on, come on. Here's what I'll tell you. It's not hard to find out if somebody's running WordPress, right? So that's why I'm not putting it out there. Information disclosure, Wasp number eight. Yeah, man. Fail. Can you cut this out?

Right. I'll have to edit this out. A lot of bleeps. Yeah. All right. Who's got this next one? Not it. I think we should skip it and do it later. All right. That sounds good.

Fine. We'll skip it. And we will say that, hey, if you would like some Coding Blocks swag, I'm going to have to say a URL because Alan wants me to. Head to www.codingblocks.net swag and you can find uh links to getting some stickers getting shirts uh if you want to some stickers or hey i even have some magnets send me a self-addressed stamped envelope and you can find the address to send that to at www.codingblo.net slash swag. Yes.

All right, great. And today, the topic we're continuing on with clean architecture. So next section of the book that we're going to be talking about is basically about the different programming paradigms and solid design principles

applied to architecture. You don't say paradigms. Every time I see that word, I have to say it, even though I know it's paradigms. It's paradigms makes me very happy but now i won't be able to not say that thanks for ruining it for the rest of us yes man for the rest of your life you're gonna look at that and you're gonna be like that's a cool word paradigms all right anyways it's one of those little twitches in my head right like why can't you have one? Because you need a pair of them.

You need a pair of diggums. The first programming pair of diggum is structured programming. We're off to a great start. Anything else you want to say about BHP while we're at it? Let's go. And so, well, we get skype keeps crashing on me um so i'm gonna keep going uh we get a little history lesson here um going back to the days of punch cards and uh writing stuff by hand i don't know typewriters and uh we get a nice little lesson here about dykstra who's famous in the programming world

for kind of um championing this notion of functional decomposition or being able to break down programs into smaller and smaller pieces until you get to such small pieces that you can actually prove them mathematically correct or not and you can also look at performance that way and you know that's back when you know performance and at performance that way. And that was back when performance mattered. Well, I mean, one of the things that he said or one of the things that he pointed out was that programming is hard and people aren't very good at it. Yeah. All these years, we're still not good at it. But I like how Joe kind of implied that performance doesn't matter anymore.

It mattered back then, but now it's like, who cares? Yeah, that's not true yeah we've seen some of your queries so it's okay yeah you said i've got the question where it's like um hey how do you sort a number or a list that's too big to fit in memory and like now i would just say i would stack overflow out or google it or whatever but like you could actually probably go in there and say like sort this list and you'll find a web that will just do it for you. You can upload a 4 gig list and it'll just figure it out for you. You know what's amazing? I mean, think about that though. Back in the time when these conversations were being had, there was no Stack Overflow. Could you imagine

programming back then? No. What are you talking about? you're talking like this is dude this is a long time ago i know but but okay fine so we don't use punch cards but they're depending on the environment that you're programming in you still care about performance you still care not that not i'm talking about there were no resources like right now if you wanted to know how to sort a big list you go you, hey, what's the best way to sort a four gig list, right? You'd probably find some Google results. Back then.

No, they were AltaVista results, but yeah. Or HotBot. But no, like seriously, back then it was a mental challenge. Like you didn't have those resources it wasn't like there was some help file in your ide that was like oh if you want to sort of 4 gig list oh you only got 64k of ram by the way you know 4 gig that's your whole hard drive plus your friends yeah it's a lot of punch cards yeah so i i mean it's just it's interesting how like the problems the problems have gotten bigger in scope because of scale but but the resources available now so anyways go ahead

no uh that's been just uh talking about punch card back day um back in the day and um you know a lot of like the proof by induction the kind of mathier side of computer science stuff that we still talk about today we're kind of championed by this guy and yeah the deal was basically subdividing programs into small and smaller pieces that were provably correct. But the deal with that is that not all constructs played nicely with that. Particularly GoTo was really bad

because you could kind of jump to any location in memory and it broke this kind of nice structured composition and it was error prone, but also made it just harder to to work on and harder to prove things were correct and so there was a big kerfuffle a long time ago about go to becoming a harmful or being declared as harmful and there was a quite a war about it for a long time long time uh and uh it seems like they kind of won and uh unfortunately it hasn't completely gone away as we've seen the go to fail and kind of recent memory you know i was going to say we should ask apple their opinion of uh go to yeah but i mean

that's the deal with the go-to right it's like they're still there like if you're doing a loop then there's some sort of you know go to that says go to back you know this instruction number but um what we can't really do in modern programming languages just say like hey jump to memory 1422 and you know keep running um so that's uh that's something that we lost but is it made things much easier and modern languages have just totally skipped over that or made it impossible to do except for sql you know go to still in sql right is it really t? Yeah, T-SQL, you can totally do that. In a stored proc, you can actually have a go-to and a label. So I can go to a

label, but I can't freaking order by a variable? I think you're just in a sore spot. Yeah, man. Totally, you can. That's correct. You can do one, but not the other. Well, I about wore down that soapbox, so'll uh i'll stay off it this night uh but uh anyway um so uh yeah proving something is incorrect is really important but um that's not that's not such a big deal when we're talking about architecture and we don't

really talk so much in this book about um accuracy um but uh math was basically the discipline kind of pushing that stuff forward and applying those mathematic and scientific principles. There were some statements in there where he said that math was the discipline of proving provable statements true and science is the discipline of proving provable statements false.

And he gets into this section about tests where he's talking about testing and he's saying this section about tests where he's talking about you know testing and he's saying well in regards to to testing software is like a science because we're our tests are showing correctness by failing to prove incorrectness right which which in a nutshell means that you can prove something is incorrect but you can't prove it's correct that's that's really important to to understand right i hadn't considered my unit test like that but yeah it was weird it really is right because you've even talked about like over time a little bit of a mind melt there yeah it kind of

stinks like if you think about it because over time you've even said you know man i had like 20 unit tests around this thing and then and then i found this other edge case right so you had proved that it was as correct as you knew it to be but you couldn't prove that it was you know completely correct because you can't think of every single edge case out there so it's an interesting notion to take away from that yeah i think the major takeaway from this section was just that structured programming gave us a good mechanism for transfer of control mainly by eliminating um things like go to and emphasizing this decomposition into a like a nice clean hierarchy yep you want to take oh outlaw Like OO Outlaw? Is that because it starts with an O? Sure.

Yeah. Sure. Outlaw has those. So object-oriented programming brought us polymorphism? So there were some of the main benefits of object-oriented programming are incrementally better than what we have um there was actually i think it was in this chapter where he said that it you know where object-oriented programming didn't bring us anything it provided nothing new was the quote that he actually said yeah it's yeah it's a pretty big smackdown of it like and a lot of the concepts kind of talked about like this is what o is kind of touted for and here's why it's kind of you know not not so

different yeah so like if you were to ask you know your typical kind of interview type question you might hear something like uh so what's the benefit of object-oriented programming or maybe that's like you know a topic of conversation in like a classroom or something like that and you hear you often hear this um and i mean we're probably even guilty on this show of saying it in past episodes that uh you know the benefit of object-oriented programming is that you can model things after they quote real world right um and i think we've i think we've even talked about like uh the ability you know animals versus specific animals and how the inherited

structure of things like that right right but he made this awesome uh you know comparison i don't know what to call it okay fine correlation where he was saying that hey before we had like one of the things things that people give credit to object-oriented programming is encapsulation, right? But we actually had better and true encapsulation when we just had plain C. And he gives this example of how in C you would define something in your header file, but then in your implementation, you know, those things were totally separate. And so anything that included your header file, it knew nothing about it, no implementation details, purely new signatures. And that was it. But then, you know, fast forward to languages like C++ and, you know, everything later, Java, Cava c sharp whatever you started that encapsulation got

weaker as we went forward because things would start to leak so in the case of c++ you had to start putting some of the details of your structure into your header file in order for the compilation to work right so you might have to put some of the member data of that class in the header file. And so it was, it was a sort of leakage of information that started to break some of that encapsulation. Like maybe,

maybe you didn't depend on it, but you knew of it. Right. And he goes on to say that, you know, the inheritance was incrementally better than where we were, and it's more formalized and safer now, but it's not so good anyways. And then the benefit of it providing the polymorphism was really trivial, right? Well, it made it trivial.

Oh, sorry. Yes. It made polymorphism trivial to implement. Much easier. In the newer languages, right? Hey, going back real quick before you. So one of the other things that he did mention about the whole encapsulation is weaker and i thought this was interesting is when he said that when you look at java and c sharp and all that they had to introduce basically hacks in order to keep things

encapsulated so the private the protected all that that was literally just a hack in order to hide those implementations right whereas going back to the C days, again, you had a separation, a true separation of it. So I thought that was interesting because we kind of, we look at it, we're like, oh, this is a great feature of the language. But in reality, it's sort of like, oh, this was bolt on to accomplish what they had already been doing back in the day. Now, granted, there's some differences, right? Like with the protected versus the private and all that kind of stuff but it is an interesting thought to approach it

that way yeah in in fairness the way he he worded that wasn't that it was necessarily so much a hack as it was that it partially repaired uh the encapsulation yep right um yeah yeah so yeah Yep. Right. Yeah. Yeah. So yeah, the magic main point was that like when C you kind of had this like forced interface because you had to use these dot H files if you wanted to be able to communicate like, or someone to be able to communicate with you outside of your file and C plus plus weakened it by exposing those member variables and private variables in that dot H file.

C sharp Java, those guys just got rid of that H file and they reintroduced those, you know, the, the scoping. So you could control that, but ultimately like people are still seeing that stuff. If they're looking at your code or,

you know, and, and interfaces are a way to bring that back, but they're not required. And so a lot of people don't do them. And so it's like this kind of optional weird thing, but yeah, just like you said, like it's weakened it like iteration after

iteration um so it's kind of funny because that's something that you would typically have named as a strength of oo yep yeah he i don't know about you guys but as i was reading this chapter um i mean he makes a strong case for going back to c and i know that in our slack channel alan had a conversation where he's like you know you ever feel like you just want to go back to the days of like a c plus plus and this book makes a stronger case that you should go back even further yeah that's that's yeah i don't know why i said that yeah i saw those stars in the uh the pointers in the examples of the book i was like oh man i'm so glad i don't have to deal with that and just even the variable names and stuff that i've seen in c code like i know that it doesn't have to be like that but

i'm thinking about the dot h files i've seen it's like hey my p2 star returns a p3 c1 star you know and there's a underscore m somewhere in there it's like what the heck is going on hey have they have they created a garbage collector for that yet i mean i need a heap that's right all right so yeah um continuing on there what you got yeah i'm trying to remember where we left off so uh i think joe covered that you know the interface is making things more formalized and safer uh and that the interfaces will allow for safe and reliable indirection yeah and just real quick on that um so the reason that interfaces made things better is that in like the c world like you would basically just kind of treat

something as if it was another object. And if those kind of memory locations happen to line up, because you kind of put stuff in the same order as the other guy, then it just worked. And that's how drivers work. There's a couple other really cool examples in the book of like, where things like you just kind of specify this stuff in this order. And when you like use this object as that one, like it just kind of works and everything's good. But if somebody comes along and kind of mucks with one of those, then suddenly you've got stuff happening out of order.

It can be really hard to debug. You're calling invalid memory locations. Who knows what's going on? You're kind of doing a little bit of weird go-to there yourself. By having these interfaces, now we've got compile-time support, or depending on your language, maybe runtime support for something. So it can tell you, like, nope, this can't be done this is not safe operation yeah i really didn't like the example that he gave with the the struct where you had two that were like you said because they

coincidentally were um you had variables or members let's call them of the same name in the same order in the same place of the structure, then yeah, you could cast one as the other in order to, uh, you know, access that same region. But like you pointed out, I viewed that as like extremely dangerous. Like that's, that can't scale. Well, maybe, I mean, one of the examples they gave was like the standard in and standard out in Unix.

Right. And the fact is you, you're coding to a contract, which is all an interfaces anyways, except, you know, back in the day, that's just what they did.

It was a plugin architecture, right? As long as you took the same shape plug and stuck it in there it worked right so it may sound dangerous and true right it is there was there was no formal really thing that defined other than the fact that hey this plug has to fit and and when you think about it that, that's what they boil this entire section down to is that is what OO bought us was the ability to swap in pieces. It was all about this whole pluggable architecture and controlling the dependencies because that's really what it boils down to, right? Is once you can swap those things in, now you can control where the dependencies lie. So in that example, okay, so, I mean,

obviously you got to make a joke then that like, so you're saying Linux and Unix scales then since those were Unix examples. But I mean, that type of contract, as you're calling it though, it wasn't something that was enforced by the compiler. And that's what I mean by like it's it it's kind of dangerous right yeah as far as contracts go it's a fist bump yeah yeah exactly but so i think i kind of jumped the gun on that so we were talking about so the oo didn't add that ability to have the plugs right that was already there like what we were just talking about the oo gives you that compile time safety with that but what he was getting to was

being able to control the direction of dependency so in when you think about going all the way back to episode one i believe is where we talked about is for interfaces right so the whole notion is if you have an interface you have a contract of what can fit there and now if you do that you can control the level or the direction of dependencies and a lot of this really depends on dependency inversion or you know inversion of control type stuff to where you inject some of these well let's not mix those two well it it sometimes goes hand in hand with it because right now if you inject some of these well let's not mix those two well it it sometimes goes hand in hand with it because right now if you create something of a type object like he even had a nice little tree and in the book that shows the way that typical dependencies go right like you're

going to have this top object which is main and then if you need to instantiate anything under it then it's going to create another object then it's going to create another object. And that's going to create another object, right? The difference is when you start having polymorphism and you have things that adhere to a contract, now you can just swap those pieces in. And typically the way that you'll go about doing that so that you're not having to new these things up in your code is you'll use something like dependency injection, right? So that you can have that swap it in at runtime or, or whatever. So it allows you to control the direction of which these dependencies go. Like if, if, if you have a business logic layer that is I business logic layer,

and then you have, you know, an I storage layer, they don't really care about each other. You just know that you need to plug one in. And so those, they're not hard, fast, this points at that type thing. Yeah. The reason why I very,

where I said like, let's not mix those things. Cause you know, with inversion and control, and then you brought up in dependency injection is the dependency inversion is just the direction of what knows about what it depends on. Okay. Right.

And so that, that's why I want to be clear and just kind of stay on that with, um, cause when we, cause that is the D in solid coming up. So I don't want to confuse those things, but, um, there was another great point in here that I hadn't really considered like this. Cause there's a lot of statements that he makes in the book where, um, kind of like the one you alluded to a moment ago about like uh object oriented imposes the discipline of indirect transfer of control and there was the statements i made about math is the discipline of proving provable blah blah he says that uh polymorphism is an application of pointers to functions

yeah and i was like oh yeah i hadn't considered it like that, but I guess if you had to like break it up into as few words as possible, he would win that lottery. You know what else I like is the whole plugin thing. And interface is literally saying you can plug in anything of this, right? We've talked about contracts, like you have to adhere to this, but a lot of people can think of a plugin, right? And it's easy to say, well, if you have this plug that fits here, then that's the interface, right? If you have that interface, any plug that fits that, you can swap it in. And I really like that. It makes it really easy to visualize in your head why you should have an interface.

Yeah, I'm totally so bad. I was really excited to read this chapter and like i've been a big fan of interfaces for so long and just like kind of hear him say like this is the ultimate power this is the reason for oh this one thing is why oh is still around interfaces so i do want to ask you guys on interface this and i want to bring this up because this is totally side topic to this, but it's directly related. I hear people all the time. Why are you making an interface for that?

Right? Why are you making an interface for this? And I argue it a lot, right? In terms of why a lot of times, if it's a DTO, I can't give you a single good reason to create an interface, right? I really can't. If it's just a dumb object that has no logic, no behavior, no nothing,

it's just a bag of data. I can't think of a single reason to create an interface. I may be wrong. On the flip side, if it's anything that has any behavior at all, I pretty much think you should make one. And I don't know if it's anything that has any behavior at all, I pretty much think you should make one. And I don't know if that's necessarily a perfect catch-all rule, but it feels like it is.

I think we've addressed this before in a previous episode, though. And one of the things that we had said was that maybe not for that first use of it, but when you find that you need a second, that that's where you would maybe introduce the interface and use the interface. Because I think, because yeah, I've kind of gone back and forth on this too, where it's like, okay, I know I'm only using this thing one time,

but I'm gonna go ahead and create the interface for it so that if I ever need something else to implement this interface, then I can. And then then you end up finding like maybe you don't ever create that second one but yeah i'm really torn because you do set yourself up for like maybe a future success by only allowing other things to be dependent on your interface i don't know and that's not over complicating things in my opinion because at that point you've you've followed that o part right the open for extension closed for modification type thing and that it feels like adding one file or one implementation thing is not really that much extra code you know joe what are your thoughts i know i know you are

like heavily opinionated on interfaces so i'm curious yeah i love them but that doesn't mean i do them all the time like i definitely try to kind of do things with a more kind of practical bent so you know i like well what i'm about to say is totally different from what i do but i think based on the reading that i've been doing what he's kind of saying is that by having those concrete classes in there you're kind of like spreading the volatility right it? It makes a good case for interfaces changing less often because anytime you change an interface, by definition, you have to change everything that implements it. So that means that the things that implement are going to change more

often every time you have a bug fix, every time you have a little whatever it's changing more often than that interface so by definition those interfaces are more stable and as we know like with testing and other things it could be really hard to kind of pull stuff out at a later time i like that kind of like so it forces you to really think about changes first right so yeah and there's one other reason too that i think it makes sense to declare that interface up front is that if you don't have that interface in any other code that depends on that concretion, that volatility needs to recompile every time you recompile that concretion. And that's because they're they're tightly bound to each other, like de facto. But if you've got that interface there then you can change that class underneath and not have to worry about that other system at all and you you can see like without a shadow of doubt that these things don't affect these other things until you're

drawing hard lines around your code that are kind of hard to do after the fact okay so going back to the dto example though would you do an interface on a dto i have but i don't feel good about it so uh let me give you an example i just did this recently in the game i was working on so i've got like these randomly generated levels right and um and you're a little dude you'll like walk around and kill other you know people whatever aliens and um it's all randomly generated so i've got these lookup tables where i can say, hey, this is the map ID. Let me get all the items. And I have like a weight table.

So it says like this, you know, health items like appear five times more often than weapons or something like that. But I also have a table like that for creatures. And so I say this creature appears three times more often than that creature. So these are two tables that have similar type columns. And so I've got a DTO for creatures, I've got a DTO for items, and both of them have like a weight on them. And so I slapped the interface on, so I had a single method that basically says like, hey, get me a random something, and it takes the weight into account.

And so I did just slap an interface on those DTOs, even though I don't like it because I feel like it's like kind of pushing some behavior type emphasis onto something that shouldn't have it. So I still don't feel good about it, but I absolutely did it. So go ahead. I've definitely done it on request response type DTOs where I'll have multiple responses and they have the same structure going back.

Okay, I can see that. Alright, I mean those are fair enough. Alright, I'm with you. I don't know that I really like it. In my case, I definitely felt dirty. And I knew that I could have normalized the data differently

in order to kind of have one sort of entity ID table with the map ID and the weights in there. But for me, it wasn't practical to have that sort of abstraction. I'm dealing with a much smaller, I've got like 10 tables in my database. So it just didn't seem like it was worth it to add another table just for this. Yeah, I got you.

I mean, that all makes sense. And I just realized for DTO, for anybody that's not aware of what that is, that's just a data transfer object. It's literally, hey, I have a database table over here. I need to get data from here to my application, right? That's usually what they're used for is just moving data from one place to another. Typically, very little to no behavior, right? No behavior. Yeah would be that would be like a poco or pojo right a plain old class would have behavior one that has no behavior but data only would be a dto yeah so i could see it sort of in the request response thing it's an interesting thing like it

and i get the decoupling so that you only have to compile one side versus the other so that's even another place where i typically wouldn't have done an interface but i could see why but for the most part like anytime somebody argues the fact with me i'm like man i like i don't want to try and convince you you know if anyone's going to argue my pull request because they're like wait a minute i don't like that you introduced this new interface and it's only used by your one thing here and i'll be like what yeah what does it matter you're gonna argue about a pull request for over that right it's it's just interesting you should have seen all the other code i wrote if that's what bothers you yeah well what's funny is like a lot of times the interfaces that i write are in the wrong spots like i'll have like

interfaces my tiny little you know area of like a you know my uh my what's it called the uh diamond in the rough right where i've made this little gold-plated module you know and so i've got my little interfaces there and you know everything's testable whatever but really what i think i would get more benefit from at least you know the swarm come from in the perspective reading this book is like it'd be really cool to have a bigger section of my code modularized and behind the interface so i could define like the um i don't know payment processor module not my little you know i pay you know whatever like the whatever dinky little interfaces i'm doing but what i think i'm kind of thinking about in terms of this book is just um having those interfaces at a much higher level than i normally think i i tend to think of like interfaces and tests going hand in hand and i

come from that perspective and so i tend to end up like when i'm going down this road with a lot of little interfaces but now i'm thinking it's like if i had been thinking about this stuff as more of a system then maybe i'd have some sort of like enemy spawning module or maybe just the spawning module that has an interface that kind of is higher level than my little dto's because that's why the dto thing is wrong but it just it's because that's what the external parts of the system will interact with right that's really what it boils down to is how is this thing going to be used and it's drawing those lines in your system so yeah and if i had that interface there like the spawning module level then i could have like a say a map for example

that constantly spawns enemies or i could have a map that has a fixed amount of enemies and you know i could just have these different kind of strategies that are involved there and i could plug and play these whole systems yeah i could create these pluggable architectures which is kind of like the whole point that we're talking about here yep cool all right so i guess i will kick off the next one which is uh functional programming and it's interesting because this one's really short and essentially it buys us correctness at the cost of performance in many cases because the whole purpose of functional programming is immutability basically you can't change the meaning of a variable once it's been created that's what it is and if you want another one you create another variable right like that's basically what it boils down to i didn't get the the cost of performance though

so we'll get into that mentioned it yeah we'll get we'll get into that it's it's it's basically like when we talk about the event sourcing thing here at the very end which was interesting so so the immutability thing and then there was the uh redirection right there's this whole thing that you can keep redirecting to to kind of chain things together because you're never changing the state of the original thing. It just keeps building on it. So that's interesting. So the event sourcing thing, and I forget exactly what the definition was. I'd heard of it before, but I'd never actually thought about it too deep in terms of what it meant.

But you mean say it it's the rebuilding. Go ahead. Event sourcing is a strategy wherein we store the transactions, but not the state. Okay. So this is where it could be at a cost of performance so the exact one of the examples he gave okay was think about this you have a bank account and you start out with whatever you deposit in it right and instead of you just storing every you know hey i added five dollars now i have ten dollars i added five more dollars. Now I have 15. Instead of that, anytime you want your bank account balance, you have to take the beginning state and apply all the events that have happened since that point in time. Right.

And what he said, and this is interesting, right? What he said was this wasn't really all that possible several years ago because we just didn't have the computing power for it and you might even think that that's kind of crazy today like you would never do this but look at git that is what git does git takes your file and it applies changes over the entire spectrum of of changes that happen and that's how you end with your last file so it's possible and there are still performance implications of it, but he even said, if you wanted to take this and because as a developer, you have to worry about state, right? You always do now it's just where you store that state and how that's handled. So the functional part of it is it's not going to

mutate that state, but you can take that and save it off. So maybe you can't go to your bank account from the beginning of time, but maybe you have a, a set point at the beginning of every day, right? So you can have these checkpoints and then you build off those during the day. And actually your favorite thing,

Joe, the SQL server, like the, the, when you talk, is it his favorite? I think it is. When you're doing differential backups on that

thing that's basically what it does right it snapshots a point in time and then it does differentials on that and then the next time you go to do it it'll snapshot it and then do differentials on that so it's truly building it up so so it happens it exists right now event sourcing is a thing and this whole computational thing and the processing power required. Like we've sort of reached that point to where it's available. And so immutability, functional programming, it's, you know, it kind of plays hand in hand with some other things. But it was an interesting take on this stuff. Yeah, and because of the immutability, you're looking at a total lack of side effects.

So things like race conditions deadlocks um coherent update problems just kind of disappear so if you've got some sort of system that does some sort of you know critical math account you know bookkeeping type stuff like it's worth considering having like a little functional section of code or an application or service or something and if you can push more and more of your code out to these areas and it's a good way to avoid some really tough problems so he's just kind of mentioning as like a tool in the belt like it might be really tough to base your whole business around you know haskell services but there might be some parts of your system systems that would benefit greatly from

being written in a functional way and we've talked about this in the past, that everything that you can write functional, if you do write it functional, it'll make your testability way much, much, much improved. Because it's a lot easier to test those functional methods than it is to have to worry about state. Yeah, I mean, because in functional programming,

it's item potent, right? Like basically everything that comes in, there's a guaranteed result. You call a thousand times, you're going to get the same result because your state's not mutating. So yeah, the testability part of it's amazing. But as we know in applications,

a lot of time you have to depend on state. It's just how you interact with that stuff, which we talked about in domain-driven design too, right? You're not going to be able to functional everything. Right, right. And so if somebody tries to tell you to do that, you turn away and you walk out and be like, I can't talk to you anymore.

Yep. So this actually was pretty short, but it's just kind of a cool little idea there to keep that tool in the belt. But just to kind of recap on the programming paradigms, structured programming gave us direct transfer of control. OO gave us indirect transfer of control. And functional gave us discipline of assignment. But each of these, do I have to say paradigms?

Paradigms. Each of these paradigms takes away something from us. It restricts us in some way. Yep. And software isn't advancing as fast as we think. Take that JavaScript. I think that was Joe's comment there. And here's the other thing, right? And whoever put this should read it because so uh going back to what alan just said about the software isn't as fast in vat yeah easy for me to say isn't advancing as fast as we think the rules of software haven't changed since they were originally documented so you know during these chapters leading up to this you know he goes over the various history going back to like 1946 where it's like oh well there was this concept that was documented here and then, you know, later concepts. And, you know, he gets to like, okay, all of the, all of the topics that define what

software is were discovered, or if you want to call it that, or documented in a 10 year span. And they haven't changed since then. Everything that we do in software is still composed of sequence selection iteration inter uh and indirection nothing more nothing less that's it yeah isn't that crazy it doesn't matter what new technology we're talking about it's still the same yep and without that kind of level of indirection if you're working in an oo language then you're kind of still doing structured programming with some sugar a little bit of o mixed in maybe yep something to think about and then it's funny a lot of people are like you shouldn't

do you should do you know compositional type stuff so it's funny how this stuff goes back and forth over time which is sort of mixing the functional with the o stuff so like you said programming is hard and programmers are bad at it. Exactly. We're hoping to make people less bad at it, including ourselves. We won't exclude ourselves. All right. So the next chapter we get into is the design principles. And we actually had an episode on this. And for whatever reason, I never look it up.

It's the episode seven. And we heavily referenced Steve Smith's uh Pearl site videos which I mentioned at the beginning of the show that's the guy who uh who did the course that I got a freebie and did a review of can I can I say he makes some solid courses yeah he makes he makes a lot of really solid courses actually I looked him up on Pearl site uh really quite quite the resume there yeah that is a solid recommendation that is that is i like it so so we're going to briefly touch on just kind of go over a quick definition of these solid things and and we're also going to put the spin of what he means by architecture lever leveraging the

solid because they're solid within code and then they're solid at the architecture level so what he talks about is what most people are used to are the mid-level software structures and the whole purpose of solid is to make those things tolerate change they're easy to understand and they're the basis of components that can be used by many software systems but what he wants to point out in that is you can have great patterns in your software right like when you write your code it could be the most amazingly patterned up code and everything but it could still end up being a mess because it doesn't interact on on a whole level with the rest of your system right and so that's why he wanted to make a differentiation between what is the solid that most people talk about versus what

is solid in architecture so to i thought of a way to illustrate that you could create let's go back to joe's game modules that he was talking about right you can make all these various modules and each one independently could be beautifully written code right and and by themselves they're all they all adhere to the solid principles but when you try to compose them together into one application you could still get yourself into a diamond dependency scenario or we've just talked about dll hell right and that's where where now you made these things pretty at the low level, but when you get into the higher level architecture, you still have a mess. Yep, totally. That's perfect. That's a perfect example. And it's not hard to do that, by the way,

right? It's really not hard to make a mess out of clean stuff. And actually, I wanted to point out there are really good tools for helping you prevent that mess. Like I made a video a while back on my game where i was looking at using end depend to figure out where i was basically i had mutually dependent namespaces and another way of saying that is i had arrows going both directions so i didn't have a hierarchy i had a cycle and so i was able to use the end depend to kind of figure out where the problems were and reorganize things a little bit. And it's still a mess. And it feels like a mess when you work on it.

Static analysis. Yeah, static analysis can help with that stuff. For those not familiar with independent. There was another tool that one of my buddies, Momolu, had actually told me about before. It's called Sonar Cube. I'd never looked at it, but it's something else that's interesting. I will put a link in here somewhere. Yeah, I saw it in a meetup.

It looked amazing. And it had that same kind of notion of it would give you like hours of like technical debt. So you kind of see it coming up and going down. I know that's not the main point of it, whatever, but I still thought it was a really cool concept. Well, it's another static analysis tool, and it has team services integration support. So you can include it in your build pipeline. You can do the same thing with independent except you know the independent doesn't

have a specific team services integration that I'm aware of. Yeah I don't think it does. And just for the record it's spelled sonar Cube, Q-U-B-E. And I'm putting it in the resources we like. And by the way, Endepen now does have some integration with VSTS and some extensions.

Very nice. So let's get into the solid principles, starting with the S. Single responsibility principle. I want to do this one because there were some things that I liked on it. I thought it was stupid repository problems. That could be part of it. If you ever deal with large teams, that does come up on occasion. So the single responsibility principle

is there's one and only one reason to change now that's the you know code developer mindset definition of that thing right the mindset in the architecture i really like this so he goes through it all i'm going to give you his end definition on it but he kind of steps through it and is like well if you do this then that becomes a problem If you do this and that becomes a problem, what it boiled down to was the final definition in terms of architecture is a module should be responsible to one and only one actor. So think of like the stakeholder of the system or whatever the actor. And that's really important because the example that he kind of goes into here that I really like is, let's say that you have a CTO, a CFO and a COO, and they all have these things where they have

to calculate pay. They have to calculate overtime and all that in good OO design. If you're a developer, you're going to be like, okay, well I have an employee, right? And then that's going to have calculate pay. Well, let's say that the CTO and the COO have different things that they use to determine what the pay rate is for overtime. Well, if you as a developer go in there, you can write all the unit tests in the world and you can go in there and you can say, okay, yeah, the CTO came to me and said that, you know, we need to change how this, this overtime is done. You put your unit tests in there, everything passed. That COO had no idea that you were

changing that code. And so now, yeah, you've got a good OO approach to it. But the problem is, is you've now broken it for another actor that was tied to that piece of code. And so that's the architectural piece of this that really matters because you affected an actor who had no idea. And that's a problem. Yeah. I was actually thinking back towards times where not because you created the change already, but because someone asked it and you're like, well, yeah, I mean, I know you want that, but then you're going to affect this other department. So we can't make the change that you want without impacting them too, as it currently exists. Yep. And it's interesting because there's a lot of approaches to fix this.

I mean, just thinking out loud, you'd be like, well, what if I made the CTO, the CFO and the COO their own classes? And then I'm going to have to make their own implementations for that. But now you're duplicating code all over the place, which kind of stinks. And he pointed out a couple of things that I thought were kind of interesting, which were, okay, maybe what you do is you abstract away the data tier of that. So that calculating all that stuff, the data tier is what brings the stuff in. And then those methods operated on it, right? That may not be perfect because maybe that data tier crosses boundaries and that doesn't work out. So another way you could do this is instead of having the employee

class, you have three separate classes or maybe you break it out differently to where you're not even doing it based off the actor. You have a pay calculator, an hour reporter, and an employee saver type thing. And then you have a facade on top of that. So that's another approach to it, right? So basically you create this nice little intro or interface into the functionality you need, but those are all broken apart. And then they even had another one that you could do right so you have this employee but now you just break out the methods and this is where it was kind of interesting is let's say that you have a calculate pay and you'd have a calculate pay for the cto the cfo and the coo and he said the argument that you'll typically get and you will get this is why are we creating separate classes

for one method and his argument it is, okay, so it looks like that, but that's usually not how that breaks down because there's probably a ton of complex business logic in there too. Or, or maybe even if there's not a ton, there's enough of it to where it's different enough that you're going to have hidden implementation. So you might only be exposing that one method, but in reality, you got three or four or five or ten private methods in there that are doing work on that so that's a bunch of different approaches to solve that problem architecturally so that when you make a change to the coos you know calculate pay you're not messing up the cto or the cfo right so hey you got an ide right you just f 12 but I do I do have to wonder like when we talk about stuff like this and we talk

even about like dynamic languages and some of the rubies and the pythons and javascripts of the world don't have like formalized interfaces stuff like that like is anyone doing this kind of stuff in the pythons in the javascripts in places in dynamic languages basically I would

say okay so maybe that's where it's not fair, right? If you're using something like TypeScript and JavaScript, it makes it a lot easier to do things like that. Yep. It almost forces it down your throat. I'm kind of wondering, is clean architecture assuming that you're working in a C Sharp or Java or it's just a static compiled language?

That's interesting i mean yeah because javascript doesn't enforce anything ruby doesn't enforce anything you can cram it's on you to enforce it right it's it's basically it's yeah it's completely on you and there's no doubt you're going to be getting file explosion here right all right i guess it doesn't say you have to create simple separate files for every class but i mean you're going to be getting file explosion here, right? I guess it doesn't say you have to create separate files for every class, but I mean, you're creating separate files for every class. Well, if you don't, then it's hard to manage anyways, right? Like, does anybody hate it

when people put two classes in one file? Oh, it's such a pet peeve. I don't like it. There was another example in here that he gave though, which is where, you know, I made my joke about the stupid repository problem. He talks about like, well, what if you have the CTO and the CEO, each need a different change to the same area of code.

So two different developers make a change. Now they need to merge, right? So now you have a merge problem. And there was one that I thought, a statement here that I thought was particularly relevant to some conversations we've had outside of this conversation where he just says, merges are risky affairs. They are. Man. Okay. So another side conversation.

And we're not going to go too deep into this, but somebody said something, our friend John said something the other day that I can't believe never hit me, but it was such, it was like a revelation. Why is it? I don't, why is it code gets tagged for release? You have something in this branch over here that's being tested, but before you tag it for release, you merge that code into another branch that's just because that one process though that's not necessarily that's how it's done almost always right like you you typically merge it back and you tag it like why master is or your or your trunk depending on whatever your your repository is that's typically what you do right like you merge it in and then you tag it there and you release from that

branch. And I took it as more like he was pointing out like, Hey, this is an improvement we should do in the process. Maybe, but that's how I've seen it done. Mostly like usually there's a merge before tagging, right? Like, Hey, we're going to put this in our main branch, right. Or our main code trunk or whatever you want to call it. And I thought that was crazy that that is how it works.

I never really thought about it. Well, I was thinking more along the lines of never doing the merge. That whole conversation about never merging. Oh, yeah. I didn't like that at all. I still don't like that. We need an updated source code etiquette episode. That was episode three.

We do. We have lots of things to add to it now i don't think world war get basically the never merge because i know that i said that and then people are like wait what the never merge option is imagine if you had your master branch let's talk get you're in you're in your default master branch, and then you branch off of that to work on your next release. And when that next release is done, you drop master.

You drop that branch. You create a new branch called master off of that other one. You're basically renaming that other branch to master. I know git doesn't you can't rename branches so let's avoid the semantics of that but let's just say that you drop the original master branch you rename the existing branch as master and then you create the next dev branch off of that new master so you're never merging your development branch back into masters where that conversation came from and and it was just kind of the timing here was interesting that here's here's our buddy uncle bob telling us that merges are risky affairs and they are they totally are and yeah and he knows everything so yes him michael

feathers and uh martin fowler if it's if one of those three didn't say it then it's probably not true so with that let's get into the o theosed principle. I lost my place. So this is a system can be changed by adding new code, but not by modifying existing code. In short, you're open for extension, but closed for something. Closed for change. Yeah, whatever. C words. something close for change yeah whatever c words indeed it's late come on it is the rest of development uh the name of the boat

anyway um i really like the idea of this um in principle it's it's fantastic like imagine being able to change something without having to change any code like everything's additive which is funnily enough a common problem at a lot of places like people keep adding new code because they're kind of afraid to touch the old stuff but in this case your code is so clean and so malleable you're able to kind of make your new changes in there and reconfigure things so that you're kind of using this new flow and so the idea that you don't have to change much code is really fantastic. It's like if it worked once, it still works. So that's at the code level.

Now, the interesting thing that they pointed out on this one, though, that thing should never be impacted by changes to lower level code, which is the whole idea of functions and classes and all that stuff. Right. But if you, if you picture it, think about like your core business logic for your application, that should be almost at the top of your hierarchy, right? That stuff is pretty well known, pretty solid, should never change really, depending on anything, unless there's a new business rule that comes in, that thing shouldn't be touched. But if you have like a view or report or some, you know, different views that exist down

at the bottom of that chain, those things should be able to be added to. If you have a web view of something of your data, that should not impact your business logic, right? If you have a web view of something of your data that should not impact your business logic right if you have a new report view of that that information that should not impact your business logic so that's really what this is talking about is in code we talk about this open for extension and and you know that's dealing with modification that was the term i looking for. So you're not ever going to open that code. In this case, you're almost talking about modules of the system, right? And that's really the difference. Instead of getting down into code,

we're talking about entire pluggable pieces that come in. Well, think about microservices. And now you think about one of those services has to change. And so, you know, know your order system now can do split shipments and so now your order processor and any other services that touch that need to be able to deal with split shipments like that can be a major pain in the butt to roll out like how do you roll out these services at the same time or roll them out in such a way that it's like you know you can handle both or whatever it's a big pain in the butt but that's kind of where

this principle kind of comes in and we're saying that like if we don't have to change these existing services we can kind of add new stuff on top of or kind of compose these things a little bit better i think it might be a little bit of a pipe dream to kind of think you can just kind of keep wrapping services with services in order to kind of compose things without changing that often but i think it's still a nice idea to shoot for yeah it's a good goal, right? But I mean, this kind of goes back to the example of the device driver. Yes.

Talked about before, right? Is that because it's this kind of pluggable type architecture, right? Like when we talk about open for extension, but closed for modification at the code level, we talk about examples like what you described there, but this is now trying to rethink some of these principles, but from an architectural point of view. So if I want to add in that new device driver to Linux, I don't have to recompile the kernel in order to be able to use it. Exactly. I like it. Here's the thing. And Uncle Bob Martin said it at the beginning of the book.

This stuff sounds like a pipe dream, but he's seen it work. And when it does work, development is so easy, right? So maybe it's worth striving for that pipe dream in this case, right? Make sure that you're doing things when you're building systems to where you really take. And you guys remember in the first episode we talked about, you have to fight for it. Like you, it's your job as a developer, as an architect, as somebody who cares about this domain of code. It's your job to make sure that you're pushing for these things. Yeah, I mean, he wraps this up by saying that for this particular portion,

you're trying to accomplish this goal by partitioning the system into components. And then as it relates to the open-close principle, you're going to care about how you arrange those components into a dependency hierarchy so that you can protect the higher level components from changes that happen lower level. Yep.

Yep. All right. Who's doing the beg? Oh, yeah. We didn't put anybody on it. I'll do it. I haven't done it in a while. All right.

So let me say then, if you have already left us a review, we thank you very much. We love to read those. They put a smile on our face every time. And if you haven't, we ask that you head to www.codingblocks.net slash review

and there you can find links to your favorite aggregators that leave us a review, and we look forward to hearing what you have to say. And with that, I think we head into Alan's favorite portion of the show. No, it's my favorite portion of the show. I got confused because we were trying to define Joe's favorite portion of the show, and I forgot my own portion of the show. I got confused because we were trying to define Joe's favorite portion of the show. And I forgot my own portion of the show.

We can't have nice things. Does that mean that you don't truly have a favorite portion of the show? You can't even remember, man. I know, right? All right. I'm still like, I can't remember the open-close principle. So, yeah, my whole night is shot here. It is.

Yeah, so we head into my favorite portion of the show survey says so last episode we asked how often should your employer replace your computer and again if you were self-employed you count as your employer so your choices were every three years every two years every one year or who stays at any employer long enough to have that problem or wait they're supposed to replace it or greater than three years Three years. So let's see. Alan, I'm going to pick you because your name starts with an A. That's logic. Yeah.

I'm going to say every three years with 40%. 40%. Yeah. All right. Joe? I'm going to go with every three years at 30 every three years 30 okay well you're both wrong nobody stays an employer long enough you know i put that one in there and i really expected that was going to be the the runaway hit and surprisingly it wasn't

every two years 40 of the vote interesting let me get on this email then yeah now now uh every three years did take that was the the number two answer with 31% of the vote. Oh, okay. So how much was the percent on the every two years? Did you say? It was 40. 40? Yeah. Okay. So I got the number right.

That was close. I said 40. Yeah, you had the right number but the wrong answer. Joe had the. No, he didn't have any of it. Well, he had the right number for the wrong answer. Right. Yeah.

If I'm saying that correctly. I don't know. Open-close principle. Yeah. Yeah. So, in today's episode, we ask, how often do you replace your phone? Do you replace it every year because you got to have the latest tech or every other year or not until it breaks and even then maybe not even then

yeah i know the answer to this one what What? No, don't. This is a fixed answer. It's every year. Is that the answer? No, it's not. Oh. No. Well, I think the three of us would already be all over the map. I'm going to say I would be every year.

Alan's going to be every other year. And Joe's going to be not until it breaks and maybe not even then. But the reality of it is that's what I say. But the reality of it is, is Joe is absolutely not until it breaks and maybe not even then. I am every other year in Alan is every six months to a year. No, I'm actually every other year. No, you're not. You have way more phones than I have. No dude. Recently. Yeah No, dude. I know. So my, my, it's literally every other year, except for when I bought that windows phone, when I bought that windows phone, some, you know, 20 years ago or whatever that was 20 years ago.

Um, no, it's been, it's been right out of every other year. Yep. Uh huh. Mm. It's like every other year for the iPhone and every other year for the Android. No, no, no. Mine's truly every other year for me. So.

All right. If you say so. Well, yeah. I mean, you guys, you guys nailed me. So I'm surprised. I'm surprised that Joe hasn't been talking to us about his pixel too. No, no headphone jack. So. Oh, not oh not doing it ruined it for you huh yep wait what version of the iphone do you have six you're on the oh so you have a fairly new one what that's two years right no the six then

there was the 6s then there was the 7 now there's there was the 7, now there's the 8, and then the 10 is coming out. Wait, but didn't the 7 and the 7S come out? No, there wasn't a 7. No, there wasn't a 7S. Yeah, that's what I'm saying. So there was a 6. The 6S. But those were separate years? I can't remember anymore.

Those were separate years. They started doing things at the same time. Like, now they have the 8 and the 8. No, they just started that with the 8 and the 10. Okay, so it's two years. I still live in Georgia. I mean, he's- It was two jobs ago. Whatever, four iterations back. So it's two years i still live in georgia uh i mean he's two jobs ago whatever four iterations back so it's been over three years oh okay yeah yep oh all right and i'm still i still miss my

forest which i had before it yeah you like the little itty bitty phones i i need that video That video you sent. Carry around a Thunderbolt monitor. That's what I want. I mean, it is crazy, though. If you think about it, how everything is cyclical, right? So there's this period of time where everyone will go to or go towards wanting everything to be smaller. And we got to the pinnacle of that with cell phones. And I think the Raz the razor the motorola razor was it right and then there was the advent of the smartphone and those stayed kind of small and you know easy to use with just your thumb in one hand and easily fit in your pocket and we had

this great generation of phones that were like that right and then it was like hey let's start making these things bigger and bigger and bigger it's because they're used for more now and now they don't fit in your skinny jeans and you see somebody walking around where like half the phone is hanging out of their pocket and it's like that's about to fall well the cyclical thing though that's i mean you got to stop wearing bell bottoms i mean but they're so comfortable man but you. The flip phones were big in America, but in Europe, and if you knew some, I knew some Bulgarians that would get their phones from Italy or something,

they had these little things, they would hold it like a pencil up to the ear. It's like, they would have to move it between their ear or their mouth, depending on whether they were talking or not. We're ridiculous as human beings. Yep. Alright right who's got who's got list off i got something uh i got something before that actually um this is not my favorite section but i do like it um and uh this is where i'm gonna ask you guys a question about it's his it'll do section it'll do that that fits that fits me nicely well um so

we do these uh jet brains giveaways every month we have three licenses to give away so if you're not in the mailing list you should join because uh you respond to emails like this asking you for example what your favorite horror movie is because it's that time of the year and there's a chance that you're going to win uh one-year license with a fallback perpetual, whatever. We'll send you the details if you join the mailing list. But I did count up the emails, which is very time-consuming, by the way. And I graphed them, which was also very difficult.

Pie charts, don't get me started. But I have aggregated the top. So, did you guys want to guess what the number one scariest movie was according to the mailing list? Scariest? I know exactly what it is. And I'm going to hate this answer. Blair Witch.

Nope. No. Well, that makes me feel better in humanity. All right. I mean, I kind of want to say halloween one two three four five six yes someone almost won uh all six prizes so wait wait what about all right so was it halloween uh halloween was number two was tied for second okay so hold on let me

think about this it had to be nightmare on elm street no that was way down the bottom really okay i don't know i mean that was certainly one of my favorites stephen king's it yeah that was number one but um some people specify old we did get a couple news though but i just lumped them all together because some people didn't specify. Yeah, because clowns are creepy. Yeah, we've got It, number one. Halloween, number two. I did count the sequels, though. I did not count all the person who sent it six times.

The Shining was tied. Alien was up there. We did get one vote for Aliens. I don't know if that was a typo or what. Nah, that can't, but Saw franchise also. Oh, Saw was amazing. And you know what? Actually, Nightmare on Elm Street was up there, but Hocus Pocus was surprisingly high.

Hocus Pocus. In fact, it beat the ring. There were some of these movies that I didn't count in this genre. That was one of them. Yeah, I can't remember. I said mine was Beetlejuice though and I think that's where things went wrong

I know what you did last summer how come that's not in there there was one though that was kind of funny where it was like a Java conference or something Java Zone there you go we got some really good answers

we got a couple office spaces as well oh yeah that one i remember that good stuff yeah so we're gonna post this right yeah excellent well i mean we are now thanks yes yes yeah great word for joe uh all right so the liss Liskov substitution principle. Software systems should be created with interchangeable parts that adhere to contracts. This kind of sounds like everything else we've been talking about, doesn't it? Kind of. Yeah. Yeah, but I mean, it's all kind of tied together.

But in short, this is a nice description we got from Josh Skeen. Because if you look at the actual definition for this principle, it's really mathy, really hard. There's like Greek letters in there. There's a phi. There's like a theta. I can't even understand the original writing of it. Can I read it? Thanks, Barbara Liskov. Yeah.

Yeah, it's amazing that anyone ever got this principle out of this. So, you know, hooray to them. But she originally wrote, what is wanted here is something like the following substitution property. If for each object of O1, and let me rephrase that. If for each object O1 of type S, there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2, then S is a subtype of T. And that O, that was someone being nice to you because it should have been phi. There are too many letters.

Yeah, they had to go Greek on it. But a shorter description, thanks to Josh Keen. And actually, I Googled this description because someone wrote it up really succinctly so i googled it and found what i think is the source but i found so many people not citing the source that i had to call them out so um this is a shorter description of the same thing objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program and this kind of harkens back to the argument we had about the square and the rectangle where you say set width on the square and it does something different when it's a square and

something different when there's rectangle even though you would think they would have like a common interface so that's an example something that violates the liskov substitution principle yeah i think it was the circular it was the circle ellipse wasn't it wasn't that the is that the same thing yeah i mean maybe i was trying to think because it was like back in the project management um it was in the any patterns section the circle ellipse yeah the square rectangle circle ellipse yeah the square rectangle circle ellipse yeah yeah but the idea there is that that that's kind of an example of something where the um you know we've got these two things that meet a common interface or they have maybe a common parentage and you call a method on the child and it gives a different result from if you called it on the parent. So you

are not able to substitute that child in for the parent because it behaves differently. Well, yeah. So to illustrate this further, the example that he specifically gave is that if you were to write code, if you were to try to create a relationship between the square and the rectangle where they were, they shared some inheritance, whether,

you know, whichever one was the parent and you wrote code such that you had a test that said, Hey, if I set the width to, to, um, one value and I set the height to another value,

and then I checked for the area and I assert that the area equals some value, then that would be broken if you substituted in the other type. That assertion would break if you substitute in the other type. Yep. So that's a bad example of Liskov substitution principle. Luckily, like we talked about, that doesn't really come up too often. That's a pretty contrived example. You know, there are certainly cases of it, but doesn't really seem to come up too often. However, there are times when, you know, we'll inherit from a parent and we'll override some of that behavior. And that's where things get kind of tricky because we're either mutating state and kind of poking around the internals and doing things differently and returning the same result, or we're not returning the same result. Either way, it's kind of bad. And it's pretty tough, I think, from reading this, that it's pretty tough to override a parent's method and not be messing with the lsp yeah and there's a part in here too where it's talking about like you know the um you know the interfaces that we have today right they come in in many shapes than just your your c sharp or java style classes and interfaces

right and he makes this example of like thinking of your rest interfaces as another form of this you know contract that we talk about yeah and certain languages don't have like this um specific uh interface construct you know something like like a Ruby or Python or something. And they still have what we'll call well-defined interfaces. They'll have classes that have to have this method and that method in order to be able to do things. Or they'll have some sort of common parentage or lineage that gives them those abilities. It's just that it's a little bit more loosey-goosey when it comes to enforcement uh which is not great but uh and you know those languages are popular for a reason they give you a lot of power and you can do a lot of things really quickly so trade-offs

go ahead um and there was an example in the book but but I think we should just not talk about it because I thought it was a cool example. But this episode's gotten a little long and I didn't really think it exemplified the Liskov substitution principle as much as it was just kind of cool. Really? You didn't think so? Oh, I like the example. I just didn't understand how it applied to the Liskov substitution principle. I feel like we need to talk about it now a little bit. Yeah, now we got to talk about it.

Yeah, okay. So, in short, we've got a system that aggregates in feeds. So, it takes a bunch of different feeds from different sources. And one of the feeds is not like the others. I'm sure you've seen this a million places. You've got 10 sorts of things you're bringing in. And number 11 does it just a little bit differently. And the easiest thing you can do is just say,

all right, if it's number 11, do it this way, otherwise that way. But Uncle Bob recommended having basically a feed configuration lookup instead, where you can kind of look up the different feeds and get some sort of pattern and get that difference. And so you've encoded that difference into data now. So everything else stays the same. Now, if you get a new pattern, you don't have to make any sort of changes. And the system is just more resilient to change. And it seems much more readable, configurable, and just better all around. And so I really liked that example, because it was like, oh, here's a problem that I do deal with,

like inconsistent data. And here's like a cool way of solving it that irons it out and makes things just, it lets me maintain a good clean model. But I didn't understand where Liskov came into it. So I think what it boiled down to for the Liskov plugin, so I get why you're saying that. It was, if you think about what you were talking about, rest endpoints that had slightly different signatures or something like that, right? The problem is, is typically what people do is they just muddy up their code, right? Like if starts with this or if has this pattern, then do this. Else, if it's this, then do this pattern. And the problem is that's not maintainable, right?

Because over time, what if one of those changes again, And now you got this whole mess. So what he was saying is, and this is where the Lizcoff comes into play, is architecture system to where it can handle that. So maybe those places where things are inconsistent, there's like a template that you can use, right? So it requires additional programming to make it substitutable at that point. So I think that's where he was getting at with this was like, you you have different domains that it comes from or maybe you know again the rest endpoints aren't compatible instead of saying if this if this if this you have a template on the url that says if this slash you know get library slash template that can be plugged in slash whatever

right and then that way it can just be plugged in it doesn't care about the format anymore because you've made it to where there's you have your own interface that will work with all of them yeah so it's pretty cool like i get how we kind of made like a little pipeline out of it that now we can kind of extend so i definitely agree that it's completely better i just didn't quite see that kind of um you know inheritance like you know i didn't see a parent-child relationship there i didn't quite see that kind of um you know inheritance like you know i didn't see a parent-child relationship there i didn't see the child or parent acting differently so i just didn't really get how it applied to the rest of the chapter well remember it's not parent-child

right it's just substitution it's literally how can you swap these things in and out right okay yeah so this is a more modular design yeah Yeah. So, okay. Yeah. How can you swap it without having to change anything else? And that's really what this one boiled down to. And I liked the way he, um, concluded this section too, because in a recent episode we were talking about, I don't remember the exact conversation, but something about like, uh, inabilities to like rewrite portions of an application or something along that line. and someone wrote in i don't remember if they wrote in by comments or if it was a in on the episode and discuss but um they talked about something kind of similar to what he wrote concluded this chapter with which was you know an inability to substitute parts of your application

of your architecture there in your application and the problems that that has and specifically as he says it here that that inability can pollute your overall architecture because you end up having to include extra mechanics to overcome it yep right and i thought that was kind of um you know nice that it was in line with some feedback that we recently got and that pollution that you speak of is the if-elses and all the switches and all the additional garbage that you have to try and handle all those special one-off situations. Yep, I like that. Next up is one of my favorites, and actually that video I talked about where I used NDPen to kind of figure out where my cycles were um kind of dealt with uh or how I got around it actually was uh interface segregation principle

don't make classes depend on classes or interfaces that they don't need and what I found is that I did I was absolutely doing that and and kind of an example there is like if you would take it a whole customer record when you only need an email address. And so what that means is anyone who's calling you has now got to figure out how to construct this customer object. And they may not have a customer. They may be trying to fake data to get it there, or it may not make sense for them. It may be difficult. And the whole time you don't even need that. And so it's not safe for anyone who calls you to think that they can pass you this kind of dummy object with just the email um filled in so you're making things tougher on your callers than

they need to be and there's actually some other um problems with that as well they don't really get into too much here they kind of allude to talking about it later but um whenever you do that sort of thing you're also taking on dependencies which means if you recompile that customer object if you change that customer object now you've got to recompile too, because you've got that, like that tight coupling there. And it's easily easy to kind of leak stuff. So next thing you know, you're grabbing things from that customer record that you, you know, are just kind of nice or convenient or whatever. And there's no clear way now for a client to say, okay, they need the email address and this and that and any other specific like state rules about it. Hey, so I want to back up

and talk about your specific customer thing. So what we're saying implementation wise is you have an iCustomer interface, right? And let's say iCustomer just for simplicity sake has name, email and address, right? And then what you're saying is there's this other piece of code somewhere that that needs an email address but because you don't have like this i email interface you're going to look and say oh well this i customer has email on it so i'm going to implement you know i customer the only thing you need off that is email. And so now you're getting this extra stuff that comes along for the ride. That doesn't make sense, right? It's out of context. It's not really the same thing. So that's when, when you were talking

about that customer thing and getting that object, it's because you're using an interface that exposes more than what you need in one particular place. Yeah. And for me, like I would be lucky to, you know, have those interfaces in the first place. It's more like I have something like a customer notifier or something, and I'm working on a customer. I'm thinking about customers. Everything I'm doing is oriented around customers. I need to send an email to a customer. I write a method that takes in a customer.

It sends off the email. And then maybe later I come back and break that class up because I'm like, you know what? If I kind of take this out, I pop in an interface here or something maybe it makes it easier to test whatever but now that I've done that I don't go back and refactor and say you know what this method only needs this one thing and so now I've kind of created this coupling where there just doesn't need to be and it makes things harder to see it makes things more difficult to compile. You know, it's just kind of bad. I don't know that it's terrible. Like, if there's one you could probably get away with.

Well, isn't there, there was the old example of the Microsoft, I think, identity provider or something like that, that used to have just like tons and tons and tons of methods that were associated with it. So if you implemented I, you know, identity, then you got all this garbage, or it might've been I profile. I can't remember what it was, but you got all this stuff and they're like, yo, I just really needed the authentication method. Right? So that's when you, that's this whole segregation principle is really, it shouldn't have been one big interface for it. It should have been I authenticateable, I, you know, profile, I, whatever. And then that thing could have implemented each one of those things. Right.

Yep. Yep. But you imagine where you like pass like a authentication header to something and say, Hey, what type of encryption are you using? Right. And then like, you could think that makes sense. But if that method wouldn't said say you know take a string and say hey you know what's your type and convert it to an enum or something like that it's much more reusable too so people searching for that code to do other things with who may not have an authorization header they might have some some other sort of you know

information can now kind of use this method because they've got that more granular information or before they were prohibited and probably didn't even know that was an option there was a interesting portion of this chapter there where he was talking about how as it applies to uh languages that you know maybe this is an a language issue rather than an architectural issue and that you know some languages like um you see like languages um c c++ java c sharp etc where you have statements like includes and using imports that it would create the dependencies that dynamically typed languages don't have this concept, right? And that it's because they don't have that, that you could argue that you're able to create systems that are more flexible and less tightly coupled

because they don't have those dependencies. So you're saying the loosely typed languages are easier? That's what he's saying. I feel like you're trying to back me into a JavaScript corner here. That's interesting. Either way, you still have the same type of problems, it's just kind of different right i mean the difference is in c sharp if you implement something that has 80 members on it and you only need two of them you're stuck with it right is what he's getting

at in javascript you don't have that in ruby you don't have that you just say hey i want these things and that's it right but there's nothing that enforces it one way or the other i think is where the sloppiness is right so it's kind of pick your poison what kind of took at the point is like we need the interface segregation principle in the static languages because of we're getting around the language issues right we're trying to not have those dependencies, like in the examples that you guys gave where you don't mean to leak that information, right? With like the additional customer information that isn't necessary or the additional information about the identity provider. Like you don't mean to leak that for those cases where you don't need all of it, but because the way that particular language is, all of that stuff is coming along for the ride.

In the case of these dynamically typed languages, because they are dynamic, you already just don't know, right? Right. But that's not a good thing. It's not like those languages are better. It says at the end there that this fact could lead you to conclude that the ISP is a language issue rather than an architecture one. Right. Oh, yeah, I guess you could take it either way.

Wait, you took it to mean the other? Yeah, I totally did. Oh, interesting. I was like, oh, it could lead you to conclude the ISP is a language issue, but you'd be wrong. And now even reading the paragraph, I'm not sure which way you meant it. Yeah, I kind of took it to mean that languages like a JavaScript, for example, because it's dynamically typed and doesn't have, you know, you don't have to do requires where you're kind of leaking.

I never thought about an include statement as a leak, but he's kind of leading up to that, that, that, that that's a type of leakage, right. And the dynamic type languages don't have that. And then as a result, you have more flexible systems that are less tightly coupled. And, you know, it kind of made sense because then I was like, well, I guess, you know, you think about JavaScript and my mind immediately starts thinking web related kind of things. Right. And an example of that and i'm like okay yeah totally uh you know there there's you're not making an include statement when you because you want to use some rest service right yeah but now um like if you do have like a ruby service or like a

service is probably about just a Ruby method. It's really hard to know what pieces you're using out of that, that object, but I guess it kind of avoids the problem altogether by not even, I don't know. My, my brain just melted. Well,

I think, I think one thing that he points out here that I help, I think help identifies the problem that he's trying to illustrate here is dependencies, right? Minus the fact that there's just things like interfaces, but dependencies when you're including something, if you have A depends on B, but B depends on C, you just now made A depend on C, even though A doesn't care anything about C. So let's say that C was a database, right?

A doesn't care anything about C. So let's say that C was a database, right? A doesn't care about a database, but all of a sudden, because it's now using B, it has to have C. And so you're creating that because you brought along more than what you needed, you've now created these tightly coupled dependencies that can really mess you up in time right and that's what he was getting at with this whole thing was even i know we were talking about down at the code level but at the architectural level and really a lot of this stuff that we've been talking about with architecture has to do with dependencies right like how do you swap in and out these things and when you tightly couple yourself to something that you didn't expect, you created a problem. Yeah. Crap.

Sort of. I have to reread the whole book now. Suddenly everything has changed. I mean, honestly, that's the one thing that's kind of been a little bit. I didn't mean to melt your brain there. You know, he talks about the code because that's what everybody's familiar with, but then he tries to bring it up to the architecture level. And just about everything I've seen so far is, how

do you keep these dependencies clear lines drawn between them, right? Like, how do you keep these boundaries up? And that's what it seems to mostly all boil down to. I think I brought some of my own baggage into this chapter. I think it's because you like it a lot right and so so you're passionate about it yeah just like i've never heard people

saying you know like like architecture and dynamic languages don't really you know you don't really think of them together too often so i mean i think about like soap and wisdoms and xml i think about architectures i think about uml i don't think about like SOAP and WSDLs and XML when I think about architectures. I think about UML. I don't think about duct typing. Wait, does WSDL still exist? Is that a thing? All right. So, then it makes kind of beg the question then about going circular here.

Dynamically typed languages don't have these concepts he's saying and that it they don't have this language problem that we're trying to solve with the integration segregation interface segregation principle but then now with like modern java's frameworks so we're getting like you know a level deeper here now we're not at the language level we're getting into specific frameworks and some of these frameworks bring in the concepts of requires or imports yeah so maybe maybe those are doing it wrong hmm well leave us a comment and let us know and you'll be eligible to win a copy of the book for yourself that's right all right so the last one the d and solid and this one is the dependency inversion principle so this is where the code that depends on the high level policy should not depend on the code that implements the lower level details.

That sort of makes sense. Yes, and Dance to Die told me that from here on out, after this chapter, we're going to be getting into acronym city. And I've already noticed they're referring to this as the dip. Well, I mean, all of these these all of these uh you know every time every place for the last chapter it wasn't uh interface segregation principle it was isp right yeah like wait a minute my internet service provider got involved here what did they do wrong the ocp yep yeah you're right so yeah looks like we're already there yep so on this one

yeah they're saying nothing concrete should be depended on yeah and i that like hurts that means like no classes it means everything is an interface or and not necessarily interface or an abstract class well hold on hold on again i think we're going too far down into code think about it from the system level you know component wise you basically want to depend on interfaces that so talking about your game earlier right you were talking about hey if i rethought this instead of worrying about everything in down here at the lower level details of this what if i made my game interface something to where you know there was this i game interface or something at that point now you have set up the abstraction at your architectural layer right and i think that's really what it is is you shouldn't depend on game you should depend on

i game right so i game you game we all game that's right the library i use um unity takes care of like inputs and stuff like that so i don't have to worry about keyboard or joystick i can't get specific so if i ever want to do some you know specific stuff then that's a good way of doing it but um it's nice to kind of have that level of abstraction if i can kind of take that lesson and apply it to other areas and have bigger modules then it would make the SQL a lot easier to do probably. I'm already thinking about the SQL. It goes back to your one true love. Yep.

Although, you know, it's weird. SQL and the SQL. We do talk about this, like we're trying to talk about it from the architectural level, but he definitely mixes it, right? Like he goes back into the, you know, don't refer to volatile concrete classes. Don't derive from volatile concrete classes. Don't override concrete functions.

So it's it's definitely mixing the two right between between actual low level implementation versus, you know, higher level component based structures in the architecture. And again, this one was trying to invert your dependencies right so that um you know he made he makes a statement in here where he's saying that statically typed languages inheritance is the strongest and most rigid of all relationships right and by using interfaces going back to the um the previous one right that's like a way of trying to get around that of not introducing that dependency elsewhere yep so this is trying to flip your dependencies on its head so that your your higher level parts aren't as dependent on those low level details and that's done by using factories for the most part is what he's talking about here right uh i mean in this specific example that

he gave yes what did you say joe yeah factories are one way um you know one thing i i noticed that he does not mention at all is dependency injection framework which i think a lot of people myself included often get kind of confused with this principle but there is no formal relation between that that is a tool for this problem but it's not the way and i kind of and so i think that's why when he said factories is one example what he was saying is like i'm not even going to touch the f word well the other f word right the other other f word anyway framework oh that one yeah but it does mention that nothing is kind of nuts and there are like things that are built into the system like things like string, in terms of language,

like strings and stuff like that. Just primitives that are what he calls not volatile. These things that are very unlikely to change. And so if you're going to depend on anything concrete, then those aren't so bad. And it kind of got me thinking about a system level too. There's probably things you can think of like, you're probably going to have files.

You're probably going to have some sort of concepts that kind of tie back to traditional computer stuff. I kind of read that portion as it's really your stuff that, that you have to be more worried about the stuff that you're writing or those third party packages that you're bringing in those third-party packages that you're bringing in um that aren't necessarily part of the framework right yeah you can play about windows all you want but you're the hot mess yeah yeah so so like the system uh namespace or system.web namespace that's probably that might not be the one that you're as concerned about.

But your particular namespace is the one that you're trying to protect more in this regard. At least the way I read it as it related to the architecture portion. Yeah, I like that. And I like the definition of volatile there. Although whenever I see a word like volatile, like it always kind of like takes me seconds is such like a not normally in my vocabulary, you know, like makes me feel like it's a reserve word. But I think volatile here, they just mean likely to change. Yep.

And then they also tell you to never mentioned the name of anything concrete, concrete and volatile in your code. Which I thought is pretty cool. And yeah, and also mentions that DIP violations can't be removed entirely. So, and that's a lot of things, just like we talked about. You know, it's okay to kind of let some things slip if they're, you know, not that volatile, they're built in, or if they're just too hard to remove. And for the things that you can't remove, if you can kind of push them into the edges or push them into the corners or consolidate them somehow, and that's a valid

strategy for dealing with this. I did find it interesting that they said that this particular principle ends up being the one that shows up the most in the book. Like this one just keeps coming back up and up and up. So it says it's the most visible organizing principle in our architecture diagrams. But it makes sense though, right? Because from an architectural point of view, that's what, if you're trying to piece together a bunch of components,

this principle is trying to reduce those dependencies or make those dependencies. How should I say that? Like less known. Is that a better way to say it? You control the direction of them, right?

That's really what it is, is you can draw boxes around it and say, I control how these dependencies work. Instead of your code dictating like that, that big tree that was shown like towards the beginning that's really what it boils down to is trying to loosen those those hard lines so that's it we've covered the initial pieces of solid and we'll be getting back into the next section later on although Although the next episode,

we're going to be doing something fun. Joe, you want to, before, before we go on to the next few pieces here, you had an idea and, and I love it. So you want to explain what,

what our next topic is going to be? Sure. We're still kind of ironing out the details. Um, but the idea is a couple of years ago we did a, a show, maybe we'd even did two shows, kind of talking about our favorite gadgets and stuff around this time of year. There's a lot of stuff goes on sale, Black Friday and everything. So we thought it'd be kind of fun to come up with some sort of budget. And each one of us kind of runs off and, you know, like, window shops, I don't know, we basically use up that budget on stuff that we would want to actually use and so we think it's going to be a little fun exercise and we're still kind of figuring out the rules so if you have any suggestions uh let us know in that comment

to win the book and we said the budget was gonna be twenty five thousand dollars right twenty five thousand yeah yeah that's what we said right all right all the tech we can play with yes $2,000 on a computer and the rest into savings. No, that $25,000 will buy you an iPhone. And by the way, none of this goes into savings. If you don't use it, it burns. Oh, okay. That changes everything.

So anyways, that'll be the next fun one that comes out after this episode and then we're going to jump back into the clean architecture so just uh be aware we're going to have a fun one soon all right and so with that uh we will have links for our resources that we like for this book as well as we mentioned sonar cube so i'll include that and we head into alan's favorite portion of the show it's the tip of the week yeah baby hey we're getting dangerously close to what joe's got to answer why is he laughing so much i squeezed one in there i uh i said tip of the week i think first oh i guess we'll find out when well When the editor does editing, we'll see who won the contest of saying it first.

It was a race. I feel like it's not going to be me. I'm sorry. I just cut him out. Did you hear him say anything just now? I don't hear it either. My favorite kind of race is the race when the other people don't know that they're racing. So you're that guy at the stoplight yeah yeah oh yeah oh yeah uh yep all right so outlaw you were up first all right so uh we've talked about machine learning uh in the past and

and that uh i think we've mentioned that I've been reading up on it or whatever. But I thought that I would include a link to if you haven't already started playing with machine learning. There is a studio.azureml.net where you can start playing with machine learning in Azure today, right now for free. And so I thought we would include a link to that as well as there's some tutorials out there like giving you some examples of things that you can do. So, you know, just a pretty neat opportunity. If you have any interest in it, you can start playing around with it if you haven't already.

For free? For free. that's awesome now i will let me put a caveat on that if you create if you do use the free service it's not like you're gonna be able to do anything production with it and the results of your model that you're going to create are going to it's only going to be good for eight hours but you get to play but you get to you get to experiment with it are going to, it's only going to be good for eight hours, but you get to play, but you get to, you get to experiment with it and it's still,

it's still a worthwhile, you know, use of your time. Awesome. All right. So I've got a couple only because it's really one with the, I don't know, side of another one.

So the first one is from Nate, the DBA in our Slack channel. Awesome guy. He's, he's always sharing and helping people out over there. know, side of another one. So the first one is from Nate, the DBA in our Slack channel. Awesome guy. He's, he's always sharing and helping people out over there. And I'd never heard of this before. And it's amazing. So if you've messed with SQL server and you've ever had a performance issue, then chances are, you probably know what an execution plan is. If you don't, maybe I should find a link and maybe I'll remember to, but either which way, one of the things that you can do is if you want somebody to help you out, if you have a DBA friend and you need some help, there's a site called pacetheplan.com

and you can go in there and copy in your XML and plop it up there and you can share your execution plan and somebody can look at it and say, hey, you have a over here you need to introduce an index or hey you've got this over here pretty cool stuff like i'd never heard of it so really awesome like that that's amazing um the other thing i have is so i built my own computer slash hackintosh slash whatever and was really excited about it happy with it and it just started blue screening like crazy oh and i was like what is this garbage right like and so i started doing some google like literally boot into it and it would die like immediately just blue screen and i was like man this really doesn't make me happy so i looked it up and apparently they were saying oh it's probably bad memory and i'm like man that doesn't happen like that's not real people don't

get bad ram not anymore right you're saying that's what you're thinking yeah right i mean like yeah that was a problem like you know 15 years ago dude i've built so many computers like i've never had this problem so the tip i wanted to share is if you ever are getting blue screens or anything like that, and you want to at least try to find out if it's your RAM, there's a website called memtest86, and it basically boots up in your UEFI and it will actually run all kinds of test patterns on your memory. And sure enough, both the sticks that I had, both of them were showing errors. Here's the crazy part. When I saw that I had, both of them were showing errors. Here's the crazy part. When I saw that you had a link there, I was like, wait a minute, that thing is still, that can't still be made, right? Like that can't still be current.

And yet there's still, there's a release from July of this year. Yeah, dude. This thing has been in development since 1994. Isn't that awesome? That is insane to me. It's a nice interface, dude. Yeah, I'm looking at the current screenshots of it. It's coming a long way.

So, yeah, man, I RMA'd my memory, or yeah, I RMA'd my memory, and I got it back, and I stuck it back in there and ran that again, because I was like, man, if I got some more bad memory, I'm going to lose my mind. That's why you were so forgetful for a while. Right, right. I got that bad memory, I'm going to lose my mind. That's why you were so forgetful for a while. Right, right.

I got that bad memory. Yeah, sorry. Oh, what? I don't even know what that was for. You don't remember bad medicine? Come on, man. I got bad memory. Yeah, but it wasn't bad memory. It is now.

Yeah, anyways, it worked. It was amazing. And it runs all slew of tests on it. And it will also check it with multi-threaded processors to make sure the processor is accessing the RAM in the right spots and all that. It was killer. Great tool. If you ever run into any problems, you start getting blue screens,

check that out. It might save you. Now, it takes a lot of time. Depending on how much RAM you have, it takes a lot of time to run through all the passes. But it's it i think that was a humble brag joe wait what was a humble brag bad memory see now you want to say you know i've got so much memory it's going to take a while uh so my tip of the week comes from andrew uh and then outlaw told me about it but uh andrew diamond and uh talked about it on the slash channel and it is the regex crossword i've actually been playing

it until i got stuck here while we were recording so if i've been quiet it's because i was trying to figure out what letters speak and hello have in common besides the e anyway um it's a really cool uh i mean it's just it sounds just like it says it's a crossword where you've got stuff going vertical and horizontal and you've got to find the matching things in common between those two and uh i'm still in the beginner stuff and it's it's gotten pretty tough but they start you off easy so it's a really cool way of learning regular expressions and what i really like about it is every other way i've ever like looked at or attacked regic expressions has been from the writing viewpoint and this is kind of going from reading so you're actually generating the text

that is in common between these two things so i think it's a really cool way of learning it and hopefully that means i'll actually remember what i learned this time. Wait, does anybody want to learn regex? Is that a thing? So just to illustrate an example of what he's describing here, let's say you had the most basic of all crossword puzzles where there was only one square for one letter that had to be filled in and on the vertical, the, uh, the, the quote, you know, hint for the vertical would be A or B and the hint for the horizontal would be A or Z. And you have to enter in some letter that solves both of those. Right. And yeah you have you have to be able to read the regular expressions in both directions in order to figure out what should go in that and it's

going to get more complicated as you go on see how i'm trying uh it hurts my brain i i don't need i feel like i need to flip my computer sideways to look at it. Well, there's actually arrows for that. There's little arrows where you can rotate the, Oh, I didn't know about the arrows. Yeah.

Oh, to the left. So, so you'll enter in your answer, right in that square. And then there's a validate button. It'll tell you, you know,

whether or not you got it right and you can move on or not, but to the left and right of the validate button are some arrows so that you can rotate the puzzle around so that you can read it more easily what are you supposed to talk in the field is there just one letter that's supposed to go there that doesn't look right well it depends on uh i guess in the beginning it'll be how advanced you you decided to pick you could start with a tutorial for the uh i probably didn't do the tutorial because i don't understand what it's for the beginning levels because i'm pretty sure i'm gonna rock this

maybe not uh yeah the first like the first ones will be like uh the top will be like a pipe b so a or b and the left to right will be like, you know, A star, which means, you know, one or more A's. And so the letter that has in common there would be just one single A. But as it goes on and you add more boxes, it's definitely gets a little more tricky. It's like regex Sudoku. Okay, so I'm killing the tutorial. Just destroying it man just saying i'm already on number four look at that man all right so moving on to the show summary sorry we're gonna have another two hours of watching us play regex well we are up to page 92 in this

book already um and uh we've just finished up with the solid principle and the pair the programming paradigms and so hope you all enjoyed and we'll have a really good show notes so you should check them out I do like the paradigms yeah thanks Alan

we'll never be able to say it again anytime correctly all right so with that subscribe to us You got it. We'll never be able to say it again. Anytime. Correctly. All right. So with that, subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. Be sure to leave us a review by visiting www.codingblocks.net slash review. And while you're up there, check out our show notes, examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel at codingblocks.slack.com and

follow us on Twitter at CodingBlocks or YouTube or anywhere else. If you go to codingblocks.net you find a bunch of links at the top of the page. You're not going to ask about my favorite part of the show? Oh, your favorite? No, yeah, we need this. What's your favorite?

I guess I should have thought of something before i uh no it's got to be those uh sweet dank memes