Coding Blocks - Clean Code – Objects vs Data Structures

Episode Date: December 13, 2016

This week we’re drawing a line in the sand between objects and data structures. Who will win? Take a listen and decide for yourself! For the full show notes visit: http://www.codingblocks.net/episode51 Podcast News iTunes Reviews: DelBoyeire, nullthecode, Ser_j, Pneema, matthew.watkins, JC_JavaScripter, Connor Phee, Stratodavius, GS Leonric, dmitry.gokun, MobileMon, vasyl shcherbatjuk Stitcher Reviews: tommyrush, DoNotAsk, nullthecode, […]

You're listening to Coding Blocks, Episode 51. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, 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 Mike Woutlaw. Man, you had props. That's not fair. Wait, I missed the props. What were the props? I'll show it again. So here's the deal. This is our first time trying a video recording. I don't know if we're actually going to release it, so this might be a little weird. But right now I'm sticking a Jabba the Hutt original Star wars toy in front of the camera that's amazing very nice yeah all right so yeah let's let's get into the very first thing that we always do which is reading off odd names

on the on the reviews and by the way there was somebody who left us one on stitcher that i want to take a stab at because he even said oh yeah when he was like good luck with good luck with the name i'm gonna go ahead like for for everybody who's uh waiting to hear that one i'm gonna go ahead and say like this one's gonna be impossible though because it has like slashes and dashes and dots above letters that really shouldn't have those so i think that this is an impossible name to pronounce. I know I would fail miserably or fantastically at it. All right, and I'm calling iTunes this time. All right, you go for it. All right, so iTunes reviews.

I want to say a big thank you to Del Boyer, Null the Code, Sergei, Panema, Matthew Watkins, JC, Javascripter, Connor Fee,

Stratodavious, which is my favorite for this one, harking back to either Stradivarius,ins or Stratocaster guitars, I'm thinking. Anyway, that's what I wanted to read. Yeah, that's what I thought too. GS Lienrich, Dimitri Gokun, Mobilemon Vasil Shcherbachevich. That's a Star Wars name, I'm fairly certain. All right. that's a star wars name i'm fairly certain all right so uh for stitcher we've got tommy rush

do not ask know the code el programador tommy snacks can tell antonius augustson wow spoon raker they told me to write a review and connor fee and i fee. And I think I'm pretty close on that. Well done. I mean, I don't know if you said it right at all, but I think it was the confidence in which you said it that completely sells it. I totally said it like a boss. Hey, for anyone who,

for anyone who might not have been paying attention, did you happen to notice that two of those names were said twice? Thank you very much. Null the Code. Yeah. Null the Code and Connor Fee. That's amazing. Thank you very much for doing it.

And all of you, seriously, thank you. Excellent, excellent stuff. Makes our days. And, you know, we really appreciate you taking the time to do it. So, yeah. Now we're on to the part that everybody likes right oh yeah the winners so so what do we got there well we had the winners of episode 50 but we're doing episode 49 right yeah so i'm a little bit confused by what we were right there yeah yeah and by we me so so episode forty nines

winner was viney or would you think that'd be Vinnie by me yeah if it's one in it looks like viney to me so that's the way I'm going to pronounce it so we'll be reaching out to you to see where you would like your copy of clean code

sent to yep congratulations and just a reminder we do still have an overly discount code uh while last 50 off most print and 40 off most ebooks there's like a banner ad on the right hand side and full disclosure we don't have affiliate fee set up still so go get stuff before we do well no i mean even with even with affiliates, it wouldn't cost you any more. But yeah, definitely go get that discount. We're not going to benefit from it. Even if we did, it'd be like 75 cents per book.

Everyone's waiting until we do benefit. And then they're like, oh man, I wish they'd hurry up because I have some books I want to get for Christmas. That's totally what's happening. Yeah, go buy every tech book ever. Every tech book you ever wanted, like all 20 of them, and you'd buy us coffee. Fancy coffee, but coffee.

And as Joe mentioned last time, you should also make sure that you follow us on Twitter, like us on Facebook, join our mailing list, because when we get cool stuff to give away that we don't actually get to keep ourselves, we mention it on one of those three channels. So definitely go sign up on those or or you know like us on those and be a part of the fun and speaking of giving away

cool stuff you should uh send us a self-addressed stamped envelope and we will return the favor with stickers yeah and um what you can do is basically just um email us and we'll send you the address or you can go to a new web page that where you're going to set up codingblocks.net swag and we'll have information either address or you know whatever you need to do to buy cool stuff from us buy us that coffee and if you have stickers and you're one of those people that voted that you don't like putting it on your laptop you can always do this put it on your case on your phone and that way that you don't like putting it on your laptop, you can always do this, put it on your case on your phone. And that way when you're talking, everybody can see an inverted. Yeah. Anyways. Hey, one other thing I forgot to put in the show notes here that I wanted to mention. So all of you people that have been, you know, wanting an SSD for quite a long time,

I've read multiple articles recently saying that if you want to get one, go ahead and get it now because apparently they're starting to become a shortage on NAND memory. And so prices are about to start going up here towards the end of the year. So if you're wanting an SSD, now's the time to get it. Who knows if that's marketing garbage? I don't know. You know, I've been reading these articles too, and I can't help but question like, do you really, I mean, you said you think it's marketing garbage,

maybe, like who knows? Right. Hard to say, right? It's impossible to know. I mean, you know, like a few years back when there was the tsunami, then it made sense, right? Like why there would be a shortage on hard drives, right? Yep.

Maybe I'm just not in touch with the rest of the world. I haven't heard of any like major event that might you know trump it was the election yep that's what it is that's what it is you know as i was as i was saying it i'm like wait a minute no there totally was yeah so i mean i really don't know but you know i've been thinking about actually getting one myself so who knows i have such affection for ssds that I kind of want to decorate my office with them. Oh, dude, they're amazing. They really are awesome.

And then we have our giveaway rules for this next episode. Like with the previous episodes, if you would like to be entered for a chance to win clean code, don't be disheartened by the fact that you haven't won in the past three or four episodes, you have yet another chance. So if you would like to try and be entered, go to www.codingblocks.net slash episode 51. And put your comment there on the page. And you'll be entered for the drawing in episode 53 to win this book. So definitely go do that. And the link will be in the show notes that should show up on your phone that you could click and quickly go to the site. So do that. All right, let's get into our next chapter in the clean Code series. Are we ready? I believe so. Yep. Chapter 6, Objects and Data Structures.

And I got a little visual here for the people watching the video. It's actually got a picture of Data, who, if I recall, Star Wars won the poll that we did a while back, but I still prefer Star Trek, even though I'm wearing a Star Wars shirt and have a Jabba toy on my desk but it's still nice to see buying this yeah better merch that's that's actually very true i haven't seen too many data dolls around all right so and now we know why Star Wars won. Exactly. Mystery over. So this chapter was kind of interesting. It wasn't as deep as I thought it would be.

But one of the things that they start off right about right at the beginning is hiding implementation is about abstractions. Like a lot of times you'll see in code, and we've all seen it. Like you'll basically have some sort of property and then there's getters and setters for every single property on the page. Right. And they make a very big point about at the very beginning saying, that's not how you should do it. When you're writing your OO code, it should be about abstracting what's actually happening. People shouldn't have to know about the data behind the scenes that should be hidden implementation and nobody should even care about it.

Well, I like the point better that you made that more often than not, you'll have the actual instance field, the data field that's used to store that hidden. That part's private but then uh so many developers will then put in a public getter and setter you know either an auto property for c-sharp or you know actual methods and maybe java or something else and it's like oh yeah that's actually a great point that you know you really are just exposing the underlying thing that you had hidden so why bother yeah totally i mean and even in c-sharp it's really easy to be guilty of this just by making everything an auto property, right? Oh, you know what?

I said auto property, but I guess actually that would be incorrect because in C Sharp, if it was an auto property, you wouldn't have a private member that you created behind the scenes. It would be, although technically that is what's happening. Yeah, and actually when I started reading this chapter, as soon as I saw the title, you know, Objects and Data Structures, I was like, all right, here we go.

Let me go get some coffee. And then I started reading it and then I finished the chapter. So it was really short. I think I counted eight full pages and there's some code samples in there too. So it's just some nice tips. But one thing that threw me immediately on the title

was just the word, the combination of word data structures. When you say data structures to me, think trees arrays hash tables lists stuff like that and that's not how they mean it all here when they say data structures they basically mean you know pocos pojos whatever um plain objects that map or represent data so a class that's got some properties in it when they say object say object. Yeah, opposite. Yep. I had this same exact reaction when I saw it. I was like, Oh, we're going to get into dictionaries and why it's better than the hash table. And no, like it totally wasn't that. But it is interesting, right? Because the parts that they got into was true pure. Oh,

and they made a point of even saying that when you're trying to do something right in OO, it takes a lot of time and thought to actually structure things in a way that makes sense, which is, I think, one of the reasons why you end up seeing a lot of times some sort of private field with public getters and setters, because that doesn't require a lot of thought, right? Like, you know that this is the data that you want to use and here's you know i'm just going to expose it all so that i can use it however i want i thought yeah there was a great oh so go ahead joe sorry i thought you're gonna say um that's why we see so much bad code is because writing oo stuff is hard but uh you know procedural code is hard in its own way it's it's hard to maintain and what i mean by procedural is basically just

um you know uh functions basically just a lot of functions that do stuff, kind of your stereotypical kind of spaghetti code, like functions all over the place, taking in arguments, doing stuff, not really doing a lot of

model-y type things. But I did think it was interesting they drew such a hard line between the two because when I think about most code bases, I kind of think about these hybrid classes

that they hate on a little bit later in the book. Oh yeah, definitely do hate on those. But there was this really good quote that I liked that was hiding implementation is not just a matter of putting a layer of functions between the variables, which would be like what the getters and setters would do, right? Hiding implementation is about abstraction and that a class should expose abstract interfaces

that allow the user to manipulate the essence of the data. So he gives this example of, you know, there are two really cool examples, but one of them that I thought like really sells it well that everyone can understand is trying to get the capacity of fuel left in a car or whatever the vehicle may be, right? And he gives one example where, you know, you have two methods and they were turned back doubles

and one of them is like, you know, get gallons of gas and the other one is get fuel tank capacity in gallons, right? And so he's kind of making the point that like, hey, you know, based off of these names and what they're returning, like you pretty much can guess that all this thing is doing is just returning back some private double behind the scenes. And, you know, there's really nothing hidden about the underlying data, you know, the underlying structure of that data, you know, it's pretty much kind of exposed, even though there's this layer of indirection maybe in front of it versus the other example, which is way more abstract, which is also returns a double, but it's just get percent fuel remaining, right? So you

have no idea what kind of measurement is being used for the capacity or anything else about that. You don't know anything about the implementation of how it's getting to that number. It's just returning you back a number. So I thought that was a really cool example. Yeah, I really like that example. And especially since it is a vehicle specifically,

the example that it's talking about, but this interface could go on a number of things, percent fuel remaining. That could be the console. It could be the gas tank itself. It could be a number of different things that can share this interface. So I just like that example. And it doesn't even need to necessarily be a car, right? Right.

Well, and yeah, that's why I corrected it and said just vehicle. And it would be, totally didn't go for this but it would be uh you know it could apply to electric vehicles too yeah that's right it'd be zero or well yeah but wouldn't like the the quote fuel be like whatever battery power is left yeah electricity is left yeah yeah this is this was written slightly before hybrid cars that's right or electric vehicles no when did we decide this was written there before hybrid cars. That's right. Or electric vehicles. No, when did we decide this was written? There were electric vehicles when this was written.

Yeah, they were totally. Golf carts. What was that ugly Chevrolet thing? Yeah. Oh, God, that thing was hideous. Yeah, that was back in the day. So there were a few quotes in here that were really interesting that I thought were spot on because we hit on this a second ago. So objects hide their data behind abstractions but expose functions to operate on the data, which is that get fuel by percentage, right?

Or get percentage of fuel remaining. And then data structures expose their data but have no meaningful functions. So when you actually hear that, that makes a lot of sense, right? Like one can do things on the data. The other one just has data is really what it boils down to. And that's really important to know. Yeah, and so when they're talking about these interfaces,

yeah, just to bolster your point, they're talking about an object here because it's got those behaviors and a data point would have something more concrete like total gallons and gallons left, something like that. It just represents the data. those behaviors and a data point would have something more concrete like um you know total gallons and gallons left something like that it just represents the data yep yeah i mean he he makes the he actually makes the point here to say that these two are are virtual opposites of one another that uh you know unless you get to joe's weird hybrid example that sounds like he has an opinion on,

but, uh, you know, there was an example of like a point that he gives, right. And, uh, this one, I think this,

well, actually, no, I'll take that back. That one might have been, I can look at that code again. I think he might've met that one as a, uh,

I was going to say he met that one as a, as a data structure, but I think he meant it more as an object. Now that I think about it, cause he was actually given methods for reading it. Yeah, and the reason I think it's so interesting that they split it up is because I think my default is probably to make these hybrids. I'll start by modeling the data, so I'll create, say, a vehicle class,

and I'll give it those two points of properties for the total gas tank or the max gas and the current gas, and then I would just go ahead and add the method there like just not even thinking about it like oh you want another percentage well i'll go ahead and add it here as a nicety but you know it makes sense to keep it here since this is a common place for me to use it if i know about the vehicle and you know makes sense that i want to know this and so it's interesting that my default is uh is a bad. I think that's most everybody's. I do the same thing, right? Like you think about what your data points are,

and then you think about the functionality you need out of it. And I don't know that that's a bad approach. It's like we've talked about before, right? Pretty much everything you do, you should just hammer it out, get it in there, and then start refactoring it out. Because trying to start at the utopian place is just a non-starter usually, right? Like you end up thinking yourself into a corner and you never get anything done because you're like, you know, you can think of five million other ways to do it.

And so you just really get stuck as opposed to putting it in there, taking a look at it, and then iterating on it. Because, I mean, how many people use things like Rational Rows anymore or UML type things to actually get rolling? You know what I'm saying? Yep. And if they do, they're probably doing it wrong. Well, I'm doing it wrong all the time apparently. So yeah, I like the idea of keeping things split out though. I can't really come up with an argument against it except for class explosion. You're going to have more files,

but I like the idea that there's only one reason for these things to change. You know, if I add a property, I go add it to the data file. If I'm changing the behavior of some data, which may be in any number of places, then I should go modify the objects.

Hey, we talked about this way back in the day. I think when we talked about solid, because you, you mentioned the class explosion. I think, when we talked about Solid. Because you mentioned the class explosion. I think back when we did the Solid episode, one of you guys threw out the fact that there was some application. It seems like it was Facebook or maybe some sort of Java app out there. They just had thousands and thousands of files and tons of methods and subgroups. They had literally just broken everything down to the most minute of points.

Do you remember, either of you guys? Sorry, I was texting. I don't remember that specific example now. Drawing a blank, yeah. Man, it seems like it might have been the Facebook Android app. I mean, where are we going with it though it just just the whole idea of class explosion isn't really that bad like because you end up as long as things are done in a maintainable way which it seems like having

100 files for subclasses seems like that might not be great i thought we were just joking about that though like that it would like if you tried to adhere to solid then you'd have like uh you know a thousand files and nothing would ever do anything they would all just be interfaces i mean i remember us making that joke several times yeah and i do agree enough that's a pain in the butt and i think the the reason that a lot of people balk about it if they um if i don't want to say if, but the reason a lot of people balk at it is because they think, oh, I'm going to have to make a change and I'm going to go have to change it in 20 places. But ideally, you're composing this stuff. So by breaking stuff into these little pieces, the theory is that you don't have to make changes. The whole reason you're breaking stuff up is to minimize the number of things that you change when you make a change. And so if you're doing things, quote unquote, right, which is basically impossible,

then you should be making less work for yourself, not more. Yeah. I mean, this whole chapter that was more about thinking about the data that your object is going to interact with and not necessarily like, because I feel like when we talk about solid, for example, we're not really talking about the data that the class is operating on, but this chapter, that's what we're talking about, even though it is like objects and data structures, right?

Like it's still how the object might use and interact and work on data, but, you know, with the intent of trying to not expose the details of that data, right? And trying to get into this mindset of thinking of that data in abstract terms, right? So going back to the gas tank example, don't think about it in the literal, this is the, you know, capacity of the tank and the current amount of fuel in the tank, right? But instead thinking of it in something more abstract, like this is the percentage of fuel left. Or don't expose it directly, right? Don't give them access directly to those underlying data structures. So here's one way to think about it.

If you think about a hybrid class, let's say you've got something that represents a piece of email, right? And you want to mark this email as sent, right? After you've kind of created it, done some stuff, it's been queued, whatever, it's actually been sent. Mail server said okay. One way to do that would be to have a class that represents the mail, and it's got the to, the from, the yada yada. And it's also got a method called mark as sent and it goes out to the database and it says you know update is sent equal one whatever that's kind of the the hybrid approach right so it's got properties mixed in there it's got some methods in there and it's fine another way to do it if more singly solidly

responsibly whatever is to have one class that just models the data structure. So it's got the two, it's got the body, it's just got the data, right? And then you've got another method that knows how to save this, or sorry, another object that knows how to save. So it takes in the mail message, it knows how to save it. And then you've got a third one that says, you know, it's got some other behaviors like says mark ascent does is takes the data marks the sent flag as one and then tells the saver to save it and so it is more classes but it's just more composable

i i i can't help but think about this like because we were joking about everything in solid being all interfaces, right? So like as you're describing it, some picture like in my mind. Okay, so I picture a class that implements an I email interface and an I savable interface. And the I savable interface provides two methods. One's to actually do the save and one to mark the save. Yep. It's and we'll get arguments on the fact that it should start with I. Yeah.

Well, I say all you got to do, but it's all you got to do is create these nine classes. Right. And that's the thing. Like it ends up turning into that. Right. But where you should start is getting it functional and then breaking it down further. If you don't have hard, you know, hardcore specs to push it out in the first place i'm kind of backing off that idea though because i feel like if you just start with make it

functional first then you're probably not going to go back and refactor it and you're probably not going to make it testable so i kind of like the idea of instead of saying make it functional first say make it testable first and that starts for that's kind of for legacy code like if you can try to keep with that mentality i know it's imp impractical, impractical a lot of times, but I'm trying to kind of convert to that mindset. Actually, you know what? I attended a meetup with a will where they had done extreme programming,

pair programming, and they had kind of walked through an entire role playing situation with it. And you know, doing the test first, isn't it really that hard? If you actually sit down and dedicate yourself to doing it, it's really not that big of a deal. So, I mean, you might be onto something and, and that almost forces you to refactor as you go, right? Because they even did the same thing. So they would set up a test and then they would do whatever they needed to make that test pass. And then they would try and clean it up a little bit. Right. Well, I mean, we talked

about this, I think in the last episode, right. The test driven development that if you're going, if you were truly going by, Oh yeah, it was because last one was the comment. No, it was two episodes before that were comments. Right. I think it was like 49, but yeah, we were talking about like, if you were truly the test-driven development format, right, then you write your test first. You write the bare minimum amount of code that makes the test pass, and then you refactor, right? So those were like the circle of life in a TDD world, right? And that if you were following TDD, then you never have an opportunity to comment on the code because never in the TDD life cycle does it say, okay, write the test now, write the comments

about what you're going to write and then write the code and then refactor and then refactor your comments and then test. And then yeah, you just do it. It's never a thing. Right. So, but I mean, going back to what you just said though, Joe, like I feel like the refactoring thing's still there, right? You still want to write your code in a way that makes sense. But then at some point, and we've talked about this in the past, if you have to revisit something and put in an if else, then maybe that one time's fine. But if you have to come back again and do another else, then at that point you start need to think about, wait a second, if there's all these cases and I need to probably pull this thing out into some type of subclass or, or something like that. Right. So I don't know. I think, I think the refactoring is still a key piece to it. Yeah. Just, uh, the testability things, um, just kind of rough. And I feel like if you don't add it up front or if you don't, you know,

pay that investment down, then it just doesn't happen and uh the code gets harder and harder to test and it's kind of digging yourself out of a hole right so i'm just trying to approach things from that viewpoint and writing the test when i can and trying to at least start there and even if nine times out of ten i end up just saying this is too difficult to write a test uh that makes sense then you know whatever but at least starting with that thought and trying to make things better yeah true did we hit this point right here nope nope we need to oh yeah no this was a really good one uh yeah this was this, actually. So procedural code, code using data structures, makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

And so that's really important, right? And this is where having the book will help you a lot because this, this particular chapter was extremely code sample heavy. Um, but when they were showing the procedural thing, like they had the whole notion of a shape and then they had like a circle, a square and that kind of stuff. And basically they'd have a function in procedural code, something like get area. And then it would say, Hey, if the object passed in was type square, then do with times height. If the object passed in was a circle, then do, you know, whatever that formula is, what pi r squared or whatever. So the thing is,

now, if you come in and add a triangle later, now you got to go back in and touch the code that touches all that other stuff. If you just had a class and you introduced a new triangle class and OO methods, then you would just have to implement that area and you could do it for each individual class. So that was really the big distinction between the two. And I think that's a really easy way for people to be able to see it. But here's the, here's the best part of this though, right? So it also said that the compliment is true, right, of the quote that you said. So, you know, to summarize, you said that the procedural code makes it easy to add new functions without changing data structures. OO makes it easy to add new classes without changing functions, right?

And so the complement of that was true is that procedural makes it hard to add new data structures because of all the functions that must change, which is the example you just gave. And OO makes it hard to add new functions because of all the classes that must change. Yep. Right? And my favorite takeaway from this chapter was this quote that he says, so the things that are hard for OO are easy for procedures, and the things that are hard for procedures are easy for procedures and the things that are hard for procedures are

easy for o so there is no there's no win yeah well it kind of goes back to do you remember uh an episode or two ago we were talking about um uh you know i i was i was sharing some of the things from a recent conf specifically uh from connect tech right and and actually one of the listeners james there was a functional uh talk that he gave and he was making the comment about like hey you know if you were a builder right then your tools of the trade might be a saw a screwdriver and a hammer and you would never say dude, we're using hammers from now on. They are the new awesome thing. Right.

Right. And no more screwdrivers, no more saws. We're just going to use hammers everywhere we can. But yet, you know, in, uh,

code programming circles, right? You often hear developers talk about things like where it's like, Oh no, man, no, you should totally be using functional programming for everything that you can use. You should do functional programming or you should try to avoid inheritance.

Inheritance is so evil, man. It's composition all the way nowadays. I don't know if you've been reading Reddit, but if you check Hacker News, this is what you should be doing. And so those kind of conversations happen in programming circles, right? And, you know, Uncle Bob here is making the point that like, well, you know, there are things that are easy for procedural and there's things that are easier for OO. Use them.

Yeah, for OO. Use them appropriately. Yep. I like that. And just to kind of think about it a little bit so i can think of examples of procedural code all day long like a you know checkout process for a website like i go get the data structure representing the user i get the data structure uh representing the cart i get you know the checkout object whatever i get these data structures oh yeah i go out i choose charge

i go do these procedural type things i say get this then do this then do this then do that very procedural what's an example of oh code uh-oh in which part i mean like so so for instance like in the checkout process right like when you go to get money so the procedural way would be if paying with credit card, go do this. If paying with PayPal, go do this. If paying with Amazon, go do this. Instead of that, you would have like an iPayment, right? And that iPayment would be like charge customer, what we'll call it, right? And then so the payment instrument passed in could be of type PayPal, it could be of type credit card, it could be of type whatever. So you're mixing the two still, right? You still get to have your procedural things because you still need steps to be followed. But then when you get to certain portions where there are different things that do the same general thing, but have different implementations, that's where

your OO comes into play, right? Okay, cool. So in a checkout example, we're adding PayPal now before we only took credit cards. In a procedural example, now it's easy to add new functions without changing the existing data structure. So I added data structure for PayPal. So like new database tables or something. And I'm able to add new functions without changing anything. But in the OO example, I can add a new class representing PayPal, and I don't have to worry about changing anything because I'm literally not touching any code in the credit card stuff. It's totally isolated. Well, wouldn't it be more like in the OO example,

you would just have one method charge, right? And you don't even know what type of payment system you got. I know I've got something that implements this interface, or maybe I have a pointer of this type, and I'm going to just call the charge method on that type, and it's going to call the right one based on the actual type that that method is. Yeah, like the interface billing method. There's your OO example.

Say billing method dot charge, and you don't care. Except for PayPal, it has all sorts of weird back and forth stuff that makes that really i can never remember the name of that in o terminology of what ah that thing that i just described like polymorphism there you go polymorphism thank you yeah because so i mean the the difference is if you're going to do all that procedural you'd literally have an itself in his elf right and yeah you should have an is elf and is elf so yeah it is that time of year isn't it true you never add just one if you add if on the checkout page and you add it if at the you know confirmation and you add it if you add it if you add it and that's the thing so so let's take this example a little bit further and this is why it's important. So in procedural ways that you go about this, and we talked about this a couple

of chapters ago and I don't even remember which one it was, but the whole idea is if you find yourself doing a switch statement somewhere, chances are you're going to be putting that in a lot of places. And so you're, you are now, yeah, gremlins and you're creating procedural code all over the place because you're saying, if this, then do this. So in your checkout process, if PayPal, then go make this call to this website API. If, if it's a credit card to make this call to your credit card processor, right? Like, so that's all your procedural. So guess what? Now, when you go to do a refund, you're going to have the same, if else condition, You better hope that you caught them all because otherwise you're going to have a problem. Well, remember, this is the book that was talking about that you should only be using the switch statements inside of factories.

And that's what I'm saying. So because the problem is, if you don't, now you're definitely not using O.O. And you're going to have to you're going to have to basically copy and paste those those switch statements everywhere. You're doing a new piece of functionality, which is your procedural code, right? So that's really where you start getting that divide. And that's where things become very important of drawing that line.

Yep. Which is a good time to bring up the law of Demeter, which is the next section. And this is one of the things, one of those things I've looked up like at least every couple of months, like, cause I always just forget, you know, I know principle least knowledge, but there's some specific rules around it. But I just always have a hard time remembering this guy. And there's some really arduous definitions. And the simplest way I can think of to boil it down is to say that a method of a class.

So a method should only call methods or properties in its own class right methods or properties on objects created in that method or objects passed in via arguments right so this was kind of uh know, if we skip ahead into the train wreck conversation. Well, actually, you know what, before we do that, there was one thing I wanted to comment, which was just a quote about the mature programmers know that everything that everything that the idea that everything is an object is a myth, which I thought was a good one. But I don't know. Do we want to get in the train wreck? Because we actually had that. Yeah, I say let's wait for that a little bit.

I kind of like talking about the law of the meter just because it's an interesting thing. And I know that it's going to come up here in a few minutes. But I was kind of interested to see that it was written about initially in 1987, which is a lifetime ago. So it's interesting to see that people were still kind of talking about it. And that's, I guess, when kind of OO was first kind of coming around. So it was interesting to see that people are still struggling with it like 30 years later.

Dude, well, let's clarify some things here, right? Because it says methods or properties in its own class, right? So to expand this out a little bit further in OO, it would also be the subclasses like any kind of inherited property type stuff right like anything that is within the ecosystem of that particular class is really what we're talking about right well yeah i really want to skip ahead no we can't skip ahead you can't do that all right fine i tell you what can we can we go ahead and do

uh let's see what you got here well so why is this important first of all like why do we even care what we talk to why can't i just go and talk to methods in other classes oh dude so it tight coupling right like all of a sudden you now have this dependency that you have to have there. And, and being that I haven't read ahead as far as I should have on this one, like I always think about it as like the puppet master, right? Like what it's just what you said here, whatever's creating objects knows about those objects. So it's, it's fine to talk to all its kids, right? Because it created those kids. They can do whatever it wants with them, but those kids shouldn't even know about each other right they they they shouldn't they shouldn't be intertwined at all and if any interaction needs to happen between two kids it should go through

the parent right whoever created that kid yep should be the mediator and the thing is you don't all the times you won't end up with one puppet master that wouldn't be such a big deal what ends up happening is you have a bunch of puppet masters and they're all kind of got these weird dependencies on each other you can't even really see what's going on and then it's untestable because you know some of those dependencies inevitably talk to you know things that are hard to test and hard to mock out and so you just got these ties all over the place and that's literally where the term you know spaghetti code comes from so just stuff tied together all over the place yeah i this is funny this leads me into something that is somewhat not related but somewhat sort of related and it comes up in our slack all the time like i'd say this question comes up or

this particular comment comes up once a week maybe more more frequently. Hey, what should I do? Should I do Angular 2? Should I do React? React. And so here's the funny part. Like my answer, even though I'm not as familiar with React, my answer is almost always React. And the reason is if you actually buy into the fuller ecosystem to where you do React plus Redux. If you're doing web development, the thing is, is it does exactly what Joe just said. Instead of having all these like, you know,

tendrils that leach out all over the place and you can't follow it. Like angular one, dude, you get into multiple bindings and you cannot make heads or tails of anything. And if something goes wrong, it is, it's frustrating with react. It's got this one way data flow. If you're using Redux to where you can actually just see, okay, this talks to that, that thing over here, a minute event that went to this. And it's like a big circle. Like you can literally follow it. And to me, a big one-way circle.

Yes. And so it's very easy to reason how things are happening and when they happen and why they happen. And that's important. And that goes to this law of Demeter right here is if these methods only talk to things that it knows about because it created it or because it was a part of its own class. You now have something that is very easy to reason. When you start breaking that rule, man, things go wrong. And I've seen people do like global variables and we all did them right.

Like the very first thing you did when you started coding anything is you made some global variables cause they were easy to access. And then all of a sudden you couldn't figure out why things were going wrong because everything was touching it, right? Yeah. I got so much I want to add to this, but I don't want

to step on the future stuff. I'm trying so hard not to, man. Well, let's get to it then. Just have like a... I need a zipper. And then throw away a key. All right. Well, we'll be back right after these words from ourselves. Our own sponsor.

Yeah. So if you want to sponsor the podcast, you should write to us. Yeah, you totally should. Yeah, definitely. And in the meantime, we're loving those reviews. This episode is sponsored by Joe's mom. Man, that's not... What if his mom wanted to sponsor?

Why would you deny her that? Now who's being mean? I wasn't being mean. Just move along before... Anyway, we love those reviews, so keep them coming because we really appreciate that's how we find new new listeners and that's really huge to us and uh so we we love reading them and uh thank you so uh please leave us reviews and you go to codingbox.net slash reviews to do that joe you look like you're gonna fall asleep we need to pass some caffeine across the wire here

everyone can see me squinting more and more as the episode goes on now if you watch this video Joe, you look like you're going to fall asleep. We need to pass some caffeine across the wire here. Everyone can see me squinting more and more as the episode goes on. Now, if you watch this video, can we can we do that yet? Because if you can, I'll take some of that caffeine. Pass it along. Why are you holding out on me? You're right there. Oh, all right. So let's get into my favorite section of the show survey says

all right so the last survey was the new mac pro with touch bar is it a amazing Apple's done it again. They've predicted the future and Touch Bar is it. Or is it horrible? Give me my function keys back. Or is it, well, the jury is out. I'll wait and see what others are saying before I pass judgment. So I pick Joe. You go first. Well, obviously nobody is going to wait to pass judgment because, you know, this is the Internet after all.

So I'm going to say death 90%. Horrible. Give me my function keys. Give me back my function keys by 90%. Now, remember, prices, right rules, right? We're mixing, you know, family feud and prices right here, right? We're mixing Family Feud and Price is Right here. 89%. 89%.

That's brutal. Okay. I'll tell you why I'm about to pick what I'm going to pick because you guys remember when the iPad came out, I was like, dude, who is going to pay $500 for an enlarged iPhone that has no cellular connection, right? I was obviously very wrong. So I think that a lot of people are going to say, I'm going to wait and see the jury's out on it.

So I'm going to say that's that one at 45%. All right. Well, this is interesting because you both split it up, so that makes it cool. And I think the last one where you picked the same thing. So survey says you're both wrong. Really? If we're playing by Price is Right rules. One of us picked the right answer.

In which case, I would say that Joe is more correct than Alan. Yeah, boy. Because he picked the right answer. It's not 90. Well, yeah. So, yeah, totally. Like 46% of the vote was horrible. Give me back my function keys.

Wow. And 44% of the vote was the jury is out. Oh, I was close. Wait, no, I won. No, I was off by a percent. Yeah, you missed it by a percent. That's what I'm saying. Like by Price is Right rules, you lose.

Wow, that's ridiculous. I nobody that said it was a good thing. Well, no, if you will know there were there were some people surprisingly that were 12% and here was the thing. It's like I kind of felt... And I read this in like... I don't remember if it was like some other well-known place, like an Engadget or something like that.

And they had a similar... Like after we had recorded and posted this, they had a similar topic that came up. And I actually thought, oh oh theirs is actually worded better because it was um you know the regarding the new mac pro like well okay which is better having this touch bar or just having a touch screen touch screen totally like why wouldn't you just make the touch and when they when they wrote that i'm like oh yeah the whole time i was looking at this new mac pro i that never even that thought the only thought that occurred to me was,

oh, my God, I hate this touch bar. Oh, no, man. I've been wanting a Surface Book version of a Mac for so long, and I think Apple's just being Apple, and they're just not going to make it because that's what everybody wants. No, no, no. I'm with you.

What I'm saying is if you were going to add touch to anything, why didn't you just make it a touch screen rather than the touch bar? Yeah. Like leave the inputs and the input devices as is. But you know, like you said, time will tell. Maybe this thing will be a huge,

uh, you know, success. I, I am more in the jury is out category personally only because, uh, I, I'm, I concerned,

would that be the right choice of words for it? Probably not. But I kind of feel like I'm doubtful that it will be correct in my usage pattern, which is multiple OS on the same piece of hardware. So, you know, like trying to go through a VM and with that touch bar, I feel like that's probably not going to work. So like, you know, like trying to go through a VM and with that touch bar, I feel like that's

probably not going to work. So like, you know, if it's a parallels or a VMware or bootcamp, I just feel like that's probably not going to work. And then if you are booted directly into one of those, you know, into that OS via bootcamp, for example, I just don't have a lot of faith that the drivers are going to be great there either. Yeah. You know, it's funny. I did read a few things about the touch bar. And one thing that people seem to love is the volume slider because it really, so I kind of get it. Like you don't have to like, you know, tap, tap, tap to go up and down. Right. I get that. The, the other piece of feedback that i've seen is that people hate the fact that it's not tactile right like if they put that same force touch that's in the mouse up there in the bar

so that when you actually click something you feel something like it did something that would be huge and then the other thing is they feel like so much of what has been done for it so far it's kind of gimmicky right like it's it's to show that those features are there but hopefully as software you know people start writing the software to take advantage of it then maybe they'll do some things that actually make sense but yeah it's hard to say yet well i gotta tell you some of the examples they showed in the in the keynote speech for it i was like oh that'd be horrible i i totally wouldn't want to do it. And maybe it's because I just have like fat chubby fingers because like they showed trying to scrub through like a timeline of something.

And I'm like, well, now I can't see it because my fat chubby fingers in the way. Yeah. It's covering up half the touch. I got this meat paw in the way. Like what? How do I get to see what I actually want to see? I can't.

Yeah. I don't love it. I really want a touch screen, but I guess we beat up that survey. Yeah. I'm not. I'm not so crazy crazy about this touchscreen as much as you are, though. But, yeah. All right, so then there's the next survey, right? So we did have a comment. So I guess there was some controversy about some things that were said in the previous episode.

And so one of the there was no controversy there was you well there was comments everyone there was comments let's put it that way there was discussion you know discussion is good the important thing is is that you get people talking yes okay so so i'll take that as a success. I got to get it where I can. But there was the idea thrown out there about like, well, hey, why don't we make the next survey about the ordering, preferred way to order methods within a class. And I thought about that. I'm like, yeah, maybe.

But I really feel like that's going to make for boring show fodder because I can already guess that Joe and Alan are going to guess the exact same answer with almost identical results. So that's why I was like, ah, it seems like that would be a boring survey though right how would you know what we'd pick i just just um you know a gut feeling maybe i hope you have a bit of slack because yeah that that feeling would be overwhelming i mean if i had to guess now i would probably say like, you know, one of those answers would have at least one vote and the other answer might have the rest of the Internet. And that's data structure hiding right there because you would say percentage of this versus percentage of that.

But, okay, okay. So not to, okay, I totally don't want to get back into the newspaper. Versus alphabetical. Well, just the whole newspaper holy war. Like I didn't even realize. Like I think that was like part of the thing that was almost as shocking to me was just like oh my god i didn't realize that this was like a holy war thing you know like like like if you start if you get into like a var wars conversation if you even hear somebody talking about that like you're sitting at your cubicle and you hear somebody you're like oh god

i'm staying out of that i already know where this is going i'm putting on my headphones and we're gonna crank up the bass and this is done right right? You know where that conversation is going. If someone starts talking to you about tabs versus basses, you're like, well, date night's over. You don't bother, right? I did not realize that this was as

heated as it was. Was it heated? Was it heated? Okay, maybe heated was a choice. it was so that was okay. Maybe he knew was a choice. I don't like how I pitched. This is more like one man stand against society.

I was thinking the same thing like in a game of risk. If you have one soldier on this side, it like a thousand takes on this. Is that a war? This is totally fair. Okay, so we'll call it the last stand. Totally fair.

Although I do really like how high-pitched Joe's voice got just a minute ago. We're like, is it really? I don't even know if I did it correctly there. But yeah, so it made me like truly have some reflection on this, though, because honestly, and I don't mean insults to anyone, but like everybody made all these cases for like why? And I'm like, yeah, okay. I mean, I get that.

But yeah, you haven't convinced me. Like I'm not – not that it's your job to convince me but but um you know it's a you know i i hear your case but i i just don't see it right and the one person who i want and i wanted to give him credit because the one person who i think came the closest with any kind of comment or feedback or whatever you want to call it that was more persuasive to you know at least get me to start thinking about like well okay fine was jw so on the comments for episode 50 and if you haven't already read it i I'm not going to read it for you. It's a little bit, you know, long, but you can go to episode 50 and read it. And he really made some good points there. But in general, and this wasn't even like the exact wording that he said, but like at least the general tone that I took away from it was, well, we have things that we consider to be, you know, uh, best practices, right? And

maybe we can't always, uh, adhere to those best practices and maybe that best practice doesn't fit every scenario, but it doesn't mean that we shouldn't strive for that best practice, right? So even though like time and again, I was able to like poke holes into the newspaper metaphor and, you know, things that I felt like, well, these are the reasons why I don't like it, right? Like here's all the scenarios. I don't know why you're laughing. Here's all the scenarios. No, seriously. You know, I listed like, you know, multiple scenarios. They were like real world scenarios where it's like, oh, this is where you can't put things in a newspaper metaphor, right? Real world scenarios where you can't. So, you know, he, he at least got me, I mean, his, his comment alone didn't persuade me,

but it did keep me thinking because prior to his comment, I was honestly just more leaning towards, you know what, maybe, maybe I should just more embrace random. Because going to Alan's point in the last one, you said there was some comment that you made where there was some quote that was something along the lines of saying that, how did you word it, something about not having an IDE, not having an IDE to use was just a cop out. Right. And I'm like, okay, well, if we take that case, right, then I

should just embrace the ID that I have, in which case it doesn't matter where it is. So, okay, fine. Just add them wherever you feel like adding them. Right. But, but it was, and then shortly thereafter was when JW's comment came in. There's kind of like, okay, fine. Okay. I take that point, right? Like there is this best practice and maybe I should try to embrace this thing. And you know, cause I didn't realize this was as heated as it was. So it did make me go and look at like, um, it made me think like, well, man, like real world examples. Have I just been missing,

misreading this this whole time? And I just thought like they were in this ugly mess of random ordering. And yet this whole time they've been in some kind of a newspaper metaphor. Right. And so I actually found some like interesting results in that. That like, so for example, I think it was last episode that we had talked about microsoft being one of the largest contributors to github right so i thought hey how does microsoft do it right i mean we're using uh you know well we as dot net developers

are using a lot of their tools right and their frameworks and everything and now that uh they've open sourcednet, let me look under the covers of.net. I'm curious to see how their actual code is done. And, you know, because for so many years I've been looking at their code through the eyes of a decompiler, right? Um, and so it was like, okay, well, how is their code actually written? And so I found some interesting examples where, you know, it was just kind of ugly and, but yet for the most part, not entirely, it was in a newspaper metaphor, uh, case, but there was access level, uh, intermixed in there. And I remember that in the last episode, um, Joe had specifically kind of gotten tripped up on like, Oh gross. You know, now if you do it alphabetically, uh, you'd be

sorting your, your privates to the top and your publics to the bottom where I had tried to make the point a couple of times that no, no, no. Uh, you know, the, the accessor was like you know consider that like a primary sort and method name was a secondary right so the publics were were still up above but it made me go back and realize like oh wait a minute you know if you look back at that chapter uh he doesn't really talk about accessor level right like he doesn't talk about except for except for like private instance members that's the only thing that he talks about but like uh public and private methods he never refers to like oh you should have these uh separated one way or the other right which i think was kind of like what you were talking about last time joe about like not having your private methods in in your public's

intermixed right did i misinterpret that, but we are absolutely stepping into this argument again. No, no, no. I'm not trying to. I'm honestly not trying to. No, I'm just telling you my findings. I know, but then it's going to make me want to tell you my findings. But I think you can find examples of code with controversial decisions all over the place,

Microsoft or whoever. I don't know that I've ever seen a real world example of you know good no what i'm saying well hold on the point the takeaway from that though was that i saw that microsoft had it intermixed and then that made me go back and think like oh wait a minute and then that's why i realized oh well uncle bob didn't even specify the the access level so i wasn't trying to like restart the argument it was just more more like, Oh, this, this, this finding made me go back and relook at, uh, re reinvestigate the words,

right? Yes. So somebody's opened your mind up basically. Yeah. Yeah. So, I mean, you know,

there, there, um, yeah, I mean, I guess like the takeaway is like, well, okay,

I'm not, I'm not bullish enough to say like, I know everything. And that's ever, I can never be convinced of anything. So like, based off of all the strong responses, like, okay, well, obviously this is a thing. It would be foolish of me to not, uh, you know, try to try to go this way. So I'm like, okay, fine. I'm actually going, you know, start going this, this direction and see, you know, I mean, it'll take some time, obviously, you know, maybe, uh, eventually I'll be like, okay, yeah, I like this way better. Or you know, I mean, it'll take some time, obviously, you know, maybe, uh, eventually I'll be like, okay, yeah, I like this way better. Or maybe I'm eventually like, oh God,

no, I still hate it, but you know, it seems to be the thing. So I'll do it or whatever. Right. I don't know yet. We'll see. But, um, yeah, I mean, it was, there were, there was, there was other, some, some other things too, where like, um, some comments, like you mentioned in the Slack channel, about, well, IntelliJ automatically sorts it or whatever. And I actually found out, at least for ReSharper, which I've got to assume that they're using similar engines, it doesn't. As best as I could tell with ReSharper, the comment was that if you extract a method using IntelliJ or ReSharper that it would automatically put the new method in newspaper metaphor order, right? And what I found was that it doesn't necessarily. What it really does more without much logic behind it, I guess you could say. I'm not trying to belittle it, but it just literally puts whatever code you extracted

directly below the method that you're currently in. And it'll keep doing that. Yeah, I see. So it doesn't go in order. It kind of stacks them. Yes, but it'll stack them. Let's say you have a really long method, right? And you extract a little bit and then it takes that method, puts that below the really long one. And then you extract a second method that maybe is called after that previous one that you just extracted.

And it'll, again, just put it directly after the really long one. So now it's before the previously extracted one and if you just kept re-extracting new methods right it's just going to keep tacking them on uh you know after the long method right so they'll just keep stacking on top of the new extractions right and and it'll also not care about accessor level right which is where i was kind of going back with you know rereading the the that portion of the book was that it youSharper, IntelliJ, well, I still haven't played around with IntelliJ as much, but at least for ReSharper,

it doesn't care like public, private, internal, whatever. It'll just literally mix them in top. But it also made me question too, because I couldn't find this answer answer was that in the newspaper metaphor um you know if you have let's say you have a total of three methods right method one calls methods two and three we're spending a lot of time talking about what's not the survey this episode yes but but but what i'm asking you guys though i'm asking you guys a question which well this isn't the survey but is the um um method one calls if method one calls methods two and three

then does the order of two and three matter right because in the i didn't see that in the newspaper metaphor right it didn't really call that out and going back to like an intellij or something like that uh you know they didn't put it in that order like they didn't put them in the order you know it was like literally just extracting it and stacking them on top of one another it was just curious finding whatever yeah yeah it's definitely not the way i'd expect it um so it's kind of like a it's like it's almost like the worst the worst way to do it oh what stacking them like that yeah it did yeah and and i and and uh i got kind of curious too because like there was this uh the finesse project that

was referenced in here and it's an open source project too so i went poking around at it and actually found some stuff where it didn't adhere to the newspaper metaphor so i couldn't help but find that kind of funny but that goes back to your point about like you know nothing's gonna be perfect right i mean there's always gonna be like uh you know little things here and there yeah so what's our new survey so alan with a no answer there. Yeah, I guess the takeaway was just that, you know, I'm going to try it, whatever. All right, so the new survey is, there was a conversation that we had related to tables, right? So, you need to add a new column to a table, and you know that that column will more often than not be null. All right. So do you add

them to the existing table because that's where they belong is, I guess, leading the jury or or your second option is create a related table that will only have the records when needed. That's also leading right now. You're going to have less records. Yeah, those are your two options. So maybe an example is like you've got a user table and you want to add like a super user column, right, to designate some guys, some people as having elevated permissions.

And you know that you're going to have, say, less than 1% of these users marked as super users. Do you go ahead and add the column and then have, you know that you're going to have, say, less than 1% of these users marked as super users. Do you go ahead and add the column and then have, you know, say you've got a million records, 999,000 records with null? See, null is a little bit different because in this case, I think it'd be kind of a zero. So I think the situation would really... What about email? What about email?

Yeah, email is probably a good one. It's like you're only going to have an email address for a very small percentage, and the rest is just, I don't know. It not a it's not a true designation you know like it is for the super user it's truly saying i don't know and i don't know if i'm ever going to know so do you add that to that column and then your column just keeps your table keeps getting wider and wider as you add new columns for things like that and And if not, do you break it out into another table? What's the line there? Is there a percentage?

So I have another example, just so that we make sure that the jury gets the equal leading here in either direction. And that is, so you gave the example of a user with permission, right? In your case, I think it was like super user permission. Well, let's go with email because that one makes more sense. Because a super user, like you said, that's always going to be a zero or one, right?

Like that's pretty much what that is. Isn't everyone going to have an email address if they're on your system? No, no. Let's just say that it's an internal thing and maybe they want to put in their personal. Who knows? But email is something that you...

I feel like that's not one that people are going to visualize most easily as easily though because more often than not the person's going to have an email address okay credit card i mean either way the the the super the permission one was actually a really good example regardless of the data type right it was the point being that you're going to have some small percentage of time where it's not going to be true a majority of time, right? So the flip side to that example would be address or contact information, right? If you more often than not, street two is going to be null. Okay. At least here in the U S right. More often than not, that's going to be null, okay? At least here in the US, right? More often than not, that's going to be a null field, right?

And if you're not crazy about that example, then the other example would be, and this is why I say contact information, extension for a phone number. More often than not, extension is going to be null, right? So those are the two kind of contact type scenarios where it's going to be needed, but you wouldn't necessarily break out a separate table

for street two or extension. Or would you? So let's take both of those examples. I mean, that's what we're trying to find out in the survey. But let's take both of those examples and let's, that's what we're trying to find out in the survey. But let's take both of those examples, and let's take it even a step further just to illustrate the point. So the reason I don't like address and I really don't like phone number is because there's multiple types, and usually that's a one-to-many relationship, right? We're kind of talking about one-to-one relationships.

But let's just say, for instance, that you had home address on the contact, and you also had home phone on the contact. So the extension and the street two are both in question so now here comes the other part of that right do you when you break this out do you create a table that is contact address supplemental and then do you create another one contact phone number supplemental you see yes i mean i hear you i i mean if i'm just saying my vote now is that because it just sounds like joe did so what's your thought joe i think if we um do a slightly uh different example that i think we might be able to kind of clear up the question a little bit more and we had talked about vehicles earlier right and the vehicle could be a plane a

car you know whatever so what if we've got a table vehicles that has cars in it, planes, trains, bicycles, and now we want to add essentially a column to a vehicle to track the size of the gas tank. Well, trains don't have gas tanks, right? Bicycles don't have gas tanks. So now we're adding a column that doesn't apply to every row in this table. So I'm trying to figure out at what point do we break that out to a separate table if it's a one-to-one relationship still? Like is it, you know, do we break it out because it only applies to a certain percentage of the rows? Do we break it out because it's a logical unit? Do we keep it in the same table because it's a one-to-one relationship?

Like what do we do with that? Yeah, it's an interesting question because if you go to normal form, you would basically break each one out into their own tables if there was ever a possibility of it being null, right? Like that's the rule of complete normality. What is it? Third normal form? Like, I think that's the, uh, the best one, but so, I mean, really it's an interesting business question because what you're talking about, like size of gas tank, if you add that to a million records and it's null, most of the time there's space being reserved on those records for that data. Yep. And it's even messy, you know, because the next thing you know, I'm adding number of steam pistons for my trains and number of spokes for my bicycles you know yep and then the question is at that point

do you just create a sub table of that for trains one for planes a database person would probably say yes you do that but but then you start talking about performance and all kinds of stuff but really it boils down to do you care about relational data more than you care about performance or ease of access, right? That's really what it boils down to. So we definitely are curious as to what this survey is going to turn out because this was a real world problem that came up

and there were several answers thrown out. And I don't think anybody agreed on any one of them. Yeah, we know we love our controversies. Yeah, we do. so that is our survey and that's the end of the newspaper metaphor oh wait i'm sorry yeah i want to get back to that for a second no no just kidding i will click end well uh somewhat relevant uh the next topic in objects and data structures is train wrecks. And in this case, they're actually specifically talking about function call dot function call dot function call.

So my kind of prime example there is like jQuery, where you kind of do like a dollar sign and you get your A tags, right? And then you do dot class equals this, dot underline equals true or whatever. And you basically chain these methods together so you get dot, dot, dot, dot, oftentimes on the same lines. And so it ends up kind of looking like a train in the editor. So here's... Is that a problem though? Well, it is if you're trying to stick to the law of Demeter there.

Yes. So here's this great little thing that I thought was so beautiful that we talked about in the last episode that kind of made it relevant here, which was in the, I don't know. Yeah, we were talking about horizontal width and spacing and whatnot in the last episode, right? As well as the newspaper metaphor. And there was this question that I think Alan asked that Joe answered, which was like, well, how many times do you dot your method, right?

Like, when do you break it out to a new line? Like, how many dots do you go before you break it out of the new line to in the in joe said two he's like well you know you do like very you know some var dot method dot method dot method you know by the time you get to that second dot you're on to a new line right yep three is too many. Well, apparently more than one if it's a method that's going to return back another object, right? And that you're going to then call another

method on that object. This book needs an edit. But wait a second, though. In fairness, though, going back to what it said earlier about classes need to know or they can do things with classes that they know about that they created right like i would argue that that's what that is like no no it's not you have a you have an object in your in your in your uh in that function right all right or method whatever you they uh whichever one you choose to call it, you have a class, some object in that method,

and you call dot some method on it. Okay? Now, if you dot again, you're now interacting with what that object returned, which means you now are aware of the internals of that method. Because it exposed it. Because you're expecting it to return back a particular thing yeah but again that's something you created so you're

aware of its children as well and its children it doesn't have to be something you created it could be it could be uh you're using something in the dot net framework right so you do i got i can't think of a good example here joe i don't know if you got one off the top of your head, but I have one, but not.net. Back to our checkout example. You know, we said, you know, we were talking about checkout. You're buying some stuff. Imagine you've got a checkout method and it takes a person and you do some stuff with it, like getting their name, their email, whatever. But you also get person.billingaddress.zipcode, right?

There's three dots there. It's, you know, three references. So you're starting to dig deeper there and you're making a train but you're aware of it because you're the one that instantiated the person or it was passed into you and so everything that i would i would argue that you're not breaking any kind of chain of dependencies there because you already instantiated that person, that person instantiates it's, it's billing address.

The law of demeanor has nothing to do with chain of dependencies there. But, but the whole thing that we said is it can access things within its classes or things that creates, if it creates that person, then by that very line of thinking in my mind it also has access to whatever that person has access to like i don't think that's i i unless i'm totally missing something in that that law it doesn't make sense that you can't interact with whatever that class you

created and by getting its billing address if that's what it exposes you are well within the bounds of the class that you knew about. I think Demeter would disagree, unfortunately. If you did, if you had, okay, let's go to the, and I was trying to look for a real life example here and fell flat, but so I missed the example that Joe said, but I think it was something along the lines of if you had a customer and you said dot get payment method and then some payment methods return and then you said dot get billing address right then now you're you are intimately aware of what get payment method is going to return and so you know about

its internals right and what it's going to what it's going to do right and you're doing this all inside the same method and again keep in mind this whole this whole book is about keeping these methods short right so really the idea here is that that should have been done like the the get billing address call should be done in another method right it's not that it can't be done in the same class necessarily it's just that it wouldn't be done in the same method yeah it's right you're doing the puppet master thing you're reaching out to stuff that are like three and four steps away. And I did find an example in.NET Framework

is the HTTP context, one of my favorites, ha ha. HTTP context.current.session.userID, for example. It's something where your method, by taking that context, only when it needs a very specific part. And so ideally, you would just pass that user ID in. But if your function is doing other stuff with like the session or the you know the current context or whatever then it's kind of um you know

it's useful to cheat that and just pass in a higher level and pluck out the stuff that you need but that's a sign that you're doing the pupper messages but pub message stuff again you're doing too much in that method and you know that's what I would do. The example that he gives here in the book is like you have context.getoptions.getscratchdir.getabsolutepath. I would totally do that. I mean, we've all done it. But the point is that it's too much intimate knowledge in that one method that breaks the law of the meter. I mean, that goes back to one of the previous chapters where they say, try and keep things on the same level, right?

And yes, you could do that with refactoring out and creating new accessor methods and that kind of stuff. So yeah, totally. Well, it's funny you say accessor because he actually makes it a point to say like, okay, well, you know, is this breaking the law or not? Right? So if these things that are being returned back are just, uh, the, if they're just data, then it's not, it's not a, uh, violation. Right? So, so if these are simply, if get options dot get scratch dirt dot get a absolute path,

if each one of those is just simply an accessor method, then it's just, it's just returning back data. Then it's not a violation. But if each one is an object and it's having to do something to figure out like, okay, well what is the scratch directory?

Right? Let me go and query this other thing and like, Oh, here's some environment variables, and let me parse the environment variables, and it had to do a lot of logic in order to determine the Scratch directory, and then it's like, okay, here's the Scratch directory,

and then based off of that, it's like, okay, but what's the absolute path of that? Okay, well, I got to go and do all this interpretation. Then that's where it's breaking the law, right? Like if it's, I can't help but think about it as I say that, but I feel like that kind of almost supports what we just said. User dot get payment method dot pay, right?

You didn't do any logic there. So how's that any worse than an accessor? I guess is what I'm getting at. Like, you know, if you're going to go all the way down worse than the accessor again, he was saying that if you, if it's just simply accessor methods, then it's not breaking the law of Demeter. If it's returning back objects, that's what I'm saying. If you're not actually using logic,

like you literally said get payment method dot pay, what we're saying here is that's going too far. Because you dug into your person, you say go get the payment method and pay, so you chain down two levels, right? So it sounds like that's kind of not allowed, which, I mean, for better or for worse, we're all going to do what we need to do to make it happen. But I feel like maybe that's one of those cases where it's like, am I really going to break that out into another method? Well, why not take the billing method? Like, why go through the customer?

And the answer is because you probably already have the customer for some other reason, right? So it's just a matter of doing a lot of things in one spot. And so you're doing the puppet master thing, right? You're dealing with the customer. You're dealing with payments. You're dealing with other stuff. And this is where I was saying, like, it could still be done in your same class, but it should be in a different method.

So you would pass in the billing method or the payment method or whatever. Whatever was more specific, you'd pass that into another method in order to adhere to this law of the meter, right? Yeah, that's interesting. So we also have a note in here, though, about like using the fluent, right? Like, so if you're doing like a link statement, or something like that. Yep. And I thought about this one, actually, the deal with that is, though, is at least with, you know, like a jQuery style is you tend to return yourself. So in that case, you know, I'm kind of okay with it. And I don't really think that violates. But I guess it depends on

which side of jQuery you're doing. Because if you're saying, get me all the A tags, get me the ones that do this, get me the ones that... You are shrinking, but it is kind of at the same level of abstraction. So I'm kind of two minds about it. But I like fluent interfaces. I feel like they're readable. And I feel like the whole reason to avoid trainers is because it's not very readable and it's spaghetti-ish.

But I feel like fluent is not that. So I feel like fluent gets passed from me. Well, it's interesting too, because there's an article I read and shared a long time ago that I think was also by Bob Martin, I think that was using pipelines for, for data. So instead of like for each is so like the, a way that a lot of people have done things historically is, you know, in your function, you might have list my list of people equal new list of people, right? And then you'd have a for each that would loop through and try and find out if any people match a certain criteria and then add them to your list above. Well, there's an article and I'll have to find the link. But basically, the whole idea is, Hey,

you know, instead of doing these four each is with all these if conditions inside of them, just do a link type query to where you say people.select.where this equal this.where. And then that way you populate that list and it's very human readable, right? Like you look, okay, I'm getting people where their last name is smith and where they are over the age of 30 right instead of nested for for each loops that they keep checking different conditions and then if it meets that condition adding it to some list that was defined outside so that whole thing too is also another dot train wreck i guess but that's more a sign of i guess the, the language than anything else, right?

But is it, though? Because in the example that you're talking about, though, it's data that's being returned. So you do your dot select and your dot where. I mean, like each step of the way, and going back to Joe's jQuery example where you're constantly refining the list, you're still just working with data. You're not getting back some new, um, completely different type of object that you have to know that like, Oh yeah, this object has this other method that I can call. Right. But you can, you can totally project to a new object, right? In that entire flow of things, you can project whatever you want.

It could be a new object. It could be a different type of object. It could be whatever. I mean, okay, sure. We could, we could always write bad code if that's what we're talking about. And we could sort it out. I would argue that that's not necessarily bad code because what, what if you just need, what if you just need the, the person ID, first name and last name, and you don't want to return all the information about a person across the wire, it doesn't make sense for you to do anything other than dot select and then new object first name last name id right like that's not bad practice oh in the case where you're talking about like an anonymous type that's being well i guess it couldn't be anonymous that's not bad code that couldn't be anonymous in that example though but yeah that's just needs based and i, that's just needs based. And I guess that's what I'm getting at.

Yeah, I feel like that example is still data. I mean, it's a very big data example, though, at least in my mind. I mean, again, we've all done some of this stuff. I guess where it would be more weird, maybe if you did that projection and then instead of just returning the projected result, you were to do more dot chains afterwards, then that's where maybe it would get, at least in my mind, out of the data realm.

By the way, it wasn't Bob Martin. It was Martin Fowler. So I found the link. We will shove it here in the show notes right underneath this. So potato, potato. Yeah. Yeah.

Martin something, right? It doesn't remind me. I'm actually, uh, Martin Fowler wrote, wrote, sorry,

Martin Fowler wrote the next chapter of this book. It was not written by Bob Martin. Oh, really? It's like everything we've talked about so far has been written by Bob Martin. So, good to know. Awesome. Cool. Alright. Did we already kind of talk about hybrids earlier?

Well, yeah, but I wasn't sure if Joe It sounded like Joe had more he wanted to say about it, but maybe I misunderstood. Yes, but in the meantime, I did mean to say Michael Feathers, not Martin Fowler. Everyone's got this straight, right? There's some name. There was an M name in there.

We're not great with names. Hey, wait, was that my M name? Oh, wait, no. You got the initials right. Yeah, so the deal was basically talking about hybrids, where we've got objects mixed with data structures. So we've got a class that's got some properties, and it's also got some methods.

And he's pretty stark on it. There's a nice quote I don't have in front of me right now, but the way I think of it is, I'm writing it as basically inferring that it's kind of the worst of both worlds because it's got properties which are just begging to be modified by other procedural code, and then you've got methods which are supposed to kind of act on its own properties, and so it's just a mishmash of people kind of poking around with your stuff

and then doing your own. So you're kind of like letting the world mess with your insides, which is not comfortable. So this is like some sort of surgery. Yeah, this is why we wear clothes. That was like episode number one where, yeah. We got off to an awkward start, folks.

So can you think of any good examples of a hybrid, like let's say in the.NET world? That just exist out there in the wild? Yeah, sure. I've never really gone digging don't know well you know one thing i'm gonna give you one i'll give you one okay go ahead joe mine wasn't dot net i was just thinking about an example where um where you know it's where you've got properties and you've got methods and then um i was thinking about dependency injection which is kind of a common technique uh for you to basically have um properties on your class

so you specify them at the class level or the object level rather um rather than passing them in as arguments and that lets you do things like dependency injection where you get things injected at runtime so you can kind of have different services and whatnot different dependencies specified at like you know app time and at test time and that's an example where you do want to have properties and you do want to have methods in the same class so there's that well uh the the best example that i could think of that for better or for worse that might be considered a hybrid here would be the date-time structure in.NET. Because it is a structure,

but you can very easily forget that it is with all of the methods that it has, right? Yeah, definitely. It's an awkward case. I know some people have mentioned it before being kind of controversial I'm not a big on smart properties either I think that's kind of part of the confusion oh you don't like ones where gets have implementations

no I just think it's kind of confusing it's unintuitive I don't like that datetime.now doesn't equal datetime.now. Ever. Unless there's some crazy optimization stuff going on. Oh, here's an example. I can't get behind

that smart property, though. I mean, maybe in that one example, but I guess as a general rule, though, I think it can be a little bit more expressive sometimes or it feels like that maybe i'm wrong uh yeah it looks pretty i just don't like the date time dot now i mean i still do smart properties all the time but how about this one uh sql command you can do stuff like say you know command equals new sql command then you could

say command dot timeout equals this, command.whatever equals that. And then at the end of it, you can say, you know, command.run or you pass it something else to run it. I kind of forget. But it's just an example that's got methods mixed in with things that you can set. It's kind of weird that you can, like, run your query and then set the timeout. You know, it doesn't make a lot of sense. And so it's just a matter of allowing people to mess with your internals. Well, I mean, that is an interesting example,

but I can't help but be a little bit distracted by it. Doesn't it make sense that Joe would bring up this weird example that would be SQL related? Doesn't that just seem so fitting? I love me some SQL. He does. I love handcrafting my SQL and my SQL commands and executing them. D? D, really?

Oh. It's a three-letter acronym that I would mention, but this is a clean show. So what's this hiding structure that we have here? Yeah, there was this another comment, and I feel like we might have talked about this too in a previous chapter. Actually, I know we did.

I don't remember the name of it, though. But we should be telling our object to do something and not asking about its internals. Right? Does that ring a bell for either of you don't remember uh one of these chapters talking about something like that there was a there was even a name for it i can't remember it now i didn't really get much out of this little section um i think i'm just missing something except for i did notice it used the word admixture like a d m i x t u r e which is very distracting to me so i've had a hard time

focusing on anything except for that weird word yeah what you're talking about outlaw is right here it says if e-text is an object we should be telling it to do something we should not be asking about its internal so yeah that's totally what it is it goes back to the command query separation that's the what i that's the name i was trying to remember okay um going back to chapter three on functions right was that you know you should ask it to do something you're not trying to get you know how many gallons of gas does this tank have you know uh left or like what's the capacity in gallons, you're trying to really just say like, tell me, you figure out what you got to do to tell me what percentage of fuel is left. Yeah. Oh, and your ad mixture thing.

So that also goes back to one of the previous chapters where they're saying don't mix things that are different levels of depth in the same method. That's really what he was saying, right? That bothered him that this whole get the path and going down and doing all this stuff was really there just to create a file, right? Yep. All right.

So everybody's favorite type of object. A Poco. It's the DTO. I feel like if that was a car, it would not be made by Pontiac, though. I feel like a lot of people don't talk about DTOs anymore. I don't really hear those words. Am I wrong about that? I use them.

I guess we use the word model a lot of times when we, you know, same thing, data transfer object. Yeah, you know what? I think you're right. I do use DTOs or I use the actual acronym DTO when it literally is just something that's being used to marshal something into and out of a method somewhere. So I do call them that. I like things like entity framework go

and they, you know, generate all those classes. It's basically, we'll get to it in a minute, but it does generate the data transfer objects as basically, you know, simple properties, but it's also got those kind of save methods and some other niceties that you can call on it, which are just extensions, but I guess that kind of moves it

into active record territory. Yep. And I didn't really have a lot of feelings about that. Like, okay, yeah, I mean, if it's a DTO, I guess my feeling on it was like, where do you draw the line, right? So you have this, it's a DTO if it only has has data but now is it still dto if it has these properties plus one method if i add two methods if i've gone too far and now it's now it's hybrid or now it's not a dto anymore man or is it three minutes i feel like this is going back to our our survey with the table on newspaper metaphor i mean sorry table column with uh we got confused there man i actually ran into this today and it kind of irritated me as there

was this dto there really wasn't a dto because i had these methods like get from record or create his params or whatever and i saw it and i was man, I hate the name of this. And I didn't change it, but I added my own method to it. It was like, I feel really dirty about this. And I feel like calling this a DTO is wrong because it implies that it's a stupid object, right? It really does imply that all you're doing is setting properties on this and then using those properties somewhere else. They are supposed to be exposed properties. But as soon as you start adding functionality to it, it is no longer just a transfer object.

Yeah, I mean, I guess prior to this book, the whole term active record wasn't something that I was familiar with. So I have always just considered DTOs as being plain dumb, you know, just data, right? I mean, if you go back to like the days of like a C, for example, then I equate them to a struct, right? And this idea of having like, you know, some number of methods in it that maybe it's still, you know, a special form of a DTO called an active record.

I guess, I guess. You know, you guys just remind me to talk about the DTO. Would you say that's a good signal? Like if you're adding methods to classes that you're probably doing things more procedurally and if you're adding classes to a project, then you're probably doing things more procedurally. And if you're adding classes to a project, then you're probably doing things more OOE. I mean, I feel like this is a trick question from a previous conversation in this chapter.

Not that one's better than the other. It's just, you know. That's a tough one. I mean, I guess it really depends on the situation, right? Like if generally speaking, if you're adding a method to a class, so let's go back to the whole simple shape thing, right? So if you have a triangle circle in a square and you currently have a get perimeter and get area, you know, maybe, uh, what's another thing that you can do on it? Well, let's just say that you only have get area and you want to add get perimeter.

You have to add that to multiple classes. So you're adding a method and you're doing it in a very OO way, right? Because you have to add it to all these things if you make it polymorphic, right? So, so I think there's a line, right? Like if you just find polymorphic right so so i i think there's a line right like if you just find yourself willy-nilly adding a bunch of methods to a particular class then maybe not but in certain situations like maybe you are trying to refactor and break out things into a more you know newspaper narrative type of way of doing things um so you end up getting like a bunch of private methods in there. So I don't know that that's necessarily bad either. And that could still be a very OO way of doing things.

And some people argue that OO is not even the right way to do things. That's true. Do people still use beans? Do Java people do beans? Yeah, dude, I've seen them. Well, that's one thing I was going to bring up, though, is that several times in this chapter, they make the point that beans throw a lot of this out the door

because they'll have getter set methods for no other reason than because they have to adhere to some bean standard based on the framework that they're playing with at that time. But I kind of wondered, too, though, though i mean isn't that a little dated i mean you're saying that you still see it but i mean it's definitely a very java thing it is it's a very java thing in very specific java world yeah because it's java beans and are those java worlds still that big a thing i don't i don't know because I'm not in those worlds. Yeah. And haven't been for a while.

I've seen generators that do that stuff, like on somewhat recent projects that I've worked with. I mean, because my experience with it is very dated because it goes back to WebSphere, right? Yeah. Well, that was big time. You don't, yeah, yeah. Java beings and all that.

Do you hear a lot of people talk about Westfair these days? I, at least in my circle, I don't. But maybe your mileage may vary. Yeah, I don't know. I mean, the active record thing kind of reminds me of Entity Framework, right? That's very similar type stuff, the.save or even... See, I don't think of the active records as Entity Framework. I feel like what Entity Framework returns back are just straight up objects.

I don't consider them active records. No, you can totally change them and do dot save. There's a truckload of methods that it includes. But you can still dot save. Yeah, you can dot save. So if you make a bunch of changes to it, it tracks the properties. Okay, so you're saying the active record is defined by having a dot save method? It's basically...

Because my point is that the entity framework objects have a bunch of other methods associated to it. Oh, it does have additional things. So that's why I'm saying it's not a special DTO. I'm saying it's a straight up object. It's an active record. So like a DTO is not necessarily our special forms. Okay. So I see what you're saying.

Yeah. I mean, it kind of falls along the line of active record in my opinion, in that you modify an object and you tell it to save it, state back to whatever it's. I mean, for the, for the record though,

like in here, he's not saying that it's necessarily an active record, that it has to have a save method. He does say that they typically have navigational methods like save and find. Right. Right. I would say they're very similar. Like, I don't think it's called that in the.NET world, but they are very similar. And it looks like there's some chatter about that, actually.

Yeah, Ruby specifically calls it Active Record. Active Record, yeah. I was going to say, I know I've seen that in their world, and I'm not in their world very much. There's actually a pretty good answer here. We'll have a link in the show notes. I'm talking about the differences between entity framework and active record. So like where it's similar and where it departs.

And it's kind of a long read, but it's pretty interesting. Awesome. Coolness. One more thing for me to be corrected about. Yeah. No, no, no. No, I think it's kind of agreeing and disagreeing with all of us same time i'm just making a joke man making a joke oh don't take away from my joke all right

so that uh well we're gonna wrap this up but i i wanted to point out there were two really good quotes that that closed this chapter out that uh i would be remiss if we didn't say, and that is that objects expose behavior and hide data. Data structures expose data and have no significant behavior. Yep. Which is a really great takeaway from this chapter. Yep. So with that, in our resources we like I'm pretty certain maybe we'll be including a link to this book I think

I think once or twice we may have already done it a few six seven times and also again remember if you'd like to win a copy of this book and see the stuff that we've been going through on here definitely leave a comment on this episode at www.cuttingblocks.net slash episode 51.

Yeah, it's definitely good stuff to think about. And it's short. Yeah. And now we get into Alan's favorite portion of the show. I'm not sure why he's making that face, though, for everyone watching the feed. My booty hurts. There was definitely some oddities there as I was trying to introduce this next section. I promise.

We've got video now, too, so that's rough. I promise that no matter what face he just made as I was trying to introduce this section, this is absolutely Alan's favorite portion of the show. It's the tip of the week. Yes, sir. All right. So what you got? All right.

So for those of you that are fans of the Adam editor, if you ever find yourself working in a file and you got, you know, your tree, your navigation tree over there on your left of all your files and you're in, you know, maybe you you can on a Windows machine, control shift backslash, or on a Mac, command shift backslash, and it will sync your current file to the tree so that you can get back, you know, if you needed to see the other files near that one for some reason. Love it.

I find that to be a handy little feature that I use more often than I care to admit. But do you actually use Atom that often? Spoiler alert. Yeah, I've actually switched from WebStorm to Atom. Wow. So if you recall, I think that was also connect tech um a few episodes back and i talked about watching one of the presentations and the guy was using adam and the various plugins that he had and and

how he was able to just navigate through it so quickly right and uh specifically in his talk he was doing uh it was a react talk with uh unit testing and you know as he was doing. It was a React talk with unit testing. And as he was doing his unit test, he was able to just see his results all within the Atom IDE. And yeah, not only was his talk just a very well put together presentation, but it was actually a very persuasive use case for using Atom. That's really cool. So I have, at least for the time being, made the switch to Atom. And I got to say, I really love it, man. It's very fast.

Better than Visual Studio Code? Well, if you recall, back when Code came out, there was, you know, shortly after Code came out, I did kind of like take a comparison of them on this show, of Atom versus Code, because they're both based off of Electron. So, you know, under the hood there, they're both the same internals, right?

And there are some things that I liked better about code. And I even like commented back to Microsoft, like, hey, this is like really odd. Like, for example, I don't remember exactly, but like one of the examples was like, there was a file delete and a file save all option. And then they were dangerously close to one another um and i was always afraid to hit that option yeah but um after seeing adam with all of the uh plugins that uh this guy was using in in the presentation it

just kind of made me switch to going to adam and now i mean i guess long story short maybe i don't care so much because you know they are both electron based but i care so much because all the plugins that i'm using are atom right and uh so i and i've just kind of gotten used to it so like as i'm going along on this path of using atom more and more then i'm like okay well you know i want to know like where the key uh you know, I want to know like where the key, uh, you know, what, where's the similar functionality that had over here? Like, so for example, um, comparing to visual studio, not, not code, but just plain old visual studio. If you were in a file and you wanted to see it in sync with the tree, uh, this in the solution explorer,

um, above the solution explorer, there's this little icon that has two arrows pointed in opposite directions, right? One arrow above the other. And that would sync the file to the tree list, right? Or in WebStorm, if you wanted to do the same action, there's a... Looks like a target. Yeah, a little target symbol uh like like if you were looking through the scope of a gun for example um you know the the uh what do they call that the

reticle um you know and that would sync the file to the tree so now that i've switched over to adam i'm like okay like this is an example of like man how do how do I switch back? Like, how do I, I'm in this file and I only got to this file because I did something like a, um, a control P and just started typing in the name of the file and then like, yep, press enter. And you know, now I'm working that file, but Oh gosh, now I'm in this file. Wait, there was a, this is, I'm looking at the controller for this file for this class. There's a corresponding model that's right next to it. Where is that? I'd rather not retype all that again so i can just control shift backslash and oh there it is and double click it or something like that right like or if you're

just trying to like browse around and see the other stuff around like that's where i kind of find that being able to keep the file in sync to the um to you know, on a need basis handy, right, in that kind of scenario. But, yeah, I've really been digging at them. Cool. All right. Well, mine actually came from Jay Belina in Slack today. So we were talking about various different ways to kind of marshal data

to and from proc calls. And the old school way that we've probably all done is like if you need to pass in a list of things like IDs that you need data for, the way that you used to do it in the old days before these even existed was you would basically pass in a string like a comma delimited list of ID numbers

and then you might have a function in SQL Server that would split that string and turn it into a table that you could then join on, right? Like that was the way that we've done things a lot. Well, Jay Belina actually hit me with, hey, why don't you just pass a table valued parameter from C sharp up to SQL Server? And I'll be honest, I didn't even know you could do it never really thought about it but I've got a link here and in the link you can go up there and you can actually from c-sharp take a list of data and pass in I think it's called a structured um yeah sqldb type dot structured and you could literally pass in a data table to get the information. So that's really kind of cool. If you have a, if you have a stored procedure and it will take a

table value parameter and it has a particular schema set up and you do that same thing in your C sharp code, you can pass the entire table in and filter it that way. So that's kind of sweet. No more parsing lists and stuff. So I do want to play with this to find out what the performance is like, see if they're kind of on par with each other. But that is pretty awesome. Cool.

And my tip of the week is a YouTube channel that was recently introduced to me by our friend Yipter. And the guy's name is Sarajili. And he makes really cool AI videos doing stuff and he kind of specializes in doing small little easy things so it'll be like 10 lines of code that can play a video

game like an old Atari game or something and he puts all the code up there does a lot with the open AI and the videos are really cool they're really well produced he's got just amazing hair so I recommend everyone check it out. Because it is so short, you can literally watch a little 10-minute video, take those 10

lines of code, and then just start exploring this. If you have any interest in machine learning or AI, this is a good thing to get into. Man, I'm totally not watching it. You said he has hair. I'm jealous. He's got amazing hair. It wobbles to and fro and he dances his head around.

It's amazing. I really thought this was going to be... I clicked into it to see. I was really kind of surprised because I thought this... Joe, you had shared another YouTube channel here recently, or at least I thought it was you. Yes. That was the one I thought this was going to be.

What was it again? Share that one, too. Yeah, that one was my tip last week. Oh, was it? Maybe that's why I'm thinking of it. That one was really cool too because it would use a couple of common libraries to do things like drawing really cool fractals and stuff.

And so it was just a nice way to watch a 15-minute video and learn something completely new and cool. That's right because we talked about the fractals because Alan did some fractals at the summit. I did. Yeah okay i made organic trees so some some videos here like build it yeah and there's drawing trees i think very similar to what you're doing f sharp there um videos like building neural network in four minutes or tensorflow in five minutes or um you know how to write an ai bot for any video game in 10 minutes. So, cool stuff. Very cool.

Yep. All right. Well, we hope you've enjoyed another chapter here as we make our way through Clean Code. This was Chapter 6, Drawing the Lines Between Objects and Data Structures, as well as Procedural vs. OO. And subscribe to us on iTunes, Stitcher, and more using your favorite podcast app.

And be sure to give us a review. You can visit www.codingblocks.net slash review, and you can find easy links there to iTunes or Stitcher. And if you have other places where you found us, let us know. Yep. And make sure while you're up there, check out our show notes, our examples, discussion, and more.

And send your feedback, questions, and rants to the Slack channel. And follow us on Twitter at CodingBlocks or head over to CodingBlocks.net and find all our social links and other stuff. Yep. Awesome. And that is a wrap on episode 51.

5-1, baby! Wait, what? We can't do that now. That's just 51. All right.