Practical object-oriented programming and the challenges of Iza and Haza

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We are continuing our season where we're looking at practical object-oriented programming, taking that thing that has been around for a few decades now and just really just reassessing where we're at, talking about some of the core concepts and how to apply them in really just in any software, but we'll say modern software, particularly with the eye towards the frameworks, the libraries, all those things that are out there that get us part way there, but they don't do it all for us. We still need to consider things and properly design our systems. This episode, we're going to continue the Iza and Haza discussion. One of the things that I want to focus on, and I think this episode, hopefully I can knock it out in one episode, is the grammatical challenges of Iza and Haza. We have these things in our language, at least in English language, that they equate the Iza when it really doesn't. It blurs the lines, and this is where I think some of our design issues come into play. In the previous episode, or maybe it's one of the previous episodes, I talked about the Iza relationship in object oriented being one way. If A is B, B is not A. That's just the way it goes. There's always a hierarchy. It's not a linked list or something like that. If A is B and B is A, then they are essentially the same class. They are the same class. They're just different instances. That's just sort of the way it goes. Actually, I guess in that case, it would even be the same instance. Now, the challenge comes when you talk about Izas and Hazas in particularly with regard to relationships, when you confuse relationships to actual being, I guess. I brought this up actually in the podcast, as much as it was the post around it. I talked about the concept of a father has a son and a son has a father. That would be two ways, but that Haza is not the same as a car has a color. Because when you do the Haza between two instances, it's different. It's a relational. That even can be, I think, to some extent in the Iza form of it as well. You have these things that are more traits and properties that we have to deal with as far as both of these relationships. But also we have to distinguish the Haza as a relationship versus Haza. You have an attribute or a property. This becomes very not only critical, but can be confusing when we talk about designing out our object oriented system. We're going to dig into that here. In a relationship, father has a son, son has a father. In that situation, I guess there's a couple things to think about. That's why it's not an Iza. Because although you can have the father is a son and a son is a father, if you've got multiple levels of generations. But in the Iza, this is where we have things that are essentially multiple classes. We have multiple inheritance in a way. It changes things a little bit, I guess. I know I'm drifting a little bit around here. Let me start with the Iza first. Let's talk about that father is a son. Let's say if you've got a grandfather, a father, and a son. That one in the middle is a father to the son, but also is a son to the grandfather. In the Iza, they actually are both. If you think of a hierarchical relation tree, then that's okay. Because what you would have up at the base, essentially, I guess, would be a male. And then inheriting from male characteristics would be son. Because there's going to be certain things you have if you are a son. And then dropping down to that, you have a father, which inherits stuff from the son because they were a son before they were a father. And then you could go down to a grandfather. So while we may flip it in the grammatical sense, and we may get confused a little bit when we start placing instances within there, the father and the son are not at the same level, basically, with the same relationships. And so it works out. Just because a father is a son and a son is a father does not mean that those are two different classes. So it's not a two-way relationship. Or it's two different instances, I guess. And this is where it gets, because when you look at what determines them as such, it's a different set of properties. It actually does exist within a hierarchy. And that's only because at the bottom level, it is inherited from the upper level. So when you get to, it's basically like if you look at it within this one, if you start at that top level of male and then son and then father and then grandfather, when you're within that son and that father range, you have attributes of all of the above. And so you can't say is a, but it's because of a hierarchical relationship. Now, the has a is going to be different. And this is probably where we're we've moved over to these a little bit. The has a, I think the easiest way to think about it is you have something that is, it really is more a property of you versus having a relationship. While relationships are properties, it's actually from a programming point of view, works out pretty good because it's there's a difference between you have the data. You know, you there is an age that is your age versus a pointer to an age, which could technically be like you have a car. You don't have to actually have a car. You have a relationship to the car so that it is not. You are not one with the car, no matter how much fun your Sunday drive may be. You're not one with the car. It is not a part of you. It exists separate from you is probably the easiest way to think of it. Your age, the age that you are, other people can be it. But your age does not exist separately from you. You can't extract your age and just go give it to somebody else. You could extract your car and give it to somebody else. But you can't extract. You can actually even you think of family relationships and stuff like that. They can happens all the time. Unfortunately, they could extract your spouse. And then they exist separately from you, no matter how close you are. You are not the same. You're not within the same instance. So that's relationship. I would be more of a maybe like a uses or more in the technical term is a coupling kind of thing is that these separate entities work together. Have a relationship with them. And this is where I think a lot of people come sort of struggle in the object-oriented world is figuring out is it a relationship or is it an attribute really to be, you know, to simplify it down. And it goes back to what I just said. That your key in this is the thing that you're referring to able to stand on itself, stand by itself, that property, that attribute, can it stand on its own? If it can, then it would be something that is there's a relationship there, not an actual property. And you'll run into this even in the database world. Funny enough, relational databases in particular, it's all about relationships. So there's a difference between having a another table that data lives in so that you have some sort of a foreign key relationship to it versus it being a column within a table. Classes work the same way. There's a difference between it being an attribute of the class that would be essentially the column of the table versus necessarily a different being off in another table. Now, the table relationships is a little different. So it's not, which is again where we run into problems when we do object-relational mappers. It's not the exact same. So relational tables and how you would model data within a relational database in particular is not necessarily the same as you would do it as instances, basically a class and then instances of the class. Because while other people can have the same value of the attribute that you have, it is not the same. Yours is unique to you. So my age, while other people can be my age, even down to the same second, they do not have my age. It's just a reference in a sense in the relational world to say this is the same value. But being the same value does not mean that it is some sort of relation and that it's not an attribute. So attributes, the easier way to think about them, can it stand on its own? Can I take that attribute and take it and what it is, that instance of that attribute and give it to something else, give it away to another object? Color. Can I take my color and give it to something else, whatever my object is? Now, in some cases, there may be some sort of a, you need that kind of a relationship because you are doing, or you may fall into it because you're doing things like a graphical panel and the children inherit the color of the parent. But it's still that color, even though it's shared, even though it rubs off on something else, on the other controls, the color is still an attribute of the primary, of each control. Now, they can be influenced by it, but it's still their own. Just think about, I mean, just getting a little metaphysical here or whatever. Just think about your beliefs, whatever they are. What you believe is what you believe. Now, it is impacted and biased by those around you and your experiences and all that kinds of stuff, but it's still yours. You cannot actually give it to another person. So that would be an attribute. Color is the same way in a lot of, you know, with most objects, I would think, is that it exists only with that instance. Well, you can, you can affect other things. You can't actually give it away. Hopefully that helps in the hasa and some of the design challenges that you run into. The bottom line is thinking about a specific instance. And are these things that you basically hang on the instance, their relationships, or that you can attach to it? Those are relationships versus the things that are intrinsically what make that class, that class. And we will continue to dig into this as we go further into some of these, some of these design challenges and options. But for now, we're going to wrap this one up. Challenge of the Week. Take a look at a couple of the classes you've been working with or that you're working on and just give it a sort of quick review on the isa hasa kind of stuff and see if there's maybe some, some things that you have as properties and attributes that really are relationships and vice versa. And that being said, I'll let you get out there and get to it. So go out and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Nord podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernord.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Nord. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Nord site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week, and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernord.com if you would like more information. Now go out there and have yourself a great one.