practical 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. Well, hello and welcome back. We're continuing our season where we're talking about practical object-oriented programming, and we are continuing a discussion of the is-a and has-a relationships. I want to talk a little bit more about the has-a relationships and how to make the most use of those. Now, the thing about has-a, we talked about in a prior episode that there are situations where things have the same name, but they're not the same. If you have a color in your house or a car or something where it's something that you've been painted, your skin color, something like that, it is not detachable from you. However, if the color would be something like maybe the, let's say a color in a graphical object where it has properties that you could actually pull off and you could use somewhere else, although the object has it, there is a class that defines that color. That's really what I talk about is what is it that we have? Is it a single attribute? Maybe even a native type like an integer or string or something like that? Or is it a complex attribute? Color could just be a name, red, white, black, blue, whatever. Or it could be something far more complex. It could have shade and hues and RGB codes and all that kind of stuff. That's just a simple example. When you think about a customer, a company could have a customer and actually have multiple customers. Customer could be an email address or it could be first name, last name, phone, email address, shipping address, billing address, order history and a whole bunch of other stuff. What I want you to do when you're thinking about in the design phase, when you're thinking about has-as, I think it's useful to think of the idea of a power up. This goes beyond that first step of is it simple? Is this attribute something very simple like a number or a simple value? Or is it something more complex? If it's something more complex, does it need to be designed in a way that we can upgrade it, that we can enhance it? You think about in a video game where a lot of these things, you've got a weapon and then you can upgrade it and you start with some basic weapon and then it does more things and more damage and more color or whatever, more explosions, all kinds of stuff that it does that makes it just more impressive. We can do that in our designs as well. We can start with contact information. Customer has a contact info class because we know that contact info is something, something more complex than a simple number or string. We can start out and the contact info, maybe it is a phone number and email address. However, we can inherit from that base contact info and extend it and add a mailing address and maybe a billing address, maybe all of those at the same time. This is where object oriented becomes very powerful. It's also referred to as like the idea of plugins, things like that, where you can plug in a certain object and you've got some values and some functionality or you can plug in a different object and you have different values and properties and functions and things like that. You can upgrade something. You can have an output mechanism that, let's say every document in your system has an output option. Well that output option could be a class that has these descendants that add more output options. So maybe the first one is printer and then later on you have one that is you can do print or send an email, print or send an email or save a file out somewhere or save to a database or fact or you smoke signals. I don't care. Yeah, you can extend this stuff. So this is where it becomes common, I think, to think of the class that you're building and ask questions about those properties along the lines of is this one, is it a simple property? Is it something that doesn't need a class? Can I track color by just a name or just a hex value or do I need to do something more RGB value or do I need something more complicated? Phone number, does it need to just be 10 digits or does it need to have some sort of formatting? Does it need to provide for maybe country codes, zip codes, addresses, customer accounts? And there's just all kinds of stuff out there that we're going to model, data that we're going to model in our objects and our classes and then our objects that we want to give it the ability to grow, to become something better than it is when we start. And so when we're thinking about those initial designs, we need to think through, is this a simple value? If it is, okay, it's a simple attribute. If not, how do we handle that complexity? Is it just some sort of structure or container or because it could be an array, it could be a list or something like that, or does it need to be a class of its own? And then within that class, what does it need? What's that base values or that base class, what does that need to look like? It doesn't make sense that we would have children, child classes that we would be able to use instead because we have that common denominator that's going to exist in a hierarchical tree in object-oriented programming. But then we also have within that common denominator set of features, the ability to maybe expand on. Now, of course, going through with the idea of polymorphism and things like that, then we can actually have something that we call in version one, and it does some things, but when we call that same method in version two or version three, it has a whole lot more functionality in it. If you think of an advance in just the graphical interface, is it maybe early on the way that the object queried the user was through a command line interface, and then it ended up popping up a text field or something like that on a GUI, and then it actually sent a text message or an email message or something like that. All of that would be gather input essentially, but now what we're doing is we're expanding the universe of what that thing can do. We're allowing it to power up, to do more, or to do it better, which is another thing. Sometimes you'll find, particularly if you're in high analysis type situations or something like that, that maybe you have computations of some sort, some sort of processing that's done early on, and then you're actually basically replace it, extend it or replace it later with something that's faster. Still doing the same thing, essentially, it's dealing with the same class, essentially, but instead we're putting in a child class. Of course, within that, you can plug something in, but that plugin can have plugins. Now we can very easily and possibly without even recompiling code, we can move some stuff around and really change functionality. That's of course becomes very powerful when we're talking about code that can dynamically make those kinds of changes. We can do sort of like a just in time use of certain classes. You can see the uses of this are endless, but there are things that I think you can see as your instances grow and do things differently or have more need, then they can access other classes. They can be sent other classes to utilize, or actually I guess other instances to utilize their expended need. You may see this in things like even some simple like a string that maybe initially its display is just a, it has to do a display thing and so it calls display and it just displays it out in a single line. But then later maybe you create a child of display that's multi-line display. You will see this in frameworks all the time. Very common when you'll see in like object relational mapping frameworks, things like that would be the ability to plug in, you have like a base, let's call it database access. But then from there you have all these child database access classes that handle specific access to Oracle or SQL Server or MySQL or Postgres or NoSQL databases or whatever it happens to be. And that's awesome when we're building out our application because with version one, we can say, okay in version one we're going to support Oracle. But we designed it because we thought that we at some point we're going to want to deal with a different database or support more databases. We designed it in a way that now we can in version two create a SQL Server version of that and then we can use that as the attributes for some of our classes. And so now they're integrating with a different database and we haven't had to change anything in the original objects nor in the Oracle stuff. All we did was we created a new class and then we've got some new code that sometimes allows us allow us to basically use that to plug it into a class and give it that expanded functionality. So HESA is very powerful, but it is something I wanted to get you thinking about how that can help you. How can that how that can really help you extend an application. And it's key to design that upfront. When you do, you leave yourself a lot of options. If you don't, you're slamming doors in your face that really don't need to be done. Challenge of the Week. Take a look at some of your core classes that you're using. As I'm saying this, I need to do this with a couple of my applications. Take a look at the core classes you're using and their attributes and what are they? Are they simple? Are they complex? Should they be simple? Should they be complex? Should the complex ones maybe be their own classes? Maybe you can get the wheels turning and suddenly you can create a whole lot of additional functionality without a lot of additional code to be written. Always worth the time to spend a little bit working on designs and thinking through solving the problems that you're solving. But I think for now, worth it or not, our time is up for this episode. So go out there 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 Noor 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 developernoor.com. Just a step forward a day is still progress, so let's keep moving forward together. One more thing before you go. and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.