ISA and HASA in Object-Oriented Programming

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. Today, we're going to look at ISA and HASA, as in I-S-A or H-A-S-A. This is a concept that is pretty important as you get into object-oriented programming, and although it's not necessarily a key property of something being object-oriented, it is definitely a concept that is worth discussing as we're going over how to practically apply this, these theoretical concepts. ISA and HASA are two different ways to view relationships of an object, essentially a class, and a function. It comes down to really asking a question, which would be, for this thing, is it a whatever that is, or does it have one of the whatever that is? For example, if you think of a car, a car has a tire, or actually multiple of those. It has a steering wheel. But then if you think of types of cars, so a Ford is a car. It doesn't have a car. It is a car. Now, some of these are very obvious. For example, what I've shown, a lot of people-related stuff. You'll have things where you maybe have a person, but maybe they, you can say they is a, that's not very good grammar, but they is a employee, or they are a customer. So you know that a customer is a person. You know that an employee is a person. Now, it is important to realize that this is a one-way relationship in most cases. If there's not, there's a little bit different there, and you're not going to have a hierarchical type. Or, I guess you could, you won't have a hierarchical relationship for sure, which is the is. And you may have essentially a many-to-many kind of relationship, some sort of pointer from one to another. So one thing may have a bunch of something, and the other corresponding object or class may have a collection of that other thing. But let's talk about the is first. So it's important to remember the one-wayness of it. So, and this, again, it's sometimes very obvious, but sometimes gets rather nebulous. With the person thing, we know that an employee is a person, which means the employee would inherit from the person. A person, if we said a person is an employee, that doesn't necessarily, it doesn't hold for all cases. But maybe in our specific situation, which would mean that if it is a one-to-one both ways, if a person is an employee, an employee is a person in our system in all cases, then there should not be two classes. There should be one. So there would be, I guess, an employee class. Or you could call it a person class, but the person is an employee, employee is a person. That means that's one class. Makes sense, right? If there's no sense for you to have two classes if they both are equal, they are the same thing. Now this, again, can be problematic, as they say, in some cases. But when you think about it, this is key for us to build our classes at the right level. What you don't want and what this kind of a design discussion or consideration will bring us is not having a hierarchy where you have, for example, Class A and then beneath it you have Class B and the right beneath it you have Class C. And then you get the D, E, and F that all come off of C. Now you may have that sometimes. You may have these essentially placeholder pieces of the hierarchy because you know you want to inherit from there somewhere down the line. For example, in your system today, you may know that a person and employee are the same thing. However, you know that at some point you're going to have, let's say, a customer that inherits from person. Now the challenge with those is that means that when you say someday, if you haven't designed the customer, if you don't know what that customer is, then you don't know. So at that point you would have person, customer, and employee. If you don't know what the customer is, you don't know what belongs in the person and what belongs in the employee. So there should technically not be a thin kind of hierarchy. It should tree out. You should have at least two subs under two children, I guess, in a hierarchy under each node. If you don't, then you're probably missing something. You probably could have some placeholders and some hooks there, but most likely you probably should have confined that classes at some point. Or you should have spent some more time at least stubbing out what would a child look like to make sure that you've covered the right properties. Now early in a design or early in an implementation, you may see this, but your design should, which should proceed your implementation, should point out this width or breadth to your design, to your tree. It's not just a single branch that goes or a single line. It actually has these branches as you go down the hierarchy. So you should see in most, and you should be able to define in most of your relationships, if it's a hierarchical, that A is B and B is not A. And where there are traits of B that would allow you to say it is A, those are the traits that should be up in the A level, and the ones that are not should be down at the B level. So for example, that employee and person. We know that employee is a person to some extent, and we know a person is an employee to some extent, but what distinguishes those two? One thing may be an employee ID. Not every person has an employee ID, but every employee does. So that would mean you push that employee ID down to the employee level. There may be a title, a job title that a person doesn't necessarily have, but an employee does. So you would have job title down at the employee level. Now that kind of thought process can allow you to set up, which I just told you not to do basically, but can allow you to at least build those placeholders for a very narrow hierarchy that you know you're going to expand upon in the future. So you know, even with a person employee, at that point, we know that a person is not always an employee, although an employee is always a person, and we can find out what are those things, what are those properties or attributes or methods of an employee that a person doesn't necessarily have. And then that allows you to push it down to that level. And this is how we figure out what our hierarchy looks like, how we build it out. The HASA tends to be a little more, I think, challenging in some cases, because people think of things as a group. And it's not necessarily that it either is or it has, but the question there usually boils down to for the HASA, does it actually have that or does that thing define what it is? And it, which is maybe splitting hairs, but it does become valuable and very important when you think of the HASA as in multiple things could have that. So an example would be color. Color is very simple trait. Now, if you have a system where color is very important, where you're doing a lot of calculations on color, and it's not just a simple attribute like maybe a hex value or something like that, or maybe just a string, you know, red, green, blue. If you have a system where it's simple, then that's just an attribute. So while you say HASA, color is really more a property. And we're going to, it does feel like splitting hairs, but the importance here is, is the property something that has its own properties and attributes that we need to be aware of and deal with separately outside of that class, or can they all be handled within the class? Color again, let's take that as an example. Let's say we have a car that has a color, and we have a graphical widget that has a color. Now, the car color most likely is just really is just maybe a string that is, it could be something very specific like a hex, you know, an RGB code, or it could be a string like, you know, white, black, green, red, yellow, brown, whatever. In that case, that may be different from the color that the widget has, which may be very specifically has an RGB, but also maybe has some shading kinds of methods so that you can shade it, particularly like images or things like that. Maybe you can blur it or you can do some way, you know, some of these color manipulations that you see in like a Photoshop or something like that. So those are not the same colors. The color that that string is that you're just using for the car, you're not going to be using those same methods that you use for the widget. So where for the widget, it would, you may say it has a color because you have this color class that has that are these things that define a color in the graphical world. But that's not the color class that you would use for the, for, you know, for a car, for an attribute of a car, because you're not going to be doing the manipulations. It's more of a, and maybe you could, but more likely it's more like a read-only or something that just has different uses. And so you don't want to take that, we'll call it the bigger or the fatter color definition that we use for the widget and apply that to the car. So even though the same name color exists in these two different instances within our system, those are not the same. They are fundamentally not the same color. We don't have the same functions. We don't have even the same necessarily, in a sense, the same understanding. Yes, a blue car may be able, you can see blue when you display that color in the graphical environment. But it's not the same. And I think I'm going to hold off there because this is definitely going to be a multiparty. Is that I just wanted to get started on the IZA and has a, and we haven't really gotten as much in the practical application. So I think I want to do that, hold that off for the next time, next episode, because there's a couple of good things that we need to talk about as we get into that. Like I said, this is not necessarily a, the IZA and has a are concepts that we deal with in the object oriented world, but they don't necessarily, they're not necessarily traits of, that define an object oriented language or something that supports it. So we'll wrap this one up here with the challenge of the week. Just start looking at some of the systems you are and think about the IZs and the has a's that exist in the system. It's not a, you don't have to sit down and like dig into or something, but just try to keep that in the back of your mind and start keeping an eye out of for where those relationships exist. And in particular, where there are things that are conflicting, same name, different functionality, like the color that I just described, because I think we will find that exists in a lot of systems in a lot of different ways. And we probably don't think about it. Too often because we just in our mind can distinguish between those, but it's very important as we get into the design side of stuff. So that's your homework for the week or till the next time we meet. But as always, until then, 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 North podcast. For more episodes like this one, you can find us on Twitter, Facebook, Twitter.com, Twitter.com, Twitter.com, Twitter. For episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernor.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 Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor 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 developernor.com if you would like more information. Now go out there and have yourself a great one.