Coding Blocks - Object Oriented Mistakes

Episode Date: September 18, 2017

Allen brings the dad jokes, Michael unplugs, and Joe gets a second wind as we discuss the anti-patterns found in object oriented programming.

What does a nosy pepper do? I got nothing. It gets jalapeno business. Oh, that's very good. That's very good. Alan finally learned what dad jokes are. Yes, I got a dad joke. Awesome.

That one made me smile. You're listening to Coding Blocks, episode 67. 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 feedbacks, questions,

and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our

social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. This episode is sponsored by Linode. Linode has data centers around the world in multiple regions with plans starting at only $5 per month.

Take control of your VMs with the Linode API, manage them from the command line, all with out-of-band console access. Deploy your next virtual Linux server in seconds using Linode's amazing management tools. To get a promotional credit of $20 towards your Linode hosting fees, go to www.codingblocks.net slash Linode, that's L-I-N-O-D-E, and enter CodingBlocks17 to get started today. It's like your first four months are on us. All right. So let's get into our reviews. Uh, big thanks to everyone who left us a review. And from iTunes, we have Adam Curtis, Alfonso, Stefan age, Woody11309, and Satmo.

Yep, and big thanks to Stitcher Reviews as well. We got, this is hexadecimal, 00F3. I did that on purpose. Yeah. That's awesome. Appreciate it. And for the full show notes, as always, you'll be able to see them on CodingBlocks.net.

For this particular episode, go to C codingblocks.net slash episode 67. And in the world of just kind of, you know, not fun news, I got this article the other night where Elasticsearch servers are basically being targeted for putting point of sales malware on there. So I have a link in the show notes for this. And it appears that the companies or the entities out there that are trying to do this, they are targeting specifically right now AWS instances of Elasticsearch that haven't been locked down. So if you happen to have any Elasticsearch instances out there, definitely go check out this article. And they even have a link in it to how to harden your Elasticsearch instances. So I highly recommend doing that.

I highly recommend anything that you put out in public. Make sure you've taken the time to harden that. Right. So when you commit your keys into your GitHub, your public GitHub repository. Right. Use a good password. Yeah, yeah. Make sure it's strong. I mean, because if somebody else is going to find it, you don't want to be embarrassed

when they see it, right? Exactly. Don't put your dog's name. This whole time it was monkey? Right, yeah. Don't put your dog's name in there. You got to obscure it. Just don't name the password password.

You know, whatever variable name you're setting, whatever, you know, you got to obfuscate it. You got to twist your video, Joe oh okay all right there we go for all your listeners all right um you've got you've got a bit of thing that i mean the big one is obviously uh you know apple announced how they're going to take all my money which kid are you giving away to get one because i from what i understand it's going to take an arm a few children yeah it means both i mean i'm not going to get the like entry-level iphone come on good lord man like who else thinks this is ridiculous like this thing they're talking about 1150 decked out right 11,150. That's more expensive than gaming laptops. Well, I don't know about that.

It's in the neighborhood. You can go buy a gaming laptop for that same price, right? Man, that's getting steep. I mean, when they started hitting $700, I was like, man, things are getting expensive. Now we've gone 50% more than that. It seems like my first one was 400 and I thought that was crazy. Yeah. Like it's getting, it's getting ludicrous at this point. But you know, another thing that was annoying about it though, is that the storage options, they went, it's, it's, you either get 64 gig option or you get a 256 gig option, but there's no middle ground and it's like ah i'm already

using more than 64 so i guess i'm gonna have to get the other one man yeah it i think i'm out of the phone game for a while like i'm happy with what i got and it's gonna be a few years now i mean i got the six and it's still bent for all it's all these years now it's been bent like i'm just gonna wait on the on this one for a little bit and see what's wrong with it. What's the killer feature you got to have on this? I mean, well, okay, so from my perspective, there were a few things that were like the big things

that they talked about, or that would be like why you might want to get this phone. Size is a big important part of it because it's not you have more screen than the plus size phone but it's in size wise it's in between the plus and the regular phone right um but and and that's all because you have the edge to edge screen so there's your like big reason is the edge-to-edge screen. And then there's other cool things that they did on top of that. So there's no buttons on that front face, right?

And so they got rid of the Touch ID, which I think they were saying was like, there was like a 1 in 50 million chance or something like that that somebody else might be able to unlock your phone with their finger. Right. Um, or maybe it was like 50,000 or so. I forget.

But then, you know, the number was like an extra digit larger for being able to unlock it with your face. And they were talking about, cause the new technology to unlock it with your face is face ID. Right. And they were showing like how they had created all these like hollywood masks that they were

using to make sure that it couldn't be tricked by something like that but you know there was kind of this uh uh you know the internet kind of did its thing it went a little crazy because when they went to go demo it live did you guys watch it no joe nope so when they went to go demo it live, did you guys watch it? No. Joe? Nope. So when they went to go demo it, unfortunately, it seemed like it didn't work. It seemed like it failed, and I'm being very careful with my choice of words there. So seemed versus?

So I don't know. I have no idea. I'm going to totally mispronounce his last name, but Craig Federici, I think is how you pronounce it. versus so i don't know i have no idea i'm going to totally mispronounce his last name but craig federici okay i think it's how you pronounce it i'm probably really messing that up but um he he was the one who did the presentation for uh or the demonstration of the new iphone 10 which by the way like every time he does one of the presentations his presentations are usually awesome and they had two phones up there and he picked up one and he went to unlock it with his face and it looked like it failed. And so

he was like, after a second attempt, he's like, okay, let me go to the backup. But the thing is, is I went back and I looked at the video for it. And because there was this article that, um, there was something about like how he, it really did exactly what it was supposed to do. It wasn't a fail, but everybody thought that it was in the audience. Right. But really what had happened is, uh, they said after the fact is that other people, while they were setting it up, must've been messing with the phone. And so the phone thought that they were trying to unlock it because even with touch ID, if you get too many failed attempts, you'll have to enter in your passcode before you can re-enable touch ID. And that's what had happened on this phone was that too many failed attempts

had happened. So you had to enter in. And he didn't want to type in his password while everybody was watching or video was rolling or whatever. Well that, or I'm presuming that he probably just thought, you know, Oh, this one, let's not even, let's not even attempt it. Right. It's not even worth it at this point. Let's move on. Interesting. Yeah. Yeah. I don't know.

I've gotten to the point that you mentioned many, many episodes ago about where just the phones, like there's nothing really all that, you know, yeah, they're faster, they're bigger and it's just like, okay. Yeah. I'm not going to pay a grand for, you know, a half inch more screen. And I'm sorry, that thing with the face. So that sounds like the kind of crap that I tell my, my project manager. I'm like, no, that's not a bug.

It's supposed to work that way. I mean, it's unusable and it sucks to use and no one would ever think it works that way. But that's how it's supposed to work, so it's fine. It's like, what, I'm not supposed to take my phone out at a birthday party or something? Because it might start getting logged because of all the other faces. I'm kind of curious to see how this is going to work. Oh, because another thing too is that you have to have your eyes open. You have to look at it.

So you can't... So in other words, because one of the things that people have kind of joked about, you know, you could be asleep and your kid takes your phone and unlocks it so they can go and play games and buy stuff or whatever, right? And with the Face ID, now you can't do that. But then one of the questions that I had was like, well, I guess then for someone who's blind, for example, who might not open their eyes,

like they could use Touch ID. That wasn't a problem. But Face ID might be an issue if it requires that you're looking at it right they just probably won't get the iphone x right and then it was like well how would you use this thing at night because there was a there's specifically uh lights for that but then yeah it's like it's all kind of curiosity right now because you know it's not yet available in our hands but it's like how is this going to work at night like am i going to be blinded every time I want to unlock the phone because it's going

to shine a light in my face? Because there was like, there was like a regular light and then an infrared light. Right. And then it was going to shoot out dots on your face so that it could measure that where the dots were. So the real question is though, have you already decided that you're going in and buying this thing next Friday? Oh no, it's not available next Friday. Oh i thought it was no well no so all of the

okay so then they announced the apple tv 4k the series 3 apple watch iphone 8 and iphone 8 plus all of those will be available for pre-order tomorrow. Oh, okay. This Friday. Okay. Right. And you get them next Friday.

Okay. iPhone 10 isn't available for pre-order until like October 27th. Okay. And you don't get it until like November 3rd or something like that. Of 2018. No, no. Well, yeah,

it's going to be interesting to see how the constraint, how constrained it is. Especially around holiday time. Yeah. You know, that stuff's going to get, I mean, they know how to do this, it's going to be interesting to see how constrained it is, too. Especially around holiday time. Yeah, you know that stuff's going to get crazy. I mean, they know how to do this. They got 10 years of experience with it. Yep. Cool.

All right, so that's the fun news. And then, Joe, you got something cool to share here? Yeah, we just passed 2 million downloads, which is just crazy. That is crazy. So much misinformation. So much. Misinforming people for 2 million times. Yes.

That's awesome. So thank you, everybody who listens, participates in the community, all of you. Like, seriously amazing. It's shocking. Yeah, we really appreciate those reviews.

That's a huge part of it. So thank you very, very much. Yeah, definitely. So that's really all the news we have today. So I guess we're going to start jumping into this particular episode, which is object oriented anti patterns.

And this one's sort of near and dear to my heart here because we were talking about domain driven design and it's kind of come up. Like when heart here because we were talking about domain-driven design and it's kind of come up like when you hear domain-driven design, they're like, do not use anemic domain models. And some people are probably like, what is that? So here you go. The anemic domain model, it's the use of a model without any business logic. So typically they call them bags of getters and setters a lot of times, right? Like they'll just be a bunch of properties with getters and setters and no behavioral type methods on them. The domain models objects cannot guarantee their correctness at any moment because their validation and mutation logic is logic is placed somewhere outside of that class. Um, and I'll go through

some of these things like Martin Fowler's the one who kind of came up with this whole notion of the anemic domain model. At least that's what it says in the Wikipedia article. And he calls it an anti-pattern. Maybe it's not always an anti-pattern depending on how complex your, your system is or your application is, but you know, whatever they do say though, that anemic domain models, they're, they're kind of contrary to this whole notion of object oriented design because data and your business logic, whatever that is, should be combined. Like that's kind of the purpose of object oriented programming, right? Because you're meeting those two and operating on them. Um, you'll typically see

these things as standalone classes with other classes operating on them, like the business layer or Martin Fowler actually referred to it as transit transaction scripts. And he's basically talking about anything that would get data and mutate it all and then do a transaction and send it to the database and update all that data. So it's interesting that that is kind of how you see it. Now there are some benefits to this anemic domain model. You have a clear separation between the logic and the data, right? If you have, let's say an order class is nothing but getters and setters and properties. And then you have some other classes like, Hey, you know, do process orders or something like that. Then,

then you know exactly where those lines are drawn, right? It's really easy to see. It works really well for simple applications. There's not a ton of logic that has to happen there. We talk about CRUD, create, read, update, and delete, right? That's what we're talking about with CRUD applications. So really easy. This one I actually thought was important. It allows for stateless object,

which means that typically it's much easier to scale because when you talk about scaling systems out to where they can, you know, scale to more servers, more people, all that kind of stuff. Typically the one thing that causes problems in any system is when you have too much state, right? If you've got session state that you're trying to maintain or whatever and spread across so that one was kind of interesting it stateless logic right stateless logic right so spin ups a whole lot easier um removes the need for a complex db um or stateful mapping layer did i spell i didn't spell that right mapping layer um and then all right yeah. I didn't type it right. And it's spelled the Southern way.

Right. Easier to use with dependency injection and, and not even just dependency injection frameworks or anything like that. It's just creating the objects are simpler because they're usually not that smart. Um, you guys have any thoughts on these benefits here? Uh, we, we talked about similar type things before we talked about this notion, you know, DTOs, pros and cons, POCOs, POJOs, whatever we've been over all, all that sort of stuff. So, I mean, there's definitely benefits. I think when you use them appropriately,

if you've got them all over the place and you're handling the mutating and the kind of validation, it's all disparate, you know, it's dispersed throughout your system and that's when you have a problem. So how do you recognize when you're creating an anemic model? I think it's really easy, right? Like if you don't have behavioral methods in it, that's, that's pretty much it. If you just have a bunch of public properties with, you know, public gets and sets on them, you're kind of there, right? If there's nothing operating on that data, or very little operating on that data within that class, then you're kind of there, right? If there's nothing operating on that data or very little operating on that data within that class, then you're probably in an anemic model.

Well, I think, no, I don't know that I agree with that. Let me make sure that I understand what we're describing here first, is that when we talk about this anemic domain model, we're basically, I think kind of what Joe hinted at, it in my own words is that there's just you're just using a bunch of dto's right yeah that's it okay okay just had to make had to clarify but you're not necessarily using them for data transfer using them for other stuff right that's the key because you could use a truckload of dto's to pass stuff back to your client side, you might have DTOs set up for that. So it's not just the fact that you have them. It's when you're passing those DTOs into methods that are staying within the same realm. So they're like DTOs that exist on the server side,

that are staying in the server side, that you're passing around in the server side so that you can perform actions on them or about them right that's when you might realize oh i'm in this anti-pattern without them actually knowing anything about their own state right like they that's well they are state well that's all they are they can't guarantee a good state at that point so that's that's kind of what I'm getting at. Basically, what you said is correct, right? They're passing it around. Other things are manipulating them, but they don't know anything about their own correctness, I guess.

Well, let's refine that and say their good state is like they know nothing about their committed state, right? Like there's a disconnect there. That's what you mean? No, valid. So committed would be whatever's on the object, right? Like there's a disconnect there. That's what you mean? No, valid. So committed would be whatever's on the object, right? But let's say like, for instance... Well, I'm saying that like there's a disconnect between them and whatever stored in like a database, for example.

It could be. So there could be, that's where the disconnect could be, right? Well, I'm not even talking about that. I'm talking about more like validity type stuff, right? Like you couldn't go to an order object that's an anemic model and say, Hey, are you in a good state? It doesn't know anything about it. It just knows that, Hey, I have these things set in my properties, but there's no logic behind it. And so, and so it can't respond to it. And so you've got to use an external class to say, Hey, is this thing valid? And that's, that's where they're talking about

the anemic model. Like, so if any, like if you had another application that then wanted to come use this thing it couldn't just use it and trust it it would have to have some sort of type of service layer or something in between that could do all the validation and everything else for it okay and even at a very small level you know if you've you've got an edit form or something and you you know hit save whatever you're gonna go and set that first name set that last name set that whatever and there's no kind of big atomic operation so like things are in during the in the middle of that operation are going to be in an inconsistent state you can think of about like um you know non-thread or threaded multi-threaded environments stuff like that you know or if you know some sort of exception happens setting one

of those items and the object is just in a weird spot and we've got no one that really has taken responsibility for that change. And so it's just kind of weird. Yep. Totally. What's the downside? Like who cares, right? Yep. We've got a few here. So one is logic cannot be implemented in an object oriented way on these. So again, you took all the behavioral and state knowledge out of that object. And so you got to do it elsewhere. You've almost got to do more like procedural type things at that point. The violation of the encapsulation and information hiding principles. So this was interesting. So basically, they're saying that you lose this

encapsulation because it's not going to exist outside that class, right? The knowledge about that class is elsewhere. And the same thing about the information hiding. The whole purpose of encapsulation is to information hide, right? Like not everybody needs to know about the internal pieces of that class. They shouldn't. You just need to be able to call, Hey, process order. Right. And when you take all that stuff out of this, out of this class and make this an anemic model, then that stuff exists

elsewhere. Like it's, so that's part of it. Um, and as we said, it requires an outside class or layer to perform this business logic now. So you've broken it apart. And now that domain model, other than sort of just being a property transfer object, it doesn't really have much value outside of that now, right? Because it doesn't maintain any of its own internal state. The side effect of the domain object cannot guarantee its good state. It's just a dumb object. That's what we just talked about a minute ago. And it does, again, typically need some sort of layer to do its communication. If you're going to be, if this is like a core library or something or core domain models that you're going to use in various different pieces, right? Like let's say that you

have, you have a shipping piece of your application, you have a customer ordering piece of your application, then you have like fulfillment piece. Every one of these things is going to have to use some sort of service layer because that domain model doesn't give them enough information and functionality to be able to do the job that they need. And this is one thing that I actually really did like from domain driven design is when you don't make anemic models and you build things into them, it makes them more expressive. So by making this anemic model, you've made this thing completely non-expressive, right? So you have this order object and it has a bunch of properties on it, but what can you do

with it? You don't know because there's no behavioral methods on it. You can't say, oh, place order or hey, go do this, right? Well, I was about to say technically you can do nothing on it. Right, right. All you can do is flip properties on do this, right? Well, I was about to say, technically, you can do nothing on it. Right, right. All you can do is flip properties on and off, right? Like you have a wall of switches, but it's not really, I mean, it's almost like if you did, right? Like if you had a panel of switches on your wall, and they're not hooked up to anything,

there's no wiring behind it that says, hey, when you flip the switch, turn on this light, you're just clicking switches all over the place, and you have no idea what's a good thing, right? It's exactly the way I treat our mixer when you're not here he looked at it dang it let's pause that's awesome there are a lot of knobs on that thing so yeah so go ahead oh no go ahead yeah it's all you no that's that's what i was gonna say that that kind of wraps it up i mean you know all right yeah that's it well uh i was just gonna move

on to the next section uh which is something i researched called uh the base bean problem or base bean anti-pattern base bean or bean bean Bean, okay. One word, two capitals, Base Bean. And I guess the idea here is that it kind of stemmed from Java Beans, which have been kind of controversial. They were the way for a long time, and then they were definitely not the way for ever since. But the idea is that this problem is named for when you inherit functionality from a utility class rather than delegating to that utility class. And so the problem isn't that you're inheriting.

The problem is that you're inheriting for the wrong reasons. And so I got a little example here where, say, you're creating a video game and it has a car class. And it's got properties like weight and top speed, maybe color, things like that. It's got a method like accelerate, right? You hit the gas, it accelerates. Later on, you'd say you're making the next, you know, great Grand Theft Auto game or whatever. You go to implement some sort of bullet class and you think, you know what? A bullet's got a weight wait it's got a top speed it's got to accelerate why don't i just inherit my bullet from this car and i get that stuff for free

now the right answer here is to you know maybe recognize that these things have something in common pull out some sort of parent class maybe have an interface that you can strap on to kind of treat these guys treat these guys generically but the the problem that we're talking about here the base beam problem is when you inherit that bullet from that car because a bullet is not a car a bullet is in like speaking like from a domain perspective it's not the same thing it's not a child of this other object and so when other programmers see this they're going to be confused because you know why the heck is the bullet car is a bullet a kind of card that i don't know about is it some other concept is someone just being lazy you know it's it's confusing when you see it and can also cause problems later down the line when somebody adds like new functionality like

someone comes in and adds some seat belt methods to the car and all of a sudden now your bullet has seat belt functionality and also sometimes you try to treat things generically like you might do something like hey game objects dot you know get all the cars and you end up getting all the bullets too and so yeah it's just a little funky and bad practice so i did look at a little bit into why, you know, why we're using the term bean here. And I could see that beans kind of had a lot of extra functionality. And I guess the idea is that when you used to inherit from beans, which was kind of like the way of things, there were a bunch of rules that you had to kind of implement this method and that method name in a certain way. And so people would kind of end up kind of fudging those rules because they didn't care about

those rules they didn't care about those methods because what they were doing wasn't really like a bean but they wanted some of the functionality of that bean they wanted to be able to use some of the tools for inspecting those beans and and be able to do cool stuff with it but at the end of the day they these weren't beans and so there there were just some kind of domain-y, model-y problems that arose from that. Okay, so when you were saying inheriting functionality from a utility class, so in the bean example, that makes total sense. The car thing seems like that's not really a utility class. It's not.

Okay, so it's not a great example. I made this example up. This is not one I found on the internet. That's it. When my examples are good, it's usually from the internet. Okay, so I wasn't trying to call you out on your example. Way to go, Alan. Sorry about that. Way to go.

I apologize, interwebs. We've talked about utility classes anyway as not really being great. A lot of times they have functions that are basically static. They don't really have state or whatever. And so it doesn't really being great a lot of times they have functions that you know are basically static you know they don't really have state or whatever and so it doesn't really make a whole lot of sense anyway but conceptually i think it's the same kind of deal you know the the concept is the same we're inheriting from something that we shouldn't be when we should be delegating to it to do something okay i got you but it is geared towards the utility type classes out there that have functionality that you kind of want to borrow. Yeah.

Right. Okay. Yeah. And so, yeah, the car thing really doesn't make a lot of sense, although I still like it. I still like that analogy. I still think it's bad. It just doesn't isn't necessarily a base beam. You imagine a utility class that does things like accelerates cars or whatever.

And now we're inheriting from it rather than. And I feel like that's a much less common problem than inheriting from it rather than and i feel like that's a much less common problem than inheriting from things that are kind of unrelated i can't be the only one though when he was giving his example and he was saying like well a bullet isn't a mustang or isn't a car and i kept thinking like the bullet mustang actually is i'm like oh see kind of is but it's like a very specific one right a model. And I'm sure I've encouraged people to do this before. Like, Oh,

Hey, check it out. You're implementing some sort of new page that is like this page that I created or like this kind of conceptual model that I created. Why don't you just kind of inherit that or copy that or, or do something with that rather than, you know, recreating the wheel.

And, you know, what I'm really saying there is, you literally copy it literally implement it uh and what i should be saying is like why don't you refactor out some sort of common functionality or utility that you can delegate to rather than implementing it uh and you know obviously you know years down the road you don't know why something breaks when you change something that seemed unrelated yeah when you were when you were describing this for some reason in my own mind i was imagining logging like if you were to write a class that inherited from some logging utility class so that you could have your class know how to log right rather than just calling that logger or you know

having an instance of it and saying like hey hey, go write this out to a file. Yeah, that's a perfect example. Does anyone do that though? Oh, I'm sure. I'm sure we've all done it. I feel like my example is better. It's a better anti-battery. Your example was better.

By the time you guys listen to this episode, I'll have edited Wikipedia. Look out for the car and the bullet. Yep. So how do you know if you're walking down this path? Are you inheriting something at all? Then it's worth considering. I think we're probably going to get to this later.

It's worth considering whether my thing is or can be substituted for this other thing that I'm inheriting from. And there's the, the old list of substitution principle, you know, so anytime you inherit, you should really think about it. And if you're doing any sort of like throwing, not implemented exceptions,

or I guess that's not so much with, with inheriting as it is implementing. But yeah, just be careful when you're inheriting. Cool. So onto our next object oriented anti-pattern call super. Uh, so this is when you require your subclasses to call the superclasses overridden method. So let's say that you have some base class that has some really cool method. You're like, oh, that's an awesome method. And you subclass that base class, but you find out like, oh, that method wasn't cool enough because I actually need to override it and provide some of my own functionality. Uh, but that base class requires that you call it, um, in your overridden version. And it's the requirement that is the anti-pattern. Okay. So it's not the fact that you are calling it. It's the fact that if you don't call it, you break.

Yes. Okay. Yes. Okay. So why does this happen? How do we hear? So this is a case where the base class is assuming that it's going to be overridden by a child class and that the child class is going to augment some of the functionality or state that the base is relying on so in order for the base

to even execute that function itself it's expecting that the child has already done some stuff you know you know in order to make it possible. Right. And, uh, the, the things that that base class are doing, you can't get around, even if you were to try to, um, reinvent it. Okay. Everything that it's doing, you can't get around it because it might be setting up some operations or a state within that class or the framework that you might not even have access to. Maybe it's like privates, for example. You can't get to it, and it needs to set that in order for everything else to even function correctly. So you can see already how this is ultra gross because there's already this implicit knowledge that has to happen.

And I found this quote related to this topic from, take a wild guess who might have been the person to write this, but can we just call him the father of software development? Or at least I feel like he writes everything. Martin Fowler has this quote that is, whenever you have to remember to do something every time, that's a sign of a bad API. Yeah.

I like that. It's nice. I can agree with that. And so this is a prime example of this. Like, hey, you're going to subclass my super cool class? Awesome. Hey, just know that when you override this method, you have to call it in your method, right?

Yeah. I'm trying to think of, I mean, I think of initialized methods. I feel like there's been a few cases in a few APIs I've seen where there's like an initialized method that you can override because sometimes you need to do some stuff and they are giving you this, like this base class that you need to, to extend and do stuff with. And, um, and then they give you the option to, um, are they rather, they force you to call this, um, the super method, but the reason you have to call it and they can't do it for you is because they don't know whether it, like when it needs to happen, like, does it happen before you do your stuff or after you do your stuff or somewhere in the middle and um and

so you end up having to do that yourself i know ext does this where you have to call parent on a lot of methods if you override them but i kind of feel like anytime you're overriding the built-in methods you're kind of doing something gross anyway because they do have some other hooks for you to do things and so maybe the right answer there is like if i don't know if you need your stuff before after or both then why not have two hooks one for like before initialize one after initialize or something like that well before and after is like one of the ways that you can get around this right right um there was you know i i i couldn't i struggled to try to come up with, like, where is this problem really? It felt like, it seemed to me like I recall, like, old school Java.

I mean, we're talking, like, go way back, you know, into the 90s when the internet was just barely, you know, known. It seems like you used to have to in your constructors and things like that. You'd have to call SuperDot or BaseDot or something like that. But then I was like, wait a minute. I think that was optional. You didn't have to do it unless you wanted to because you specifically. But then it was like, why would I ever want that? Because those constructors are supposed to automatically be called,

so why would I ever need to call? so maybe the constructor was a bad example but that that was as close as i could get to and even then it was like gray and i couldn't really find anything well we got to be careful here right because like even in c sharp if you subclass something but you're not overriding it like say that you're calling the constructor right like if you have a subclass of something and you have a constructor and you want to call bases constructor, you can just say base, but that's like good practice. You're not forced to.

And I think that's where the description of this one is. You're literally overriding the base classes method and now you're required to call it. Otherwise things are going to get borked. And that that's definitely, I can't think of an example where that's required and I can't think of an example where I would have ever seen that either. EXT used to definitely do it.

I forget what's your methods, but you would have to this.call parent. Oh yeah. In order to call up the, call up the chain to the parent because it had to do some special magical stuff. And the deal is you don't want to just override their method because they're in order to call up the chain to the parent because it had to do some special magical stuff. And the deal is you don't want to just override their method because they're doing these crazy tricky things

that may change between versions and you don't want to have to change your code every time. So the deal is like just override wherever you need to because it's JavaScript, they can't stop you anyway. So just do whatever you need to and then call us and let us know at some point and hopefully it'll all work. What he's talking about is Cintia's EXTJS,

and one of the methods you're talking about specifically is the constructor. I think you were looking at that recently. But yeah, if you don't call parent, even in some of the render functions, if you override the render and you don't call the parent.render, or call parent render, then it won't render. And you'll be like, why didn't it work? Yeah, in JavaScript, so you can accidentally clobber their methods, but I'm realizing it. If you don't have good tooling around it, so it's really easy to just name a method,

whatever, and you've just destroyed whatever they've got. JavaScript. So how do you fix this? Yeah, right. So the number one way that came to mind for me which was coincidentally i later i was reading uh the wikipedia article on this uh template methods to the rescue we love those things and we've talked about them in during uh episode 16 man that's been a while ago too yeah so it was kind of funny like one of you said uh just a

moment like call me or when to call that and it made me think because uh we actually referred to it as the the hollywood principle uh don't call me i'll call you yep right that's awesome um and and that was where there was a one of the frameworks that was described referred to, let's see if I can find it again, the before and after, before, after, and around methods that you could use to guarantee when something gets executed, that it's executed in the order that you want.

It'd be kind of on the base class's responsibility to provide those virtual methods and have its own protections about like what it expects that that thing can or shouldn't do. And, you know, if it wanted to set, if it wanted to have an expectation that a certain thing happens after one of those calls, then it'd be on the base class to verify that that happened rather than you know okay you have to set this and then call me right yep can you say that template methods are one of the best patterns oh i love them yeah some people give a ton design patterns kind of a you know a hard time for you know whatever reason you know thinking they're like you know deficiency deficiencies in the model or whatever

but i feel like template methods is a particularly good example of a good way to enforce that the right things happen and prevent mistakes yeah so i don't i don't know yeah they're hooks so just to give a real quick synopsis of it right if you're in in the method like process order right you might have a before process order that it'll just call in the subclass and that method could do something. It could do nothing. It doesn't matter, right? But the template method is, Hey, you have to, you have to have this thing available. We're going to call it on whatever the subclass is. You do whatever you want in there, right? And then I'm going to do some work and then I'm going to call it. Okay. After order process would, could be another template method

pattern that it's going to call. And you can do whatever you want in your subclass, you could do nothing, you could do whatever you want, but you're guaranteed that order of operation. And then that way, you can just substitute in whatever functionality you need over time. So it's a substitution, right? Like really, if we're talking about the template method pattern, it's just a way to on your subclass, be able to call things that you can have do specific things you want. Yeah, I've got like a pipeline of events that are going to occur. And I'm giving you the opportunity to do some stuff at certain intervals. And those are

fixed. And I have control over when I allow those to happen. And so I can kind of, you know, protect my pipeline from bad things happening. And at the same time, make it clear to the caller what's available for change and when good times to do things are. Yep. Yeah, it'd be like, you know, going back to an old school kind of example might be the ASP page lifecycle. Oh, yeah. That's exactly what that was.

Yeah. And that thing was disgusting. So, yeah. I mean. I don't miss it. cycle oh yeah that's exactly what that was yeah and that thing was disgusting so so yeah i mean i don't miss it it's like application start uh session start request start all that sort of stuff yeah they were like maybe web frameworks have that stuff they were like these on pre-init pre-init init on init init complete on init complete. Like there was this, yeah, there are a whole bunch of different like places in that there were like hooks for you. There's like, Hey, if your class provides this method, we're going to call this method. Here's, you know, we're

basically, uh, there, there's these 20 methods that we're going to call and they're always going to be in this set prescribed order. And any of these methods you can provide your own implementation of it you can override it in your class and your version will get called and it's a beautiful pattern it really is uh you know where else it's used heavily that i'm sure that you like is in uh oh why can i not think of it post sharp what's that What's that called? Oh, aspects, aspects, right? That aspects do that a lot of times to where, because they're typically it's inverting things, right? Like if you're going to wrap an aspect around a method, you're going to want something to

fire before the method, after the method, whatever. That's basically what they're doing as well, is they're putting in hooks to say, Hey, if you want something to happen, when this thing enters, put in your method here. If you want something to happen after this method completes, put something here. Like template method pattern is used all over the place. Yeah. I mean, yeah. Specific to PostSharp.

I'm not sure if that one would count as template method pattern, but Aspectacular that we talked about absolutely used the template method pattern in order to establish its hooks. We need to check in with Vlad and see if he's pushed out the version 8.0 or anything. I haven't looked at it in a while. Yeah, I got like a million downloads. Right. What'd you say, Joe? I miss Vlad. I do too yeah all right cool yeah so take a little break here for a second to say please leave us a review if you haven't already uh we made two we made our second million a lot faster than the first and it was all thanks to you guys uh leaving those reviews and spreading the word we really appreciate it and so i want to take a second to say thank you and also if you haven't already uh beg you for it because it means I want to take a second to say thank you. And also, if you haven't already,

I beg you for it because it means the world to us. So if you've got a review that you would like to review, if you go to cuttingbox.net slash review, we'll have some links there that make it real easy for you. You don't need iTunes. You don't need, I mean, it's not going to be pleasant, no matter how you do it, but we'll make it a little bit easier for you

if you go to slash review and we'll give you a couple options there so you don't have to install iTunes. All right. And with that, it's time for my favorite portion of the show. Survey says. All right. So last episode episode we asked, having multiple monitors is great,

but are they a handicap, a hindrance, or a must-have? So, Joe, since you survived the hurricane, we will go with you first. Okay. Now, is this my opinion or what I think? This is what you think. Isn't that the same? Come on.

No. Nope. I think everyone is going to say a must-have, and I'm going to put it at 70%. 70% must-have. Yeah, but really quickly, I'll tell you why I think it's wrong. And I think it's because a lot of people use that second monitor basically for their email or their tickets or weather stuff i think in a perfect world you wouldn't have any requirements and you would just code code code i think it's solving the wrong problem so you're saying email is where your requirements are

code anarchy absolutely absolutely oh man email slack yep geez um so i'm also gonna say Code Anarchy. Absolutely. Oh, man. Email, Slack. Yep. Jeez. So I'm also going to say everybody said a must-have. But, man, I'm going with $1. All right. Because he didn't go over 70. There's no way it's over 70.

Trying to play the Price is Right strategy. Yes, I'm going to win this one. I like it, sir. I like it a lot. I'm going to win this one. I like it, sir. I like it a lot. I'm going to win this one. All right. All right. So both of you are going with having multiple monitors is great,

and it's a must-have. Alan says 1%. Joe says 70%. Joe, come on down. Really? Yep, 88%. down. Really? Yep. 88%. Wow.

It was by far the walk away choice. I mean, I expected it to be high. I don't think I... That's like the highest we've ever gotten on anything, I believe. I think that might be, yes. Yeah, that's like there were a few people that accidentally clicked the wrong button i think this is probably what i mean i actually did a double take it first because i only saw the first two results i'm like man it's so low we didn't guess we didn't really get a good turn and people didn't like this survey and then i was like

i had to scroll a little bit to see that and like oh there it is oh my gosh yeah so here's the proof you need if you're if your boss is refusing to buy you a monitor you can go you can actually get this uh little pie chart from the show notes print it out show it to your boss and uh get him to buy you another monitor i will say it is handy right like there's no question but i am curious because i've seen you bouncing all over the house and I'm sure that this is where it's coming to. So in episode 66, the question came up about like, hey, why have you stopped using your multiple monitors? Why am I seeing you only on the one monitor? And as a result, you're mobile because you're not tethered to that. And it's because honestly, the first, when I, when I read this question out loud in episode 66, when I read the answers, I should say, let me correct that.

Uh, when I read the answer choices, I kind of blurred handicap and hindrance together. But when I, when I wrote the show notes i i broke them apart because like well i guess it could technically be a difference because like the way um joe described how people might use that second monitor he was describing a distraction right like a hindrance right um but i kind of felt that it it definitely became it it it was feeling like a handicap and to have the monitors this is don't look at me like that no i'm curious don't judge this is where we're going yeah encourages multitasking uh and multitasking not so great well i mean humans aren't capable of that we can't we can only do one thing at a time right even computers can only do one

thing that's what you know that's just the way our stupid brains work my wife does like 10 things all the time well i mean she's special though um but yeah it was it was getting to the point where like it felt like if i didn't have that monitor and that keyboard, then it was like, well, this laptop is just a paperweight. I can't use it without this stuff. Where's, where's my, where's my other keyboard? Where's my other mouse? Where's the other monitor? And so basically this has been an exercise for myself to force myself to go going back to just keeping it simple just using what is on the laptop and nothing else and how far you know how much can you do right and it's kind of forced me to focus in on like well i can only see but like maybe two files or you know limited number of lines so i gotta like

kind of stay focused and on those areas and it kind of makes you break your code up a little bit more because now you're like well you can't have these long methods don't have space for that i need i need short methods that get the job done so yeah it's kind of forced you know it's been an it's been an interesting exercise let's put it that way you know what's funny about that is i thought when i saw you moving around the house that you just wanted out of your cave like no man like no there are times that i'll do that like oh seriously like even i love my office like you know we've both built our own desks we love them right like but there are times where i'm like i need a change of scenery right like i will unplug and go sit down on the

couch or I'll unplug and go to the kitchen table. Or I like, I will literally just unplug to get a different view. And that's what I thought you were doing. So like, when I asked you that question, you're like, I want to talk about it on the show. I was like, well, wait a second. He's just trying to get away from his desk. But it's interesting to find out that you're just trying to force yourself onto a smaller screen. No, it's forcing myself to be more productive. Do you think it did? That's what, well, I mean, I'm still trying this exercise.

But that's the state. Because where it was getting to be annoying is that if I had my laptop connected to, you know, all the peripherals, right? And then I'm like, oh, you know what? I want to go work, you know, I want to watch the news at the same time with the family. So I kind of like to be upstairs. But, I mean, what I'm working on right now, I could do both at the same time. I could, like I kind of like to be upstairs, but I mean what I'm working on right now, I could do both at the same time. I could like half listen and use and do this,

but then it would be like, well, I, I wouldn't like, I was so acclimated to using that screen or that keyboard or that mouse or whatever that it just felt so foreign to me that I'd be like, Oh, this is awful. I can't stand it. Like, why is it so what, why you, I can't read that. There's not enough real estate on this itty bitty little screen, right?

It would be things like that, which I know all sound totally stupid, but you know, when you go from one extreme to the next, that can happen. So it was like, well, let me take away the extreme, the peripheral extreme. The massive pixel extreme. And go the other direction with it and just kind of force myself to work in this environment and to force myself to be productive in this other environment. That's interesting. force myself to be productive in this other environment. Right. And then as a result of that, now I can be mobile again and treat this laptop like it, like a laptop.

I guess because I've always done that. Like, you know, if my wife's watching, I, I can't think of anything dancing with the stars or something. Right. I'll go plop down next to her and, and, you know, have my laptop there and be doing stuff so i've kind of never left that realm so i guess that's i could see where like if literally you're always looking at billions of pixels right like that it's it's hard to to walk away from that so that's interesting well now and here's one of the super specific apple parts to this though is that it's super um well i shouldn't say apple i should say windows um because windows is not thunderbolt friendly so if you you can't just plug and unplug a thunderbolt device from windows you can you have to hibernate not

an apple one that so that's what i found out when i was doing those reviews of the various different computers so this is interesting and i found this really annoying if it's a um certified like intel or microsoft certified i don't know what the certification is but if it is certified to work with Windows, yeah, you totally can. Hot plug it, unplug it, whatever. The Apple one, when you plug it into your Windows computer, it tells you it's not a supported Thunderbolt device

and it may not operate as expected. And that's why you have the problems. It's because... Well, that's where Apple's specific then. The Thunderbolt monitor itself does not... It's not necessarily fully compatible with the PC range of Thunderbolt. Oh, it's not just the Thunderbolt display.

Even if you use the, the Apple Thunderbolt, uh, to ethernet dongle, that doesn't work. Same problem. And so the workaround for that, that I found was that I would just hibernate the machine and then un-hibernate it, and it would be in whatever expected state that I wanted.

But that would be annoying because then reconnect to VPNs if you needed to connect to a VPN for any reason. Yeah, it was just a hassle. And that's the point. It's like those kind of hassles that were very specific to that hardware i felt were kind of like it was kind of anchoring me to the desk when i wanted to have a little bit more flexibility in my life right so yeah excellent well i definitely feel like when i'm on the laptop i do different types of things like whenever i feel like i have a lot of code

do or like you know i'm going to be creating files, I kind of gravitate more towards the keyboard and I want that sort of thing. And on my laptop, like I tend to do a lot more JavaScript type stuff because I don't want to open up the battleship of Visual Studio and have, you know, three or four panes open. And even now the debugging tools in Chrome, you know, if I want the big monitor, if I'm going to be doing some hardcore debugging because I want to have that information on the right and be able to see and interact on the left. So, uh, you know, I just think it kind of changes. I don't even want to really want to type a lot on a laptop,

you know, I don't want to write a novel. I like to have my big keyboard. You guys are snobs. It's totally, well, it does totally make me miss the days of the 17 inch, you know,

laptops like those aren't bigger screens. Yeah. Because kind of especially because the one big thing that i've found to be annoying is the chrome dev tools yeah like wanting to be able to see that um because if you wanted to have the main presentation window at a reasonable your normal kind of resolution and not something that's like super squished up and now like, you know, maybe your responsive design is kicked in or whatever.

Like, you know, I don't want any of that. I want to have it at a normal resolution and I don't want to have to like zoom out or tricks like that. That has been the most frustrating thing. Yeah, I mean, you get a lot better alt tabbing and command tabbing when you're on a laptop. That's for sure. Because I mean, that's really the only way to be effective like with chrome dev tools

like you said you can't have it over here because it's gonna screw up your screen so yeah yeah and this is where like that's that 27 inch was really nice for that yep all right so today's survey yeah today we want to know how many different podcasts you subscribe to and we were talking about this a little bit earlier. I don't know anybody that just subscribes to one, but hey, maybe you do. And apparently it's the right one. So we're going to have a couple options for you to select. Obviously, there can be only one, us, of course.

Also, let us know if you listen to less than 10, because YOLO. Wait, wait. YOLO. Yeah, wait, if you, uh, YOLO. Yeah. You only live once. You only live once. Dang it.

We were supposed to do yes, yes, no. Oh, this would have been a perfect opportunity. Oh, dang it. That's right. All right.

One of these days is, uh, let us know if you listen to less than 25, um, which means you're probably doing a bit of culling because you're on the edge um and you might have slipped into the abyss that is less than 50 or more which i'm calling a pro status here um and then uh less than 100 and uh i think you're on a first name basis with everybody at npr npr i think you know everybody at Gimlet Media as well.

Yeah, man. Gimlet. They're crushing it. So we'll be telling what we do next go around. We have to find some more to subscribe to. Yeah, we do want to do a quick Google feud before continuing. Yes. Yeah, what would it be without a Google feud?

So here's the way we're going to do this. Um, I have three surveys and we're going to see how many of them are needed to see who wins. I'm going to give you both the first, we're going to play this more traditional, like, you know,

family feud will be played. So you're going to get the question. Uh, I'm not going to be able to do like first to buzz in cause that's not going to play this more traditional like Family Feud would be played. So you're going to get the question. I'm not going to be able to do like first to buzz in because that's not going to work. But I will give you each a chance to answer. And whoever gets the highest answer gets to take the board. And then you get your two more chances. I'm only going to give you two more chances. And if you fail to get those, then the

other person gets the opportunity to win the board. So outlaw is Steve Harvey. Pretty much. Got it. And we're the buzzer beaters. Okay i'll let joe do the survey first so i will let alan go first google feud uh do hurricanes move so slow. Move slowly. All right. Joe? Happened in the summer. All right. Well, you get control of the board, Joe, because move slowly wasn't even on there.

Of course it wasn't. Happened in the summer was? Well, I'm going to give him credit for why do hurricanes happen. Oh, man. That's a stretch. It was a lot closer than move slowly. It was. All right.

All right, Joe. You get two more chances. Give me two more. Oh, geez. Why do hurricanes uh wobble i got nothing i can't imagine you can't even come up with one more i know everything about hurricanes it's impossible for me to question them okay well then i'm gonna give it to alan for his opportunity to steal and win

why do hurricanes I'm going to give it to Alan for his opportunity to steal and win. Why do hurricanes... I don't understand asking why in A Force of Nature. Like, what? Why do hurricanes... go inland? No, Joe wins. What were they?

Like, I have a hard time. Number one, Google choice here, or Google suggestion, why do hurricanes form? Which is very similar to happen. Why do hurricanes have names? Okay, that's a good one. Okay. And why do hurricanes spin? Okay. i feel like the answer to all those is just because they're jerks i mean they're like did you like that format of google feud or i like it

i like it yeah you want to do one more we'll do one more we'll do one more okay let's see uh let me get this into the board. Okay. You ready? Let's do it. Does Microsoft. My goodness. Joe goes first.

Why does Microsoft. No, Why does Microsoft... No, just does Microsoft. Does Microsoft. I'm terrible at this game. Does Microsoft... make money? That's a good one. Here comes your chance to take control of the board, Alan.

Does Microsoft make hardware? Man, I guess I didn't think about that option. If you both got it wrong, like who gets control of the board? Oh, I guess technically like regular family feud, you would automatically get control of the board because he got it wrong. Oh yeah. Oh yeah. Cause I would think the second person would get it. No, you would automatically get control of the board because he got it wrong. Oh, yeah. I would think the second person would get it. No, you can both get it wrong.

The first opportunity is an advantage to going first. The next person. Your turn again, Joe. Does Microsoft Sue Pirates? I don't know. uh you guys are gonna get sue pirates i don't know i have no idea i really have nothing on this one yeah i don't know that you guys are gonna get these these were like i was really surprised that google had these what do we got

all right so let's go back to the old format does microsoft number one suggestion own google really really on oh they get they they don't get any better from that okay does microsoft own skype okay my personal favorite, does Microsoft support Windows 7? And lastly, does Microsoft own Apple? Man, okay. Yeah, we would have never gotten those. Interesting. Yeah. Not what I expected. i expected so is i guess i was assuming that google was basing these suggestions off of like

things that other people had asked what people search and yeah and like the answers it already knew but then if that's the case are really that many people asking if Microsoft owns Google and Apple? That's crazy. I mean, whatever. Maybe it does exist. Who knows? Well, crazier things have happened, which is why we are now going to talk about the circle ellipse. The circle ellipse or square rectangle problem.

Man, this one is kind of long and I apologize, but like there was a lot to this. So this is interesting. This is basically, I've got notes here and some of them don't really even make sense. So, um, subtyping variable types on the basis of value subtypes. All right. Scratch that. I don't even know what that means. All right.

So it violates the Liskov substitution principle, which Joe mentioned just a little while ago, which is also part of solid. And that's basically when you're subtyping something is a, right? That's what it's supposed to be. So an apple is a fruit, right? Subtyping, fairly easy stuff. So if you take a, you know, a pretty simple example here, you have a fruit is the super type and a subtype could be an orange, right? The orange should be

able to be used anywhere that a fruit is used because it is a fruit. It has all the properties of fruit, right? So where's the problem? This is where the ellipse or the circle ellipse problem comes in. So depending on how you think of this, let's say that you said that the super type, so the base class is an ellipse, but here's the problem. An ellipse has the ability to stretch on the X axis and it can stretch on the, on the Y axis. has the ability to stretch on the x-axis and it can stretch on the on the y-axis so now if you try to make circle a subtype of ellipse so it inherits ellipse stretch x and stretch y don't apply to a circle because if you were to do one of those things it is no longer a circle right so

that is where this whole circle ellipse thing is. And this is an argument against OO in some, in some realms, because they're like, you know, subclassing doesn't always make sense. So what you might say then, okay, well then don't make the circle, the subclass of the ellipse. So let's flip it around. So now you have the super type of circle, but it has properties of radius and diameter. An ellipse doesn't have that. An ellipse doesn't have a radius because a radius is a fixed, you know, length from the center of the circle all the way around the thing, right?

So now you can't even make ellipse a subtype of the super type circle because it can't use radius and diameter. So those two properties have no meaning in the world of ellipse. So that's why this is called the circle ellipse. And same thing with square rectangle, you can use your imagination there and figure out why that won't work well. So this is where it gets kind of interesting is okay, well, what is a developer slash engineer slash programmer to do based off our previous survey? So one thing you can do is you can change the model. Now this has so many sub points to it that are kind of interesting and I don't really like a lot of them.

So I will probably open up a conversation on most of these. So one is you could return a Boolean indicating the success of the call. So for instance, let's say that you went with the ellipsis is your, is your subtype or your, um, your super type, your base type, and then the circle is your subtype. So you go to call stretch X on your lips, right? And it's going to return true. He said, yeah, I did it right. Now you go to call stretch X on your circle and it's going to return true said yeah i did it right now you go to call stretch x on your circle and you're going to return false and say no can't do it that's one way you could approach this now okay so it sounds like we're basically saying like this kind of modeling

problem exists you may run into it and you can can't, I mean, you can change the model. But realistically, it's looking more like the way to solve is to kind of hack around the interface and how you deal with these things. Similar. Yeah. So basically, what we're saying now is you might call set x, which is a doer, right? We've talked about this before, like CQRS and that kind of stuff. You know, typically, your getters are going to return something and your doers are usually void, right? Now we're saying, Hey, no, we're going to make the return type of this thing. Tell us whether you did it or not. Right. So that's one way. Don't love it. I mean, honestly, I really, I don't love that. Um, well, yeah, because as a developer, what do you even do with that information?

What do you, what do you mean do with that information all right what do you what do you mean you couldn't set it you weren't able to call stretch what do i do with that right right and honestly to me it sounds like you're gonna have a bunch of nasty logic now and whatever's using that because the whole purpose of being able to use swappable types and subtypes is you just pass in you know know, you pass in the interface and you say, Hey, you have type base, right? And you say, Hey, go call stretch X. Now you're going to have to have a bunch of logic says, Hey, if this was true, then do this. It was false and do this. You're going to have that garbage everywhere. Right? And so now you won't have clean, concise

code around it. So I don't love that. The next one is very similar. I don't love this one either. Throw an exception for an invalid on the subtype. So basically stretch X and stretch Y in your circle, you're going to have in there, throw invalid exception, right? Invalid, you know, I don't know. You might even create a special thing for it, but that's kind of, I like this one, but it's similar to the true and false. It's any different yeah but at least it informs the caller that they're doing something wrong and not thinking about a case this feels kind of similar to the base bean anti-pattern actually because you're describing yes you know not throw it's almost like you would throw a not implemented exception yes only now we're saying that the exception would be instead of not implemented like

a you know you can't do this exception yeah i'm not really valid operation right it's garbage i'm not yeah yeah exactly i like the way you phrase that i'm not really an ellipse right even though i say that i'm a type of ellipse i'm not right exactly yeah joe i don't like this one it happens okay i mean it's like so like the prime example I've seen throughout my career is like you've got some sort of products table and it's got different products in it and they've got quantities, they've got prices, they've got whatever. And now they're offering digital products and they don't have a quantity. And weird stuff happens when you try to decrement that quantity. You know, like you may put, you know, negative one in there. And so weird stuff happens or you put like a really big number in one day, you run out

and weird stuff happens. And so that kind of sucks. But another example is IPv4 versus IPv6 or actually probably all IP versions up to six where you could just take that whatever IP address and convert it to a number and then do math on stuff to see like, is this IP in that IP range? Then we have to IPv6 and the freaking things are bigger than numbers so i can't really do that anymore so i've got this whole history of like an ip address representing a number and now all of a sudden it's essentially a string because it's

you know it's just too stupid big well we're going to come back to this because i think there's there's answers to that um but i don't think this. Um, so the next one is return the resulting value after the method call. So instead of returning true or false, like what we said, Hey, I did it, or Hey, I didn't do it. Now, if you call set X or set or stretch X on the circle and you set it to 10 inside that method, you're going to set the X and the Y both to 10 for the circle, just to make sure it's in a consistent state. Because if you set one to 10 and not the other, then now you don't have a circle anymore. You have an ellipse. So you're going to do that. And then you're going to return 10 back out of the method, right? Or let's say that you're not going to allow them to actually

do anything in the method. You're going to call this stretch X 10, but it was previously, you know, the, the diameter of the circle was five. You're just going to return this stretch X 10, but it was previously, you know, the, the diameter of the circle was five. You're just going to return five and be like, no, we didn't do it. Here's the value that it currently is. So again, I don't like this. It doesn't, it does not convey the intent and what's really happening, right? It's, it's not telling the user that, Hey hey i'm not on ellipse i can't really do this this is just kind of masking the problem still in my opinion thoughts you look deep in it over there yeah i'm not crazy about any of these set methods that return back something that's fake because in that last example,

depending on, maybe not in that example where you're just returning back a simple value type, but if it was something more complex, you might be tempted to think that you could chain calls on it, but that might not necessarily be the case there, right? Yeah, because multiple of those methods might not be implemented. It's weird to see a chain of calls with a set in the middle that then does future, I don't know.

Yeah, it's like jQuery in your typed objects. Yeah, I'm not crazy about this scenario. So actually, I think I mixed up this next one with the previous one a little bit, but allow a weaker contract. stretch x and stretch y would both change both properties on the circle to keep it in you know a consistent state that's the one I was thinking of that one's that one's you know a little bit closer I could almost get behind that one so far out of all these that one's the closest to what I

wouldn't, you know, go, no, I'm not doing that. Uh, the other is to modify the subtype to the supertype on the change. So this is interesting. Basically what you're saying is if you call stretch X on a circle, now you're going to say, this is no longer a circle, create a new ellipse object and give that thing back. Right? So this is more along the lines of, uh, and I don't know why I can't think of it right now. Um, not object oriented inheritance. It's when you do, when you build things up, why can I not think of this right now? There's a term for it. It's popular. It's when you build things up, that's not object.

So, so not inheriting methods or whatever composition, composition over inheritance. So this is more along the lines of that, right? Like you have this immutable thing that you go and call this method. It's going to return you a new object. And in this case,

it's not going to give you back a circle because it's no longer a circle. It's going to give you an ellipse. So that's that one. I you back a circle because it's no longer a circle it's going to give you an ellipse so that's that one i don't like it because it changes it changes the underlying type which i think is dangerous yeah yeah i'll say like you don't just return a circle again you return like an eye shape or a you know eye round thing or something right right um so here's another one. This is also, this is the make everything immutable, right? So that you can't make any state changes to it. You're constantly replacing things that, that feels wrong to me as well. Um, that's taken the previous one to the next step. This other one, I really don't like factor out all the modifiers so basically any of your stretch x's and

all that put that into a different class and then you'll use that class to operate on all the objects can't stay on that one like i don't even really want to go too far into it but wait a minute these are like anti-patterns that are building on top of themselves it's ridiculous domain model yeah it's kind of what you're doing here yeah so now you'd build a mutable ellipse class, right? And then you'd be able to pass it. I hate that. Like, I don't even really want to talk about it. Um, put preconditions on modifiers. So this one's interesting. And I feel like if you're going down this path, it's time to rethink your classes. But in this, what they're saying is, Hey, so maybe on the base class, you have this is stretchable

property, right? Or this is stretchable value that you can pull from. And then when you call stretch X, you can say, Hey, is this class stretchable? And if it's not, then you just say, no, you can't do it. Right. And, and you exit out. But I feel like that's cheating at that point. Now you don't, now you're kind of saying, Hey, I know there's things that are going to subtype me that aren't really of my type. And so I'm going to give you an out. So don't love that one. But I mean, it's a little bit cleaner than the others. Factor out common functionality into an abstract class.

So basically what they said here, and they had the example up there is you would have an abstract class of circle or ellipse. So now you don't have inheritance. You're just putting all the functionality in that main class that I mean, okay, maybe drop inheritance relationships. So this is more along the lines of what I think I would probably lean to if I were going this route, which I don't think I would. But so what they're saying is you factor out interfaces now that each class would independently implement. So your top, you know, if you had something like get area, that would be, you know, I round shape or something like that, right? And it would have a good area. And then both of your your classes would implement that. But then anything that was

like stretchable, you might have an I round stretchable or something, only your ellipsis class would implement that thing. And then your circle one would obviously have its own. So it's really just factoring out interfaces that only work at those levels. I think I like that a lot. Cause what do you need inheritance for? Like, unless there's an API that forces it, I think it's an artificial construct is there's no real true modeling requirement for inheriting something. Is there? No, there's not. And I mean, everything that you taught in school class, whatever it's to put, it's to put these things into human concepts, right? That's really what it's there for. It's the only reason object-oriented exists is so that you can wrap your mind around a way to share functionality, right?

More interfaces. That's basically what this is. So that was that. Then they said just merge the circle class into the ellipse class, which I thought was funny. So basically get rid of the circle unless you just need a circle for some reason. So that's interesting. Um, and this inverse inheritance one that they put on there, like, I don't totally understand how this would work, but basically what they're talking about is any mutators that exist on the subclasses get pushed up to the superclass.

I'd imagine you'd have to have some sort of mechanism to be able to do that or a language that supports it. Oh, you're missing a solution. It's the just do whatever and create a ticket for the backlog. That's real life stuff right there for you oh man so then there's this whole thing of just use a different language or a feature of the language that you're in oh good idea no man this one yeah this one makes me sick a little bit so they showed some lisp examples where you literally can change the type. This, this is craziness. So let's say that you had this circle, right? Or an ellipse or whatever.

And you just say, Hey, this is no longer an ellipse. It's a, it's a circle. Now you can literally swap out the type on it and it'll keep all its identity values and everything, but you can swap the type. Like that seems like a bad idea to me. It seems like that opens up a world of crazy. What kind of nightmare problem must you have in order to consider moving to Lisp as a solution? I don't think you understand

the math behind ellipse and circles though. I think we just lost three listeners. Maybe more just for that comment. So, yeah, man, that one's crazy to me. Like, if you're swapping out types on the fly, I feel like that's another recipe for problems. Yeah, the only reason that's not an anti-pattern is because not enough people have done it. Yeah, I mean, seriously.

It's just craziness all right and so then this is where i think some of this this is where it really comes to a head it's just use a different paradigm challenge the problem right so and i think this is the most legit one all the way around is so they had an analogy that I really liked. It was kind of cool. So you have a person as a base class, right? And that person has methods, walk North, walk South, walk East, walk West. Then you have prisoner that inherits from person. Well, a prisoner is a person, but they don't have the freedoms of a person. So they can't walk North. they can't walk east, they can't walk west, they can't walk south, right? So this is an interesting one because now you need to rethink it. Do I need to have a free person? Do I need to have, you know, you need to think about the problem, what you're trying to

solve now. And now maybe you don't inherit from person, you inherit from free or from, you know, trapped person or something. Who knows? But it's you start thinking about the problem differently. And then I like what they did here. Also, in the Wikipedia article is they went back to the circle and the ellipse and they said, OK, now approach it from a different angle. Instead of thinking just in terms of circle and ellipse, what about a one diameter shape? What about a two diameter shape, right? Now you think about it in a more abstract term. So if that's what you're really going for, and that's what you need, go down that path, right? But I think the key here, at least for me, and I'm curious what you

guys think, my takeaway is'm curious what you guys think. My takeaway is think about what you're trying to solve, right? If you're trying to, to cram that circle into that ellipse hole or vice versa, then maybe you're doing it wrong and maybe you need to rethink the problem. Right. And that's kind of my takeaway on this. If you're, if you're hacking your way around it, then you're probably doing a bad job at it i feel like this just doesn't come up that often for me like it you know it's rare and so i feel like you can get away with doing that doing something like throwing exception because most models or most domains i've seen like this is just not coming up that often and if so my

my default is definitely to change the model and just kind of architect it differently and that's kind of what we're what we're saying with like the one diameter shape and two diameter shape what we're saying is just don't have inheritance you know just live without it just solve it another way i i think that's just what we do yeah i mean it when you do that you end up having more code copying or code, you know, borrowed. Yeah. Borrowed code because you can't reuse it. Right. Like that's the important part of OO and inheritance, right? Is you don't have to rewrite the same stuff, but if you were trying to go for perfect inheritance and it's getting in the way of a clean design, then I think you have to re rethink it and just bite the bullet

and do it right. Like do it properly in a way that's going to be more maintainable as opposed to all these hacky workarounds, which is going to really muddy up your code base. Yeah, just copy, paste, and tweak. Yeah. And that's definitely the easiest solution. But I mean, ideally, I think in most cases, you would change the model.

Otherwise, I think anything else introduces debt. Yeah, a lot of it potentially right here's my thought though on on this anti-pattern i absolutely 1 000 billion percent hate the name the circle ellipse or ellipse circle or no what was it it was like circle ellipse or the square rectangle problem because you worded it great earlier. And I forget exactly how you said it, but you said something like where, uh, this thing is not one of those, but I'm saying that it is because it inherits from this thing. Right. But if you go to Wikipedia and you look for rectangle, for example, it says a rectangle with four sides of equal length is a square, say that there's a special kind of a circle can be defined as a

special kind of ellipse with two foci that are, uh, equal. Yeah. So it's like, give me a better name for this thing, man, because that's awful.

These things are that, that is one is the other. It's, it's frustrating. And, and again, this is why some people are against object oriented because problems like this come up they're like well you can't solve it well that doesn't i mean come on like we make concessions in code all the time we compromise on all sorts

of stuff we there's no there's so many situations where there's just not a clean answer and we deal with them all day this isn't a showstopper, you know? That's the key. What you just said is you deal with the edge cases, right? That is always, if you get hung up on designing your thing and saying, we got to scrap the entire project because we can't make this inherit from this, then you're going to fail at anything you try, right? You're going to fail in another language. You're going to fail. I just want to point out that we have

mentioned on this show many times how the hardest thing that we do is to name anything and that has migrated to wikipedia where they have trouble naming the anti-patterns that's all i'm trying to get at yep i mean you can commit a bug people do it all the time they commit known bugs because fixing it is worse than just dealing with it oh yeah totally i mean we've all you know what's funny is i don't remember what the code is now but i know each one of us personally had looked at a piece of code one time and thought it was so bad and we're like nope i'm fixing this i'm fixing this and then you get to like a day and a half in it you're you're like, I'm tucking my tail. I'm running.

Nobody will ever know that I did this. Right? Like you literally back out because you're like, yeah, you can't fix it. Yeah. And there's situations where you see them like this problem happens in.001% of cases. And the consequences just aren't that bad. Right. And it's going to take me three weeks to fix.

And it's going to make everyone angry because the diffs are going to be just insane nobody will know what right take it and you put it in the backlog yep totally totally all right it's your turn joe all right uh i want to talk about circular dependencies a lot of shapes going on tonight and uh circular dependencies are basically unnecessarily direct or indirect mutual dependencies between objects or software modules dll example dll is the kind of prime example that i think of when i think about this sort of thing where you can't upgrade a because it depends on b which depends on c which depends on a or you've got things depending on two different versions of you know b or c or whatever and, and things just get a little wonky.

I guess the version thing doesn't really apply here. That's more of a DLL thing. I'm going off the rails with my examples again. But, yeah, I mean, just the idea of circular dependency. And that's actually something I got really caught up with when I was playing around with Unity because I was using Independent Static Analysis tool to kind of look at my stuff. And I kept seeing that there were namespaces that were dependent on each other.

And those were signs where I had basically a bad flow of logic, like things were reaching into and grabbing stuff out of wrong places. Things were going up the hierarchy chain instead of down the hierarchy chain. And there was indicative of all sorts of problems with my model. And it just kind of manifested that way. And that was an easy thing for the tool to detect. And so it's an anti-pattern. So how can you tell when you're in there?

I think it's kind of hard to know when you're in it. It's so easy sometimes to just kind of reach out and grab something when you need it need it for others from database or from some other class or something and it's almost just kind of the way we work and we don't really think about um you know what that means in term of terms of like our object hierarchy being a nice clean tree but i do think if you're unit testing then you are particularly protected against this problem because it's really difficult to deal with dependencies and unit tests. So you end up not having as many and you end up passing things a lot or injecting things in rather than going out and fetching it whenever you need it. So I do feel like when people say unit testing encourages clean code, there are a lot of times they're talking about dependencies

and particularly circular dependencies. It can sometimes cause memory leak problems because the garbage collector can't clean up something. So you've got a reference to an object and a reference to an object. Sometimes we'll see this in JavaScript. You'll have things referencing things up and down the tree and then you try to serialize them to JSON and you just can't. You get an infinite loop, basically. Like JavaScript, you'll have things referencing things up and down the tree,

and then you try to serialize them to JSON, and you just can't. You get an infinite loop, basically, and take the browser out. And that sort of thing also happens with the garbage, the GC. What does the C stand for? Collector. Didn't I just say it? You did. Oh, man.

It must be past 10. Yep. Past 10. Going downhill. So, yeah. Often indicative of flow or hierarchy problems where information would be perfectly flow in one direction. In a perfect world, we have these nice little trees of code where we have one entry point. You got your main method, whatever, and everything kind of spiders out from there.

And it's a nice binary tree with a perfect number of branches or whatever. But that ain't happening in most cases. I did read that this practice is actually somewhat common and encouraged in functional programming. That's it. I'm never touching it. I'm never going to look at it. So I'm trying to kind of rationalize this a little bit i you know i don't know i didn't deep dive it i you know this is just me kind of guessing but i kind of think about functional programming being really similar to

math and like you can't really have the concept of a number without the concept of addition right because two is just two ones right and i i can't really add stuff without having numbers. So you've just got this kind of chicken and egg problem where, you know, that's a super, super basic example, but, uh, where the, these things just kind of need to be discovered or put together or abstracted together in order to kind of build something bigger. And, uh, it was a cat's cradle or whatever they call it when things kind of, uh, lean on each other in such a way, you have to kind of construct them carefully and then remove the

scaffolding no you don't know no i don't know someone in the comments let let us know what the heck i'm talking about because i would like to know well speaking of though as far as like you're getting additional information because going along the lines of the circle, circular dependency and DLL hell, we've talked about this in the past. And I remember I put out like a, you know, a request to, to the audience. Like if, if you have, if you know of any good books on like dealing with, um, packaging and Dll and trying to avoid dll hell or you know how to resolve those kind of situations like that would still be very much appreciated yep yeah i wish i i wish i could find this sort of thing um the the geometric shapes i'm talking about i know they have a name where there's basically they're almost like impossible shapes that you shouldn't be able to kind of create but if you do things like kind of like a mobius strip where you can kind of draw something in 3d space that like shouldn't really theoretically be possible where there's like an escher drawing where the

stairs are infinite uh that would be that would be similar except those that's kind of like a trick but i feel like in geometry there's like real patterns that are just kind of goofy. So somebody read Gödel, Escher, Bach, or whatever and let me know what you find. I'd love to see that in the notes. And so what do you do about it? Basically, I think static analysis tools and testing are your best methods of kind of fighting this. And just beware if you're reaching out or using singleton and stuff like that. We have patterns like IOC or observers that are really good at cutting those

dependency lines and preventing this sort of thing, which is kind of funny when you think about it, because those dependencies are still there kind of at runtime, but they don't offer the same sort of downsides that they do when we're dealing with compile and design time that's interesting it makes me really want to dig into the onion pattern the the design patterns because it's really cool seeing how that differs from you know like i i forget what independent calls their view where it shows all the lines going out to all the dependencies. But when you see the onion pattern,

it's literally just everything pointing inward, which is really cool because it breaks that stuff down. But yeah. So I'm looking at Mobius strips now online. All right, well let's get into the last one for the evening. And this is constant interface. So this is the quick summary definition for this would be using interfaces to define constants. Now, as best I can tell, this is only a Java thing, right?

Because I know Alan's shaking his head because you're thinking C sharp and you're like, you can't do that in C sharp. And you're right. You can't have a field in C sharp. And it wasn't up until C sharp six that you could even have assign a value on an auto property, which you also can't do in a interface. So this is a Java thing only as best I can tell. So a lot of what I'm going to be talking about is going to be coming from a Java kind of world. So why might you be tempted to do this? So again, you want to define a constance, you want to have it out there, and you're going to put it in this interface. So why, why might you put it in an interface? So maybe I, you know, and some of these are gonna be questions of like, I don't know, maybe you're thinking of composition over inheritance and you're like, Oh, Hey, you know what? Uh, I need all these constants out there

and, uh, you know, for different purposes. And maybe I just want to allow you, the developer that who's using my awesome library to be able to, you know, match these things up however you need. Maybe that's your reason. You know, and you're putting it in the interface because you can only inherit from one class, but you can implement from multiple interfaces. Maybe that's your reason. And I'm not entirely sold on that, but yeah, it's just maybe.

And, you know, but ultimately you're, what you're trying to get at is a convenient way to share some constant value across your app or your namespace, right? So that's the root problem that you're trying to get at. So why is this particular implementation of this bad? So if you think about a constant, a constant is an implementation detail of your class, right? You're like, your class needs to have something, it needs to know something, there's something that's never going to change. But you don't need that implementation detail to be publicly available, right? That's more often than not that constant. Nobody needs to know it, you know? Um, now, so yeah. So think about all the uses of your class and all the subclasses of your class, right?

That might now be exposing this constant for no reason, right? The users, they don't care about that constant. Some implementation details is specific to your class. Why do they care, right? It should, you know, if we were to think about it in that regard it would probably mean it should be private right yeah yeah so but now you've made it part of an interface which means that it's part of a contract we've referred to interfaces as con contracts but this is for an interface i mean for a for a. So that value is not supposed to ever change, right? However, in your Java class, you could implement that interface, right?

And then create your own constant of the same name, but with a different value, essentially changing whatever the other value was or hiding the other one. So making it pointless, right? And you as the developer, you could do that unknowingly, right? There might be a constants plural interface that just has a whole bunch of things to find out right and you don't even realize that you named something the same and now it's gonna be super hard to look at that and be which which one is that right now some of this conversation assumes that you're actually implementing the interface you don't have to implement it in Java, right?

You could just use it. You could just use it. So you could just plain and simple, let's just say I very plain and simply have an interface that might look like a public interface foobar, right? With int i equal five, right? So in that very simple interface, I don't have to implement it to use i. I could just say foobar.i and I get the value. So basically

what I'm describing is you wrote it as an interface, but you're kind of treating it and using it more like an enum. Or a static class, right? Well, okay, hold on. But good thinking, though. I like the way you're thinking. So now think about this. Now think about this, though. What if you had a reference to that interface?

Like, that kind of becomes pointless now, right? If you had a reference of a type of that interface, why do you even really need it to get to that constant? Because you could get to the constant value without even having an instance of it. So that makes it super kind of weird to think about. So going along with what your thoughts were like, okay, so we realize we're in this bad situation and that this is bad. I think we can safely agree that this is bad.

There's a lot of conversation out there about how this is an awful thing to do. So what are your alternatives, right? So one of the things that I was thinking of is that, you know, going back to what I said before about this is implementation detail, it probably doesn't even need to be publicly made available. You could just get away with keeping this thing private to your class. And when you do find that you need to make it available for other purposes, that's when you might do something else with it, right? So when you do find that you need to have these constant values available across your app or your namespace, then use an enum.

I mean, you're already, you know, the alternative, you were already suggesting using this interface as an enum. So why not just really just use an enum, right? And if you don't want to use an enum for whatever the purpose, whatever the reason, then as you suggested, Alan, this is where you could have a class with static, public static variables instead. Yeah, I can't, I can't think of a reason why you would do this because it's like you said, with the the contract with the with the interface the whole purpose of the interface is to expose public functionality right public well java's different

though yeah yeah now here's the difference though with that public static portion though is that uh you know if it's read only which would be like a C-sharp thing, right? Because then you could have a public static read-only variable, and it would kind of act like this. Yeah. Huh. Yeah, I don't... It's weird, though.

I know that it's different. Java's different than C-sharp, but the purpose of interfaces in Java is the same, right? Like, the intent behind it is the same is to give you, it's shaping things, right? It's polymorphism. That's the whole purpose of it. So yeah, this seems like an odd, like almost like a slip on their part when they made the language available to do this. I mean, this is where they totally diverge, though. Because you're totally coming at this expectation of an interface from a C-sharp.NET world.

And in Java, you can have methods in the interface. That do things? Yes, that do things. Okay, yeah, I'm totally... Apparently, I never read that far in the java book well i mean it's a relatively new thing um it was eight yeah hold on that's the purpose of like an abstract class or even a base class or whatever you want to call it right like i mean i well they have the notion of like instance variables like our instance variables and member variables and

member variables is like yours instance kind of is shared between the instances so i kind of see it as an extension of that and that kind of line of thinking um which you know i'm okay with or you know like a static variable is the same kind of deal but not in your interface but not in your interface right i mean i see i can understand kind of coming at it from that angle and kind of seeing you know like leading up to that but uh you know i mean i think it's absurd right okay it definitely seems off with my kind of way of thinking about it so i can't imagine what i would gain from doing this right and i think that's the key right like the fact that you can override it and accidentally hide it is it seems like another dangerous thing it's kind of weird to call it an antipod no like

are there like legions of programmers like you know doing this stuff inside and out like you know 9 a.m to 5 they're they're throwing in its constants into interfaces yeah I'm curious I just searched for it the first thing that came up was a stack overflow from 2008 apparently it's not all that talked about yeah but anyways cool yeah i mean it going back to this though it is kind i think that back in episode one, though, I is for interface. I think Joe did this whole thing about like, what if, right? And what if interfaces could do something? And I kind of think that some of the things that he might have said then

apply to interfaces in Java now. Ooh, can I put them on third parties? Because I think that was my biggest thing I wanted to do. Oh, maybe that was it. Okay, never mind then. Forget everything I just said. Dang it. Is that the rewind?

Yeah, it was rewind. I'm sorry. I should have made that more clear first. No, because I thought one of the things that he wanted was to be able to provide a method that had a default functionality to it. I don't know about that. I thought that was one of the things that he wanted was to be able to provide a method that had like a default functionality to it. I don't know about that. How do you remember that? I wrote an article called what if interfaces?

Oh, maybe that's what I think there were three things. Maybe it wasn't in episode eight. Maybe it was in the article. It was both. I think maybe it was in both. Now that he says it, we're getting somewhere.

Let's see. I'm actually looking this up. Yeah, so it does kind of feel like that the definition of interface kind of got bastardized between, like, you know, from a Java world and what's in a.NET world, right? Yeah. In a.NET world, it's purely just like, here's the contract, here's the expectation. You're going to have this field. I don't care how you get it.

And you're going to provide it to me. You're going to have this method. And I don't care what you got to do inside of it. But yeah. Yeah, it's very much, this is what you're allowed to call, right? Okay, I mean, I still feel very strongly about my three what-ifs. I totally agree with me.

It's not common. So why don't interfaces support constructors? I don't know. Okay. It's funny. it would be nice like I should be able to say like my module or you know

if you're gonna adhere to my contract I need to be able to create you guys in a consistent way across different types of objects yeah

I like it what if interfaces supported static classes it'd be kind of nice to have a static class that implemented an interface right What if interfaces supported static classes? It'd be kind of nice to have a static class that implemented an interface, right? Like who cares if it's static or not, as long as it meets my interface. I don't need to know the details.

I can halfway agree with that, yeah. Yeah, I'm there. And then finally, what if interfaces supported, oh, I don't even have the third one here. What if interfaces supported anonymous classes? And I think we might have gotten there eventually. But the idea was that I'd be able to take an anonymous class and say, hey, it is this interface now. Shove it over there.

Oh, is it of this type or make it this type or whatever? Yeah. Why do I got to create a file just to, you know, do two little things? I can create these dynamic objects. Like, why can't I just i just say like hey here's my dynamic object and this is this interface just trust me well there's no way to cast it or anything like that in c sharp yeah because where that would be really nice is on uh return yeah where you don't want to have to create some stupid little DTO. Yeah, you just say return this as this.

Right. Yeah, and I don't have a what if for the thing that I want the most, although I know we talked about it back in episode one, which is why can't I assign my interface to a third-party class? I take the HTTP session and say, hey, this is an I session, and now I can deal with it generically so i can mock stuff out in my libraries so that i can do testing you know for for my classes and mock out objects for things like http sessions or whatever for objects from in the framework that i don't want to have to deal with in my unit tests that would be cool if you could basically take something from an external and say cast it as this? Like that would be pretty cool.

But I'd imagine there'd be all kinds of problems that run into that. Oh, you know what? This article was written just a few days ago in 2013. Came out September 9th. Man. I'm still fired up. Four years ago. Four years.

Wow. We're kind of like the old kids on the block now. It's awesome. Two million downloads ago. If it helps you, I know the author, so I could maybe get you an autograph. Yeah. Just saying. Awesome.

I can see he's also using some copyrighted images. No idea what you're talking about. Yeah, I didn't hear that. Oh, man. so moving right along yep uh we will have a link to this article wikipedia article in the resources we like linking to these fantastic object-oriented anti-patterns and with that let's get into Alan's favorite portion of the show. It's the tip of the week. Yeah, baby. All right. So I'm going to go first and this one is going to be kind of different, kind of obscure,

but if you ever find yourself in a situation where you need to create large files, because, you know, sometimes you just need a large file. I'm going to include a link to the, to a great Slack stack overflow answer. And the reason why I like this one is because it includes Linux, Windows, Mac OS, as well as just any kind of cross-platform Unix derivative. But specifically at the time, what I was looking for was the Mac OS version for, I'm going to pronounce it Makefile, but it's MKF file. And so what you could do is you could say MK file, uh, space minus in space, and then the size of what you want. So let's say you want a 10 gig file. Uh, you, so you'd have MK file minus in, uh, 10 G and then the file name, and it would go and create this giant file for you. There's, like I said, we'll include, the article includes, or the answer includes,

you know, fsutil for Windows and fallocate for Linux, and then the more traditional cross-platform Unix version of just using a DD command to do this. But this is really nice if you just need to create some stupid large file, whatever your reason might be. That's cool. Sounds like you were up to something fun slash fishy. No, why would you go to such a dark place?

The fishy? that was weird no specifically what i wanted it for was to test a uh a raid system so i wanted to just be able to create a bunch of large blob files i really didn't care about them but i just wanted some large files out there and then just get a checksum on them and then be able to do things to the array and verify that it was in a consistent state, be able to do a checksum again, you know, subsequent checksums on those files again to make sure like that they didn't change. And then like, you know, what happens if I just completely slam the array completely full, then what happens, right? Like those types of situations. So that's if I just completely slam the array completely full? Then what happens, right? Like those types of situations.

So that's why I just needed the ability to create like, hey, how much space is left? Okay, that's the number I need to create a file that big. That's cool. Pretty cool. Awesome. So mine, I don't think I've ever done this tip before. We've talked about encapsulation. We've talked about scoping of variables and all that kind of stuff.

And it's funny. So recently had some conversations about just JavaScript and how it, you know, doesn't play like everybody else. Right. And the whole thing of private variables in JavaScript came up and anybody that's worked in JavaScript knows that there's no real such thing as a private variable, but you can cheat it by creating closures. And it reminded me, I did a video probably about two years ago, that's up on YouTube on how to actually do a closure and how they work and what it means and all that. And the gist of it is typically inside a function, you'll var up some new variables. But if you want to keep those things private, they're already up some new variables. But if you want to keep those things

private, they're already private to that method. But if you don't want them to be exposed using JavaScript's prototypical thing, inside that, that function that's wrapping this other stuff, let's say that you have var first name, var last name, if you don't want to expose that, so somebody can't hit your object and say dot first name, dot last name, the next thing you might do is say var function get name or var get name equal function, create a new function. And inside that function, you'll return a reference to that local variable. So it's interesting if you're ever writing any kind of plugins or you're writing things in JavaScript and you want to make sure people can't screw up the state of whatever your

object or your plugin or whatever it is that you're writing, that's how you do it. And with Node.js, I would imagine this is fairly important because you don't want to expose the internals of what your modules are and stuff that you're creating in Node.js. So I thought that'd be pretty cool. And another way to learn about this kind of stuff that I think is really cool is TypeScript. If you are coming from a typed programming language background, TypeScript is very familiar. The syntax isn't one to one with C sharp or Java, but it's very familiar. So I was looking at TypeScript's website and they now have this TypeScript playground, which is kind of cool. So you can go up to typescriptlang.org and they have this, and we'll have a link in the show notes,

but they've got this playground and you could literally like in the dropdown on the top left, you can say, Hey, you give me your example using classes. And on the left, it'll show you the TypeScript that generates this class that you can use like in an OO way, similar to your C sharp or Java or any of those. And over on the right, it'll show you the translated JavaScript. And so you can actually see how closures get created. Like if you're going to create a private variable in TypeScript, how does it actually translate that down or transpilot to JavaScript? And what does it mean in the language? So I thought that'd be a cool little tool for,

for people to play with. I do want to make one correction. When you said the VAR and up the function, you'd actually want to this dot the whatever you want the function, right? Oh yeah. You would, you would want to this dot the function so that it would be available,

but you're going to return the VAR. that it would be available but you're on that object yes yes correct okay yes just in case if any listeners were like paying attention to that they're like wait a minute yeah yeah no that's that's totally correct uh very nice well i uh i am up now and i have two brand spanking new podcasts for you to check out both of them are in single digits brand spanking new so uh you guys should go listen and uh let them know what you think because they love reviews too hey by single digits you mean single digit episode numbers yes single digit episode numbers i think one's like seven ones at five today okay yep uh and they are say Say what? I wasn't sure. I thought I heard some squeaking. No, go ahead.

No. The first is Crush Code and those weekly dev tips. And Crush Code builds itself as the podcast for developers with short attention spans. So right up my alley, they've got some really fun talks. And the hosts are really energetic and positive, which is nice. We've got real estate episodes talking about machine learning and Neo4j. So if you're interested in either of those, then you should check it out. And the other is Steve Smith, who we mentioned quite a bit on our solid run of podcasts there back in the day. And so he's got some really short episodes, like six minutes.

They're weekly and they're really short episodes, like six minutes. They're weekly. And they're really concise and insightful or consiteful. The latest description of the most recent episode is to be wary of the new keyword in your code and recognize the decision you're making by using it. So if that kind of thinking or those kind of episodes sign up your alley, then you should check them out. Cool. All right. Well, as I mentioned, we have talked about the anti-patterns available to you in object-oriented programming.

So all your needs there can be met. You can find your latest anti-pattern that you want to use. And now you shouldn't, you probably shouldn't implement that. Well, even the base being no, no, not that one either.

All right. So with that, be sure to subscribe to us on iTunes, Stitcher and more using your favorite podcast app and be sure to leave us a review by heading to www.codingblocks.net slash review and while you're up there go ahead and check out our show notes examples discussions and more send your feedback questions and rants to the slack channel codingblocks.slack.com and make sure to follow us on twitter at codingblocks.net uh at codingcks, dang it. Or head over to codingblocks.net

where you'll find all our other social links at the top of the page. I got my second win, guys. Let's go. You're ready? Back to back episodes. Let's do it. The dream.

I don't know that he does have a second win. I don't think so. No, we're going down. We're going down.